Intent to implement and ship: Honor media HTML attribute for link icon
François Beaufort 🇫🇷
Contact emails
Spec
https://html.spec.whatwg.org/#rel-icon
https://html.spec.whatwg.org/multipage/semantics.html#processing-the-media-attribute
TAG review
This follows a well-known pattern of using the media attribute to take link elements into account. This has also been a part of the HTML spec for a long time. As such a TAG review doesn't seem necessary. Note that this is a known and acknowledged bug in Chrome.
Summary:
The link element’s “media” attribute will be honored for link[rel="icon"] so that web developers can define multiple equally appropriate icons based on a media query (dark and light modes for instance). The last one that matches will be picked.
Browsers don’t currently honor the media attribute for link[rel="icon"] even though the HTML specification says they should[1].
We're deliberately limiting this Intent to icons for the moment, but discussions have been started to add support for other link relations like "manifest".
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Demo link
Debuggability
DevTools already support viewport resizing and emulating a number of media features such as “prefers-color-scheme” and “prefers-reduced-motion” enabling web developers to observe favicon changes.
Risks
Interoperability and Compatibility
For interoperability risk, if no other vendors follow, web developers would still be able to use this feature (as described in the activation section), and users will see slightly less adapted icons in non-supporting browsers. At the same time, we have positive signals from Mozilla regarding this change.
For compatibility risk, I've scanned the HTTP archive table “httparchive.response_bodies.2020_08_01_mobile” and only 53 websites use link[rel=”icon”] with media="(prefers-color-scheme: dark)" and 85 websites use link[rel=”icon”] with media="(prefers-color-scheme: light)". Ideally, these sites are using it correctly, and us shipping support would be a progression for them. In the worst case, the wrong icons would display for those sites. Note that there are 1673 websites that use link[rel=”icon”] with media, the large majority being with media=””, media=”all”, and media=”screen”, which will not be affected.
Signals from other implementations (Gecko, WebKit):
Gecko: Positive (standards-positions issue)
WebKit: No Signal (webkit-dev)
Web / Framework developers: Positive (tweet with 28 Retweets and 150 Likes, 69 stars on the bug).
Activation:
For multiple equally appropriate icons, the last one is always picked by Chrome and Firefox as specified in the spec, while Safari always picks the first one.
If web developers want to use it now with multiple equally appropriate icons, the first link[rel="icon"] should be the default one, the second one would be the specialized one (dark mode for instance), and the last one would be the one without preference (by default, light mode for instance). In other words, Safari would pick the first one, Firefox and olders versions of Chrome would pick the last one. New versions of Chrome would pick dark or light depending on system preference.
<link rel="icon" href="default.ico" />
<link rel="icon" media="(prefers-color-scheme: dark)" href="dark.ico" />
<link rel="icon" media="(prefers-color-scheme: light)" href="light.ico" />
As suggested by the HTML specification [2], Chrome will update icons when media features change (e.g. dark/light mode change, viewport resize).
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
No. A test suite is currently impossible due to the lack of an API to query favicons. It is tested for Chromium using the internals API.
Entry on the feature dashboard
https://www.chromestatus.com/feature/5728508477177856
[1] Icons could be auditory icons, visual icons, or other kinds of icons. If multiple icons are provided, the user agent must select the most appropriate icon according to the type, media, and sizes attributes. If there are multiple equally appropriate icons, user agents must use the last one declared in tree order at the time that the user agent collected the list of icons.
[2] User agents are not required to update icons when the list of icons changes, but are encouraged to do so.
Yoav Weiss
Entry on the feature dashboard
https://www.chromestatus.com/feature/5728508477177856
[1] Icons could be auditory icons, visual icons, or other kinds of icons. If multiple icons are provided, the user agent must select the most appropriate icon according to the type, media, and sizes attributes. If there are multiple equally appropriate icons, user agents must use the last one declared in tree order at the time that the user agent collected the list of icons.
[2] User agents are not required to update icons when the list of icons changes, but are encouraged to do so.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5JA0GNVMoOQ8Y9JbeEcb2tfe0gRP46NgP9Cmhe3fmBiBg%40mail.gmail.com.
Yoav Weiss
Daniel Bratell
LGTM2
Looking forward to when I can finally use favicons for
media="print". :)
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiPQiZm5RpqzoXumYUrcvOQhU%3DTa0COiz6auHtWQkH7Yw%40mail.gmail.com.
Mike West
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bd750556-1510-9e3f-797e-e8c8a7333d2d%40gmail.com.
Domenic Denicola
> If you expand past icons to other link types, I think you'll need to do some more work to define the processing model. It's not at all clear to me what it would mean for an application's manifest to shift based on dark mode, for instance.