What's there now, and why
govuk_tech_docs 6 renders favicon links in its core layout, branching on show_govuk_logo. This
site sets that to false, so the layout takes the branch expecting the site to supply its own:
<link rel="icon" sizes="48x48" href="/images/favicon.ico">
<link rel="icon" sizes="any" href="/images/favicon.svg" type="image/svg+xml">
Version 3 of the gem referenced no favicon at all, so this repository never needed one. On the
upgrade (#624) every page linked two files that did not exist — 218 broken references, one pair per
page.
To unblock that PR the files were filled with GOV.UK Frontend's own favicons, copied from the
gem, because the repository has no HMCTS icon assets of its own.
Why that needs replacing
It puts the GOV.UK crown on a site that deliberately turns GOV.UK branding off. show_govuk_logo: false is a considered setting — this is an HMCTS engineering documentation site, not a GOV.UK
service — and the favicon now contradicts it. GOV.UK brand assets are also not intended for use
outside GOV.UK services.
It is not a functional problem. Nothing is broken and no page fails. It is the wrong mark in the
browser tab.
Two ways to resolve it — someone with the brand context should choose
1. Supply HMCTS favicons (expected route). Replace two files:
source/images/favicon.ico — 48×48, ideally multi-resolutionsource/images/favicon.svg — scalable, for sizes="any"
Nothing in the code or config reads their contents, so this is a straight file swap.
2. Or decide the site should be GOV.UK-branded and set show_govuk_logo: true in
config/tech-docs.yml. The layout then uses the gem's bundled GOV.UK icons from its own asset path,
legitimately, and the two files here can be deleted. This also changes the visible page header, so it
is a bigger decision than it looks.
Acceptance
source/images/favicon.* carry HMCTS branding, or option 2 is taken and the placeholder files
removedbundle exec middleman build, rake check_pages and rake check_urls all still pass — the link
check is what caught the original gap, so it is the regression test- No other file changes
Context
What's there now, and why
govuk_tech_docs6 renders favicon links in its core layout, branching onshow_govuk_logo. Thissite sets that to false, so the layout takes the branch expecting the site to supply its own:
Version 3 of the gem referenced no favicon at all, so this repository never needed one. On the
upgrade (#624) every page linked two files that did not exist — 218 broken references, one pair per
page.
To unblock that PR the files were filled with GOV.UK Frontend's own favicons, copied from the
gem, because the repository has no HMCTS icon assets of its own.
Why that needs replacing
It puts the GOV.UK crown on a site that deliberately turns GOV.UK branding off.
show_govuk_logo: falseis a considered setting — this is an HMCTS engineering documentation site, not a GOV.UKservice — and the favicon now contradicts it. GOV.UK brand assets are also not intended for use
outside GOV.UK services.
It is not a functional problem. Nothing is broken and no page fails. It is the wrong mark in the
browser tab.
Two ways to resolve it — someone with the brand context should choose
1. Supply HMCTS favicons (expected route). Replace two files:
source/images/favicon.ico— 48×48, ideally multi-resolutionsource/images/favicon.svg— scalable, forsizes="any"Nothing in the code or config reads their contents, so this is a straight file swap.
2. Or decide the site should be GOV.UK-branded and set
show_govuk_logo: trueinconfig/tech-docs.yml. The layout then uses the gem's bundled GOV.UK icons from its own asset path,legitimately, and the two files here can be deleted. This also changes the visible page header, so it
is a bigger decision than it looks.
Acceptance
source/images/favicon.*carry HMCTS branding, or option 2 is taken and the placeholder filesremoved
bundle exec middleman build,rake check_pagesandrake check_urlsall still pass — the linkcheck is what caught the original gap, so it is the regression test
Context
govuk_tech_docs6.3.0)decision rather than an engineering one