Intent to implement and ship: Honor media HTML attribute for link icon

210 views
Skip to first unread message

François Beaufort 🇫🇷

unread,
Mar 4, 2021, 4:24:00 AM3/4/21
to blink-dev

Contact emails

fbea...@chromium.org 


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

https://media-link.glitch.me


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

unread,
Mar 4, 2021, 5:05:42 AM3/4/21
to François Beaufort 🇫🇷, blink-dev
LGTM1

This seems like a small and useful change. I'm also optimistic regarding interop and Mozilla following suite.

Would be good to file a WPT issue asking for such a testing-only 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.

--
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

unread,
Mar 4, 2021, 5:09:04 AM3/4/21
to François Beaufort 🇫🇷, blink-dev
Apologies! The link above does just that...

Daniel Bratell

unread,
Mar 4, 2021, 12:06:00 PM3/4/21
to Yoav Weiss, François Beaufort 🇫🇷, blink-dev

LGTM2

Looking forward to when I can finally use favicons for media="print". :)

/Daniel

Mike West

unread,
Mar 4, 2021, 2:06:55 PM3/4/21
to Daniel Bratell, Yoav Weiss, François Beaufort 🇫🇷, blink-dev
LGTM3.

I agree that this does not require a TAG review; it's been in the spec for a while, and our colleagues at Mozilla seem on board with the potential value.

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.

-mike


Domenic Denicola

unread,
Mar 4, 2021, 2:22:52 PM3/4/21
to Mike West, Daniel Bratell, Yoav Weiss, François Beaufort 🇫🇷, blink-dev
From: Mike West <mk...@chromium.org>

> 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.

I filed https://github.com/whatwg/html/issues/6450 on this, as although the spec does indicate icon should update, it's indeed not very clear on the specifics.

Reply all
Reply to author
Forward
0 new messages