Re: [whatwg] Icon mask and theme color
On Mon, Jun 15, 2015 at 12:18 PM, Kornel Lesiński kor...@geekhood.net wrote: The new Safari is still only a preview, so I hope Apple will switch to a better solution. It would be great if we could get some feedback from Ted colleagues on what the thinking here was. -- https://annevankesteren.nl/
[whatwg] Icon mask and theme color
Apple has released a version of Safari that has a new interpretation of link rel=icon and meta name=theme-color that conflicts with existing usage on the Web. Safari (8.1 OS X 11.11) uses `theme-color` for foreground color of favicons of pinned tabs, but other browsers use `theme-color` for background colors. This makes it impossible to have a light theme color that fits Chrome's background and a dark pinned icon color that suits Safari (rdar://21379839). Additionally Apple introduced a `mask` attribute on the link element that is merely modifying the link relationship, but in a way that is incompatible with other browsers. To avoid compatibility problems I suggest specifying a way to define icon masks and colors in a way that doesn't conflict with usage on the Web. The new Safari is still only a preview, so I hope Apple will switch to a better solution. To prevent user agents from using theme-color in conflicting ways I suggest defining theme-color to be a background color: https://github.com/whatwg/meta-theme-color/issues/10 and adding a new meta: meta name=icon-mask-color to define color for the favicon specifically. Additionally I suggest defining `icon-mask` link relationship for an icon that user agent can colorize: link rel=icon-mask href=silhouette.svg This way authors can control whether they want the icon to be reused as a regular icon, with link rel=icon icon-mask, or not, by using this relationship alone. -- Kind regards, Kornel Lesiński
Re: [whatwg] A mask= advisory flag for link rel=icon
Edward O'Connor eocon...@apple.com writes: Lately we've identified a need for an additional advisory attribute for icons. Modern user interfaces have a flatter, more minimal UI style as compared to UIs of the past, and modern devices often feature higher-density displays. Legacy favicons don't really do well in these new environments—they can come off as garish and pixelated. It'd be great if sites could provide a simple, monochrome, scalable icon that would fit right in on modern systems. Such an icon could be used as the default tile image on Windows, as a template image on OS X and iOS, or a system icon in Material Design. These images can be tinted to better fit in with the site's theme. Their shape is important and can be used as a mask which lets the image be used in a variety of UI contexts. Please tell me where the requirement for SVG favicons with 100% black paths comes from. I do not understand why an SVG favicon cannot have proper SVG colors so there are no interoperability issues with it. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] A mask= advisory flag for link rel=icon
Nils, Le 16 juin 2015 à 10:03, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net a écrit : Edward O'Connor eocon...@apple.com writes: These images can be tinted to better fit in with the site's theme. Please tell me where the requirement for SVG favicons with 100% black paths comes from. I do not understand why an SVG favicon cannot have proper SVG colors so there are no interoperability issues with it. Ed, maybe, replied already I believed in the sentence above. The mask icon is giving just a shape. So that the chosen theme of the phone can customized the color to its own choice. Be imposed by the brand of the operator, or I guess someone hacking its theme to have its own. see for example http://stackoverflow.com/questions/9711481/icon-color-on-different-themes I guess things like Android theme, icon sets, etc. would give some answers. https://dribbble.com/search?q=+icon+sets+monochrome It's a way for a site to provide a generic shaped icon but that will adjust its colors depending on the theme. -- Karl Dubost http://www.la-grange.net/karl/
Re: [whatwg] A mask= advisory flag for link rel=icon
If I am not mistaken, it should be possible to use the outline shape while not requiring 100% black color for every path in the SVG icon. As I see it, a proper icon has to have a distinctive outline anyway. Karl Dubost k...@la-grange.net writes: Nils, Le 16 juin 2015 à 10:03, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net a écrit : Edward O'Connor eocon...@apple.com writes: These images can be tinted to better fit in with the site's theme. Please tell me where the requirement for SVG favicons with 100% black paths comes from. I do not understand why an SVG favicon cannot have proper SVG colors so there are no interoperability issues with it. Ed, maybe, replied already I believed in the sentence above. The mask icon is giving just a shape. So that the chosen theme of the phone can customized the color to its own choice. Be imposed by the brand of the operator, or I guess someone hacking its theme to have its own. see for example http://stackoverflow.com/questions/9711481/icon-color-on-different-themes I guess things like Android theme, icon sets, etc. would give some answers. https://dribbble.com/search?q=+icon+sets+monochrome It's a way for a site to provide a generic shaped icon but that will adjust its colors depending on the theme. -- Karl Dubost http://www.la-grange.net/karl/ -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Icon mask and theme color
Hi all, Kornel wrote: Safari[…] uses `theme-color` for foreground color of favicons of pinned tabs, but other browsers use `theme-color` for background colors. Well, meta name=theme-color is not specced as speficially a foreground or background color; it's a color that user agents may use in any number of ways to customize their UI when displaying a web page. Safari's use of theme-color for pinned tabs is consistent with its definition. [1] This makes it impossible to have a light theme color that fits Chrome's background and a dark pinned icon color that suits Safari[…] UAs are allowed to automatically adjust the theme color for different uses, which is intended to address this issue (again, [1]): When using the page's theme color, user agents MAY adjust the color in UA-defined ways to make it more suitable for particular uses. For example, if a UA intends to use the theme color as a background and display white text over it, it may use a darker variant of the theme color for that purpose, to ensure adequate contrast. I think I agree with you that sites should be able to provide more than one color. That said, I suspect one color hits the 80/20 point and maybe we shouldn't overthink it. Additionally Apple introduced a `mask` attribute on the link element that is merely modifying the link relationship, but in a way that is incompatible with other browsers. It's compatble with other browsers and the spec of link rel=icon. I'll start a new thread with our proposal in a sec. More on compat below. Daniel wrote: Apple suggests that these new elements 'should be placed before other link rel=icon elements to avoid compatibility issues' -- if sites follow this guideline, it should make other browsers ignore the markup and honor the final real favicon. When there are multiple link rel=icons specified, here's what the spec currently says user agents must do [2]: 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. Our proposal is simply to add mask= to this list of advisory attributes that are used to determine an icon's appropriateness here. User agents that don't understand mask= should continue to pick the most appropriate icon given the other attributes. If there is a tie, the last link rel=icon wins. That is why we recommend authors put link rel=icon mask first—so that the existing tie-breaking behavior results in the legacy favicon being chosen. Ted 1. https://github.com/whatwg/meta-theme-color 2. https://html.spec.whatwg.org/#rel-icon
[whatwg] A mask= advisory flag for link rel=icon
When link is used to pull in external resources, authors may use several attributes as hints about the linked resource to help UAs decide whether or not to load it. For instance, the resource's MIME type may be provided in the type attribute. This allows UAs to avoid loading resources they don't support. Another example is the sizes attribute, which is used to help browsers download an appropriately-sized icon for a site without redundant resource loads. Lately we've identified a need for an additional advisory attribute for icons. Modern user interfaces have a flatter, more minimal UI style as compared to UIs of the past, and modern devices often feature higher-density displays. Legacy favicons don't really do well in these new environments—they can come off as garish and pixelated. It'd be great if sites could provide a simple, monochrome, scalable icon that would fit right in on modern systems. Such an icon could be used as the default tile image on Windows, as a template image on OS X and iOS, or a system icon in Material Design. These images can be tinted to better fit in with the site's theme. Their shape is important and can be used as a mask which lets the image be used in a variety of UI contexts. There are already some favicons in use out there would work for this purpose but UAs aren't in a position to know that (at least, not without downloading the icon first). A simple author opt-in saying that an icon is suitable would help UAs pick the right icon to download and, unlike the sizes and type attributes, there's no need for a complicated attribute value microsyntax. A boolean attribute will do nicely. See the postscript for bikeshedding the attribute name; in the rest of this proposal, it's called `mask`. Authors would provide a mask icon like so: link rel=icon href=mask.svg mask This combines well with the other resource hints we already have: link rel=icon href=mask.svg type=image/svg+xml sizes=any mask There are any number of properties UAs might want to use when deciding whether or not to load a resource, so you might think we shouldn't add a new, one-off attribute every time we identify one. Instead, we could add a generic hints attribute and have it take a space-separated list of advisory info about the resource. I don't think this objection holds for at least two reasons: 1) In the 10+ years we've been working on HTML at the WHATWG, we've only actually added one new hint to link, the sizes attribute. We're not at risk of a Cambrian explosion of attributes here. 2) All of the three existing hints (the type, media, and sizes attributes) take values with microsyntaxes; if we assume that pattern continues, the syntax needed for a unified hints attribute would get way too complex (think srcset= but *much* worse). Better to separate hints with different syntax into different attributes. I think the addition of a boolean mask attribute to link rel=icon is the simplest thing we could do here, and would help sites' icons better fit in on modern platforms. Ted P.S. OK, bikeshedding. What should we call the attribute? The ideal name says something about the icon and not about how a UA might use it. There are a few properties of the icon that are interesting: it's monochrome (and can be tinted to fit a theme), it's suitable for use as a mask, it's a simple/minimal/reduced representation of the site or app. We could go with a monochrome attribute, a mask attribute, or some other option. Out of these I most like an attribute named mask. It's shorter, for one. But I don't strongly prefer it and I'm sure someone else will come up with something way better.
Re: [whatwg] Icon mask and theme color
On Jun 15, 2015, at 3:27 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jun 15, 2015 at 12:18 PM, Kornel Lesiński kor...@geekhood.net wrote: The new Safari is still only a preview, so I hope Apple will switch to a better solution. It would be great if we could get some feedback from Ted colleagues on what the thinking here was. First: it looks like we neglected to send our proposal for this ahead of our preview release. It’s now been sent belatedly. We regret the error. Second: we’re definitely open to changing this if there’s consensus for a different syntax. Our original thinking on this: rel=icon is intended to support selection from multiple formats and sizes. It seemed natural to extend this to the notion of a monochrome icon that’s intended to be recolored. Before deploying the feature, we thought it would be cleaner to extend rel=icon than to invent a new rel value. (There’s already the legacy -apple-touch-icon value with in theory could be obsoleted by rel=icon with the appropriate size). For similar reasons, it seemed better to reuse the existing theme-color meta (which gives license to darken or lighten the color as needed). The nature of the problem: to avoid breaking the regular favicon, both in Safari and in other browsers, sites need to make their regular favicon explicit with a rel=icon link (instead of relying on favicon.ico), and need to put the mask icon first instead of last in the list of icon links. We thought clear advice to do this, plus the fact that breakage should be obvious, would limit the scope of the error and would lead sites to fix it promptly. That doesn’t seem to be happening, at least yet. We noticed this problem internally even before shipping (working with some sites to get mask icons up before release), but there was internal debate about whether the problem would shrink or grow over time. Where do we go from here: (1) We could add mask or something like it to the standard, and change browsers to ignore mask icons in contexts where they are looking for a regular icon. (2) We could change to a new rel type for mask icons, such as rel=mask-icon, but keep theme-color as the source of the color, with the possibility of darkening light colors used to make light colors viable. (3) We could change to a new rel type for mask icons, such as rel=mask-icon, and give it a color attribute to be used specifically for the icon. We don’t have a strong principle on this, and it’s not too late to change before shipping the release version of Safari 9. We welcome input on which of these would be best, or whether something else entirely is better. Sorry again for not bringing this up before the preview release that included this feature. Regards, Maciej
Re: [whatwg] Icon mask and theme color
On Mon, Jun 15, 2015 at 7:33 PM, Edward O'Connor eocon...@apple.com wrote: Our proposal is simply to add mask= to this list of advisory attributes that are used to determine an icon's appropriateness here. User agents that don't understand mask= should continue to pick the most appropriate icon given the other attributes. If there is a tie, the last link rel=icon wins. That is why we recommend authors put link rel=icon mask first—so that the existing tie-breaking behavior results in the legacy favicon being chosen. I think the only problem with this advice is that it lacks the bit where you need to list link rel=icon href=/favicon.ico explicitly (and last) once you add a link rel=icon mask entry. That seems to be the reason why Twitter is now black rather than light blue in Firefox. -- https://annevankesteren.nl/
Re: [whatwg] Icon mask and theme color
Hi Anne, You wrote: Our proposal is simply to add mask= to this list of advisory attributes that are used to determine an icon's appropriateness here. User agents that don't understand mask= should continue to pick the most appropriate icon given the other attributes. If there is a tie, the last link rel=icon wins. That is why we recommend authors put link rel=icon mask first—so that the existing tie-breaking behavior results in the legacy favicon being chosen. I think the only problem with this advice is that it lacks the bit where you need to list link rel=icon href=/favicon.ico explicitly (and last) once you add a link rel=icon mask entry. Fair point. Even though we've all been trying to move people away from the well-known /favicon.ico URL to link rel=icon for years, I guess we need to keep saying it. :)
Re: [whatwg] A mask= advisory flag for link rel=icon
On Jun 15, 2015, at 3:55 PM, Elliott Sprehn espr...@chromium.org wrote: Adding a whole new attribute for this seems like overkill, why not use the rel. link rel=icon mask href=... sizes=... That's what the rel list was designed for. In general, rel values are supposed to be orthogonal, they should not modify each other’s meanings. rel=“alternate stylesheet” and rel=“shortcut icon” are two specific historical exceptions. But rel=“license help” means the link is both the license and the help for the page, not that it’s help about the license or anything like that. So I don’t think it would be a good pattern to use the rel value for this. It also wouldn’t solve the immediate problem with browsers getting the wrong icon because sites didn’t carefully set the correct order. Perhaps we don’t care about solving that, but if so, I’m not sure it’s an improvement. - Maciej On Mon, Jun 15, 2015 at 10:37 AM, Edward O'Connor eocon...@apple.com wrote: When link is used to pull in external resources, authors may use several attributes as hints about the linked resource to help UAs decide whether or not to load it. ... This combines well with the other resource hints we already have: link rel=icon href=mask.svg type=image/svg+xml sizes=any mask There are any number of properties UAs might want to use when deciding whether or not to load a resource, so you might think we shouldn't add a new, one-off attribute every time we identify one. Instead, we could add a generic hints attribute and have it take a space-separated list of advisory info about the resource. That space separated list already exists, it's called rel. - E
Re: [whatwg] A mask= advisory flag for link rel=icon
Adding a whole new attribute for this seems like overkill, why not use the rel. link rel=icon mask href=... sizes=... That's what the rel list was designed for. On Mon, Jun 15, 2015 at 10:37 AM, Edward O'Connor eocon...@apple.com wrote: When link is used to pull in external resources, authors may use several attributes as hints about the linked resource to help UAs decide whether or not to load it. ... This combines well with the other resource hints we already have: link rel=icon href=mask.svg type=image/svg+xml sizes=any mask There are any number of properties UAs might want to use when deciding whether or not to load a resource, so you might think we shouldn't add a new, one-off attribute every time we identify one. Instead, we could add a generic hints attribute and have it take a space-separated list of advisory info about the resource. That space separated list already exists, it's called rel. - E
Re: [whatwg] A mask= advisory flag for link rel=icon
Hmm, I suppose Elliott's proposal is a bit ambiguous, but I read it as fixing the ordering issue by adding a separate mask rel value. Such that the following are equivalent and independent of ordering: A) link rel=icon href=colorful.pnglink rel=mask href=black.svg B) link rel=mask href=black.svglink rel=icon href=colorful.png And if someone actually did want the same icon for both, they could do: C) link rel=icon mask href=blackhole.svg Justin On Mon, Jun 15, 2015 at 4:20 PM, Maciej Stachowiak m...@apple.com wrote: On Jun 15, 2015, at 3:55 PM, Elliott Sprehn espr...@chromium.org wrote: Adding a whole new attribute for this seems like overkill, why not use the rel. link rel=icon mask href=... sizes=... That's what the rel list was designed for. In general, rel values are supposed to be orthogonal, they should not modify each other’s meanings. rel=“alternate stylesheet” and rel=“shortcut icon” are two specific historical exceptions. But rel=“license help” means the link is both the license and the help for the page, not that it’s help about the license or anything like that. So I don’t think it would be a good pattern to use the rel value for this. It also wouldn’t solve the immediate problem with browsers getting the wrong icon because sites didn’t carefully set the correct order. Perhaps we don’t care about solving that, but if so, I’m not sure it’s an improvement. - Maciej On Mon, Jun 15, 2015 at 10:37 AM, Edward O'Connor eocon...@apple.com wrote: When link is used to pull in external resources, authors may use several attributes as hints about the linked resource to help UAs decide whether or not to load it. ... This combines well with the other resource hints we already have: link rel=icon href=mask.svg type=image/svg+xml sizes=any mask There are any number of properties UAs might want to use when deciding whether or not to load a resource, so you might think we shouldn't add a new, one-off attribute every time we identify one. Instead, we could add a generic hints attribute and have it take a space-separated list of advisory info about the resource. That space separated list already exists, it's called rel. - E
