Re: [whatwg] Icon mask and theme color

[Smylers]

Maciej Stachowiak writes:

> > On Jun 16, 2015, at 4:37 AM, Nils Dagsson Moskopp
> >  wrote:
> > 
> > (5) Use the shape of the path in the SVG icon as a mask and retain
> > the theme color meta value. Why isn't this done? One could have a
> > properly colored icon for one purpose and use the outline of the
> > same icon for the flat design staff.
> 
> We could change to considering only the alpha channel of the mask icon
> instead of both mask and luminance. ... Note though, that even if we
> went alpha-only, it might not be possible to use the same file for a
> mask icon and a full-color icon and get good results, for certain
> effects.

Sure — for the best results a site may want separate icons. But the
recent threads have been largely prompted by sites inadvertently serving
suboptimal icons, so we also need to consider the behaviour when they
make a mistake, not just the ideal case.

And even for the ideal case, a single icon may suffice for some sites.
Twitter, for example, with a solid blue bird shape as the colour icon,
which could also work as a mask. That _some_ sites would require two
icons doesn't seem like a reason to impose that burden on _all_ sites.

> obvious example is Facebook’s normal favicon, which is a white
> lowercase f on a blue rounded rectangle. It’s important in the color
> version for the white to be white, not transparent, but if both the
> white and blue are solid, the mask version is just a roundrect.

Yep, the ideal colour version wouldn't work as a mask. But t'other way
round, the mask could work as an acceptable (albeit not ideal) colour
icon. Currently when the mask is inadvertently used as the ‘colour’
icon, it has to be all black. But with Nils's suggested change above,
the mask could use Facebook blue instead of black; the masking effect
would be the same, but if the mask ends up being interpreted as as a
colour icon, it then at least has some colour in it.

> > On Jun 15, 2015, at 12:53 PM, Kornel Lesiński 
> > wrote:
> > 
> > (4) Don't require the mask icon to be 100% black and read the color
> > from the icon itself. 
> > 
> > The mask flag would indicate that shape of the icon is distinctive
> > enough, i.e. alpha channel of the icon can be used without the color
> > channels, but wouldn't forbid use of color channels.
> > 
> > If in Safari you'd like to enforce use of only a single solid theme
> > color for the icon, then you can compute the theme color by
> > averaging colors of all non-transparent pixels of the mask icon, and
> > use that as the icon's theme color.
> 
> We do have a requirement to have the mask icons render with a single
> color. I don’t think the approach suggested here is very good. Color
> averaging would not be very predictable in its results and could be
> unstable to changes in the icon if it’s actually multi-color.

No, but colour-averaging would only be a fallback to get _some_ colour
in the situation where the developer failed to follow guidelines and put
multiple colours in their mask image.

Again, consider Twitter: if they have an icon which already is a solid
shape of the correct colour (so it can be used as a colour icon, too),
why should they have to specify that colour a second time in their HTML?
You already know what the colour is, from the icon itself.

Smylers
-- 
http://twitter.com/Smylers2

Re: [whatwg] A mask="" advisory flag for

[Maciej Stachowiak]

> On Jun 16, 2015, at 9:49 PM, Anne van Kesteren  wrote:
> 
> On Tue, Jun 16, 2015 at 10:42 PM, Tab Atkins Jr.  wrote:
>> Before we start bikeshedding, can you commit to actually changing your
>> implementation?  Safari has already shipped with the exact proposal
>> given in this thread; if you're seeking a rubberstamp rather than a
>> collab, say so.
> 
> Maciej already clarified this, no? They're perfectly happy to change
> this before Safari 9 ships, provided, I'm guessing, that we settle
> this somewhat quickly.

Yep. Quoting myself from earlier:

> On Jun 15, 2015, at 12:00 PM, Maciej Stachowiak  wrote:
> 
> 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.

To be even more explicit, we’re willing to change. If there’s a rough consensus 
soon, we can change it before any final non-beta release of Safari ships with 
the feature. Even if the discussion continues for a while, we may be able to 
change after we ship, but we might have to stage it and support two syntaxes 
for a while.


It seems like the current leading candidate is:

- Change  to , but keep using the 
theme-color meta for the color

If anyone feels strongly about sticking with the icon rel value, please speak 
up.

It might also be good to change interpretation of the icon as a mask to 
consider only alpha. But this probably wouldn’t affect the spec since how any 
 is rendered is implementation-specific. Also, t would not make 
it practical to use the same icon for mask and non-mask purposes in most cases, 
so it wouldn’t help with the compat issue. So this aspect seems less urgent.


Regards,
Maciej

Re: [whatwg] Icon mask and theme color

[Maciej Stachowiak]

Consolidating replies to limit spam.
> On Jun 16, 2015, at 4:37 AM, Nils Dagsson Moskopp 
>  wrote:
> 
> Maciej Stachowiak  writes:
> 
>> […]
>> 
>> 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.
[…]

> 
> (4) Set a MIME type like application/vnd.apple.svg-mask+xml. This might
> prevent breakage in other browsers and allow opt-in without introducing
> new attributes. The source of the theme color could then be in the file
> or in the theme color meta value.

I think inventing a new MIME type or a new file format would be less elegant 
than a new rel value, and it would be harder for authors to adopt correctly, so 
I think this is dominated by (2)/(3). At least, I can’t think of a way in which 
it would be better.

> 
> (5) Use the shape of the path in the SVG icon as a mask and retain the
> theme color meta value. Why isn't this done? One could have a properly
> colored icon for one purpose and use the outline of the same icon for
> the flat design staff.

We could change to considering only the alpha channel of the mask icon instead 
of both mask and luminance. We did it this way because we already had code to 
treat SVG as a mask for the , and it seemed better to be consistent. Note 
though, that even if we went alpha-only, it might not be possible to use the 
same file for a mask icon and a full-color icon and get good results, for 
certain effects. I believe others on the thread have explained this already, 
but another obvious example is Facebook’s normal favicon, which is a white 
lowercase f on a blue rounded rectangle. It’s important in the color version 
for the white to be white, not transparent, but if both the white and blue are 
solid, the mask version is just a roundrect.


On Jun 16, 2015, at 1:48 PM, Ben Francis  wrote:

> On Mon, Jun 15, 2015 at 8:00 PM, Maciej Stachowiak  > wrote:
> 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.
> 
> Just putting this out there, did you consider using the W3C web manifest [1] 
> for the pinned sites feature?

We looked at it, but we didn’t want to require a whole new format for the 
feature to work at all. I wouldn’t rule out using it in the future as a 
possible alternate source of metadata for pinned tabs (or for websites saved to 
the home screen on iOS), but I can’t make any commitments on this.

In any case, web manifest would still require us to figure out a way to specify 
mask icons, and source of color for the mask icon.

[…]

> We are still discussing the properties of an "icon" object in that spec and 
> it already has a background_color member. We could explore adding something 
> there that fits Apple's requirements? Perhaps this could be used to deprecate 
> the proprietary apple-touch-icon as well?
> 
> If that sounds interesting to you then please feel free to file an issue on 
> GitHub https://github.com/w3c/manifest/issues 
> 

The color for the mask icon is a foreground color, not a background color. I’m 
not yet sure whether it mask icons need a dedicated color or could just use the 
theme color.


> On Jun 15, 2015, at 12:53 PM, Kornel Lesiński  wrote:
> 
> Another suggestion:
> 
> (4) Don't require the mask icon to be 100% black and read the color from the 
> icon itself. 
> 
> The mask flag would indicate that shape of the icon is distinctive enough, 
> i.e. alpha channel of the icon can be used without the color channels, but 
> wouldn't forbid use of color channels.
> 
> If in Safari you'd like to enforce use of only a single solid theme color for 
> the icon, then you can compute the theme color by averaging colors of all 
> non-transparent pixels of the mask icon, and use that as the icon's theme 
> color.

We do have a requirement to have the mask icons render with a single color. I 
don’t think the approach suggested here is very good. Color averaging would not 
be very predictable in its results and could be unstable to changes in the icon 
if it’s actually multi-color. One thing we could do is move the color 
specification from the webpage to a  tag inside the SVG or something, but 
I’m not sure that’s a huge improvement either.

Regards,
Maciej

Re: [whatwg] A mask="" advisory flag for

[Anne van Kesteren]

On Tue, Jun 16, 2015 at 10:42 PM, Tab Atkins Jr.  wrote:
> Before we start bikeshedding, can you commit to actually changing your
> implementation?  Safari has already shipped with the exact proposal
> given in this thread; if you're seeking a rubberstamp rather than a
> collab, say so.

Maciej already clarified this, no? They're perfectly happy to change
this before Safari 9 ships, provided, I'm guessing, that we settle
this somewhat quickly.


-- 
https://annevankesteren.nl/

Re: [whatwg] A mask="" advisory flag for

[Kornel Lesiński]

>> 
>> The reason for treating the icon as a mask is that we want to enforce
>> having a monochrome shape, specifically for our pinned tabs feature.
> 
> The svg  element has a switch for choosing between luminance and
> alpha masking; I think using alpha masking instead seems like a pretty
> clear win.  It makes the color irrelevant, making it more likely that
> the plain icon is appropriate to use for a mask as well, and there's
> no difference in behavior if you're using opaque colors.  (No
> difference in functionality overall, either; you just achieve
> partial-transparency with alpha rather than color.)

I think it would be a big improvement if Safari only looked at the alpha 
channel and ignored luminance for the mask.

And as I've suggested before, instead of reading the theme color from the 
problematic , Safari could read the theme color from the icon 
by averaging colors of opaque pixels of the icon. 

Instead of 100% black, authors should be advised to make the icon 100% in the 
theme color they want.

It would be easy to author (it'd display essentially as-is if the author used a 
solid color) and still meet the requirement of enforcing a monochrome image 
(authors that mixed colors against the advice would get one color that is a 
blend).

And all this would be achieved without the need for another metatag, and the 
mask icon would the same in other browsers.

-- 
Kind regards, Kornel Lesiński

[whatwg] preload="none" and HTMLMediaElement.load()

[Brian Birtles]

The HTMLMediaElement.load()[1] method currently cancels playback of the 
current resource and runs the resource selection algorithm[2] (and in 
turn the resource fetch algorithm[3]). When preload="none", however, the 
resource fetch algorithm doesn't require the UA to load data or progress 
to HAVE_METADATA--instead it can suspend the load until, for example, 
the user goes to play the video.


In Firefox we've hit compatibility issues where some sites are calling 
load() on preload="none" resources and expecting to get a 
"loadedmetadata" event.[4]


Apparently, even with preload="none", Chrome and IE progress to 
HAVE_METADATA when load() is called. Presto, apparently, does not.


I've just landed a patch in Firefox to make a call to load() treat 
preload="none" as preload="metadata" to match the behavior of Chrome/IE 
in this case.


(Note that we need to do this not only when preload="none" is explicitly 
specified but also when the preload attribute is missing and the UA's 
missing value default for preload is 'none'--as is the case for us on 
mobile.)


Is it possible to get this reflected in the spec?

Best regards,

Brian

[1] 
https://html.spec.whatwg.org/multipage/embedded-content.html#dom-media-load
[2] 
https://html.spec.whatwg.org/multipage/embedded-content.html#concept-media-load-algorithm
[3] 
https://html.spec.whatwg.org/multipage/embedded-content.html#concept-media-load-resource

[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1165203

Re: [whatwg] A mask="" advisory flag for

[Tab Atkins Jr.]

On Tue, Jun 16, 2015 at 2:36 PM, Elliott Sprehn  wrote:
> On Tue, Jun 16, 2015 at 2:33 PM, Tab Atkins Jr. 
> wrote:
>> On Tue, Jun 16, 2015 at 2:25 PM, Elliott Sprehn 
>> wrote:
>> > On Tue, Jun 16, 2015 at 2:22 PM, Tab Atkins Jr. 
>> > wrote:
>> >> On Tue, Jun 16, 2015 at 2:07 PM, Elliott Sprehn 
>> >> wrote:
>> >> > sizes is a generic feature that's available for all image resources.
>> >>
>> >> No it's not;  and  are completely unrelated.
>> >
>> > :( That's really confusing:
>> >
>> > https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#attr-sizes
>>
>> Non-global attributes aren't global. Who knew. ^_^
>
> Well, two elements that both load image resources and both have an attribute
> named sizes that do different things isn't very good developer ergonomics.
> href isn't global either, but I'd be sad if we added a new element where it
> was interpreted as something besides a url.

Yeah, you're not wrong.  I simply didn't remember that 
existed when I designed .  If we could redo that, I might
have chosen a different name.

~TJ

Re: [whatwg] Icon mask and theme color

[Tab Atkins Jr.]

On Mon, Jun 15, 2015 at 12:00 PM, Maciej Stachowiak  wrote:
> For similar reasons, it seemed better to reuse the existing theme-color meta 
> (which gives license to darken or lighten the color as needed).

Agreed; along with Ted's observation that theme-color hits at least
the 80/20 use-case, I don't think we need anything new for colors
here.  UAs SHOULD look at the lightness of the theme-color and make
adjustments as appropriate.  (Tho only if necessary - Twitter blue,
for example, should stay unless it's really bad. Icons don't need to
meet the same a11y contrast guidelines as text, I wouldn't think,
giving you a lot of latitude to keep the specified color exactly in
most circumstances.)

Re: [whatwg] A mask="" advisory flag for

[Elliott Sprehn]

On Tue, Jun 16, 2015 at 2:33 PM, Tab Atkins Jr. 
wrote:

> On Tue, Jun 16, 2015 at 2:25 PM, Elliott Sprehn 
> wrote:
> > On Tue, Jun 16, 2015 at 2:22 PM, Tab Atkins Jr. 
> > wrote:
> >> On Tue, Jun 16, 2015 at 2:07 PM, Elliott Sprehn 
> >> wrote:
> >> > sizes is a generic feature that's available for all image resources.
> >>
> >> No it's not;  and  are completely unrelated.
> >>
> >
> > :( That's really confusing:
> >
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#attr-sizes
>
> Non-global attributes aren't global. Who knew. ^_^
>

Well, two elements that both load image resources and both have an
attribute named sizes that do different things isn't very good developer
ergonomics. href isn't global either, but I'd be sad if we added a new
element where it was interpreted as something besides a url.

- E

Re: [whatwg] A mask="" advisory flag for

[Tab Atkins Jr.]

On Tue, Jun 16, 2015 at 2:25 PM, Elliott Sprehn  wrote:
> On Tue, Jun 16, 2015 at 2:22 PM, Tab Atkins Jr. 
> wrote:
>> On Tue, Jun 16, 2015 at 2:07 PM, Elliott Sprehn 
>> wrote:
>> > sizes is a generic feature that's available for all image resources.
>>
>> No it's not;  and  are completely unrelated.
>>
>
> :( That's really confusing:
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#attr-sizes

Non-global attributes aren't global. Who knew. ^_^

> In any case, I don't think adding a boolean mask attribute to 
> specific to the icon type makes sense.

Agreed, for the reasons stated previously by myself and others.

~TJ

Re: [whatwg] A mask="" advisory flag for

[Elliott Sprehn]

On Tue, Jun 16, 2015 at 2:22 PM, Tab Atkins Jr. 
wrote:

> On Tue, Jun 16, 2015 at 2:07 PM, Elliott Sprehn 
> wrote:
> > sizes is a generic feature that's available for all image resources.
>
> No it's not;  and  are completely unrelated.
>
>
:( That's really confusing:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#attr-sizes

In any case, I don't think adding a boolean mask attribute to 
specific to the icon type makes sense.

- E

Re: [whatwg] A mask="" advisory flag for

[Tab Atkins Jr.]

On Tue, Jun 16, 2015 at 2:07 PM, Elliott Sprehn  wrote:
> sizes is a generic feature that's available for all image resources.

No it's not;  and  are completely unrelated.

~TJ

Re: [whatwg] A mask="" advisory flag for

[Tab Atkins Jr.]

On Tue, Jun 16, 2015 at 1:51 PM, Edward O'Connor  wrote:
> Hi Elliott,
>
> You wrote:
>> I'm fine with either interpretation, mask-icon or "icon mask" like
>> "alternate stylesheet". I don't think adding a mask attribute to the
>> HTMLLinkElement for this makes sense.
>
> Could you elaborate? It's not clear to me why 
> wouldn't make sense, but  does. They are both
> useful advisory hints that help UAs avoid redundant resource loads.

"sizes" really is an advisory hint; if you don't understand it and
just download one of the icons, at worst you'll get a version that
needs to be scaled up or down.  Accidentally displaying a "mask"
version of the favicon can give substantially worse results; the
design tradeoffs made for mask icons can be substantially different
than those for favicons, and result in a completely unsuitable icon
(particularly if rendered in solid black, as is currently
recommended).

Note the WHATWG thread from two days ago about 
already being seen in the wild and having precisely this problem,
where the simplest conclusion appears to be *specifically ignoring the
mask links*. 


~TJ

Re: [whatwg] A mask="" advisory flag for

[Elliott Sprehn]

On Tue, Jun 16, 2015 at 1:51 PM, Edward O'Connor  wrote:

> Hi Elliott,
>
> You wrote:
>
> > I'm fine with either interpretation, mask-icon or "icon mask" like
> > "alternate stylesheet". I don't think adding a mask attribute to the
> > HTMLLinkElement for this makes sense.
>
> Could you elaborate? It's not clear to me why 
> wouldn't make sense, but  does. They are both
> useful advisory hints that help UAs avoid redundant resource loads.
>

Do you plan to add the mask attribute to ,  and CSS?

sizes is a generic feature that's available for all image resources.

- E

Re: [whatwg] A mask="" advisory flag for

[Edward O'Connor]

Hi Elliott,

You wrote:

> I'm fine with either interpretation, mask-icon or "icon mask" like
> "alternate stylesheet". I don't think adding a mask attribute to the
> HTMLLinkElement for this makes sense.

Could you elaborate? It's not clear to me why 
wouldn't make sense, but  does. They are both
useful advisory hints that help UAs avoid redundant resource loads.


Ted

Re: [whatwg] A mask="" advisory flag for

[Tab Atkins Jr.]

On Mon, Jun 15, 2015 at 10:37 AM, Edward O'Connor  wrote:
> Authors would provide a mask icon like so:
>
> 
[...]
> 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.

Before we start bikeshedding, can you commit to actually changing your
implementation?  Safari has already shipped with the exact proposal
given in this thread; if you're seeking a rubberstamp rather than a
collab, say so.

In the spirit of bikeshedding, Justin Dolske seems to have the right
idea.  "mask" or "icon-mask" or something as a new rel value that
indicates a file to be used as a theme-color-filled mask works better
within the existing ecosystem.  In particular, naive processors that
understand rel=icon but not mask (aka every browser on the market
today besides latest Safari) won't do stupid things, like use the mask
as an icon directly.

> There’s no technological enforcement that the SVG only uses the color
> black. We will interpret it as a mask in the same way as the SVG ‘mask’
> element, which effectively combines the luminance with the alpha channel.
> Effectively, this means that other colors will end up partly transparent,
> so using other colors will probably do something weird, but nothing
> prevents authors from doing that afaik.
>
> The reason for treating the icon as a mask is that we want to enforce
> having a monochrome shape, specifically for our pinned tabs feature.

The svg  element has a switch for choosing between luminance and
alpha masking; I think using alpha masking instead seems like a pretty
clear win.  It makes the color irrelevant, making it more likely that
the plain icon is appropriate to use for a mask as well, and there's
no difference in behavior if you're using opaque colors.  (No
difference in functionality overall, either; you just achieve
partial-transparency with alpha rather than color.)

~TJ

Re: [whatwg] A mask="" advisory flag for

[Elliott Sprehn]

On Tue, Jun 16, 2015 at 12:43 PM, Maciej Stachowiak  wrote:

>
> > On Jun 15, 2015, at 5:40 PM, Justin Dolske  wrote:
> >
> > 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) 
> > B) 
> >
> > And if  someone actually did want the same icon for both, they could do:
> >
> > C) 
>
> That isn’t how I interpreted Elliot’s proposal.
>
> That said, if we do make a new standalone rel value for mask icons, I
> would suggest "mask-icon" or something like that instead of "mask", since
> mask is too generic a term.
>


I'm fine with either interpretation, mask-icon or "icon mask" like
"alternate stylesheet". I don't think adding a mask attribute to the
HTMLLinkElement for this makes sense.

- E

Re: [whatwg] A mask="" advisory flag for

[Taylor Hunt]

If reuse of the same SVG `rel="icon"` is desirable, would it be
possible to have certain elements inside the SVG use `class="mask"` or
something similar?


--Taylor Hunt

On Tue, Jun 16, 2015 at 3:47 PM, Maciej Stachowiak  wrote:
>
> There’s no technological enforcement that the SVG only uses the color black. 
> We will interpret it as a mask in the same way as the SVG ‘mask’ element, 
> which effectively combines the luminance with the alpha channel. Effectively, 
> this means that other colors will end up partly transparent, so using other 
> colors will probably do something weird, but nothing prevents authors from 
> doing that afaik.
>
> The reason for treating the icon as a mask is that we want to enforce having 
> a monochrome shape, specifically for our pinned tabs feature.
>
> Regards,
> Maciej
>
>> On Jun 15, 2015, at 6:52 PM, Nils Dagsson Moskopp 
>>  wrote:
>>
>> 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  writes:
>>
>>> Nils,
>>>
>>> Le 16 juin 2015 à 10:03, Nils Dagsson Moskopp 
>>>  a écrit :
 Edward O'Connor  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
>> 
>

Re: [whatwg] A mask="" advisory flag for

[Nils Dagsson Moskopp]

You could just set the colors of all paths to black internally and
derive a suitable mask from any SVG logo that way. See any error?

Maciej Stachowiak  writes:

> There’s no technological enforcement that the SVG only uses the color black. 
> We will interpret it as a mask in the same way as the SVG ‘mask’ element, 
> which effectively combines the luminance with the alpha channel. Effectively, 
> this means that other colors will end up partly transparent, so using other 
> colors will probably do something weird, but nothing prevents authors from 
> doing that afaik.
>
> The reason for treating the icon as a mask is that we want to enforce having 
> a monochrome shape, specifically for our pinned tabs feature.
>
> Regards,
> Maciej
>
>> On Jun 15, 2015, at 6:52 PM, Nils Dagsson Moskopp 
>>  wrote:
>> 
>> 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  writes:
>> 
>>> Nils,
>>> 
>>> Le 16 juin 2015 à 10:03, Nils Dagsson Moskopp 
>>>  a écrit :
 Edward O'Connor  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
>> 
>

-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] A mask="" advisory flag for

[Maciej Stachowiak]

There’s no technological enforcement that the SVG only uses the color black. We 
will interpret it as a mask in the same way as the SVG ‘mask’ element, which 
effectively combines the luminance with the alpha channel. Effectively, this 
means that other colors will end up partly transparent, so using other colors 
will probably do something weird, but nothing prevents authors from doing that 
afaik.

The reason for treating the icon as a mask is that we want to enforce having a 
monochrome shape, specifically for our pinned tabs feature.

Regards,
Maciej

> On Jun 15, 2015, at 6:52 PM, Nils Dagsson Moskopp 
>  wrote:
> 
> 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  writes:
> 
>> Nils,
>> 
>> Le 16 juin 2015 à 10:03, Nils Dagsson Moskopp 
>>  a écrit :
>>> Edward O'Connor  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
> 

Re: [whatwg] Relative URL plan

[Anne van Kesteren]

On Tue, Jun 16, 2015 at 8:29 PM, Boris Zbarsky  wrote:
> What optimizations are we talking about here, specifically?

Not sure. Was just indicating that we have that option if it would be
particularly painful/pointless/footgun. I haven't exactly thought it
through and there's not much feedback beyond http/https use cases.


> Note that my general view for how URL objects should work internally in
> Gecko is that we should have an immutable backing store and mutators that
> clone-with-modifications (basically copy on write).  Of course in terms of
> the web-exposed behavior we'd just have the web-exposed URL change which
> internal object it points to on mutation, so we can expose whatever mutators
> we want.

Makes sense. In retrospect I kind of wished new URL() at least started
out immutable, so it could become a native value in JavaScript some
day, but too late now.


-- 
https://annevankesteren.nl/

Re: [whatwg] A mask="" advisory flag for

[Maciej Stachowiak]

> On Jun 15, 2015, at 5:40 PM, Justin Dolske  wrote:
> 
> 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) 
> B) 
> 
> And if  someone actually did want the same icon for both, they could do:
> 
> C) 

That isn’t how I interpreted Elliot’s proposal. 

That said, if we do make a new standalone rel value for mask icons, I would 
suggest "mask-icon" or something like that instead of "mask", since mask is too 
generic a term.

 - Maciej


> 
> Justin
> 
> On Mon, Jun 15, 2015 at 4:20 PM, Maciej Stachowiak  wrote:
> 
>> 
>>> On Jun 15, 2015, at 3:55 PM, Elliott Sprehn 
>> wrote:
>>> 
>>> Adding a whole new attribute for this seems like overkill, why not use
>> the
>>> rel.
>>> 
>>> 
>>> 
>>> 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 
>>> wrote:
>>> 
 When  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:
 
   
 
 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] Relative URL plan

[Boris Zbarsky]

On 6/16/15 2:23 PM, Anne van Kesteren wrote:

Actually, it seems like you can, though that would equally affect data
URLs, but maybe that's not too bad. I guess for the API we could
special case a couple of schemes to not support reading/writing as
desired for optimizations.


What optimizations are we talking about here, specifically?

Note that my general view for how URL objects should work internally in 
Gecko is that we should have an immutable backing store and mutators 
that clone-with-modifications (basically copy on write).  Of course in 
terms of the web-exposed behavior we'd just have the web-exposed URL 
change which internal object it points to on mutation, so we can expose 
whatever mutators we want.


-Boris

Re: [whatwg] Relative URL plan

[Anne van Kesteren]

On Tue, Jun 16, 2015 at 8:18 PM, Boris Zbarsky  wrote:
> Why can't you?  If it's something you want to reason about as a separate
> entity, why doesn't it make sense to set it as a separate entity?

Actually, it seems like you can, though that would equally affect data
URLs, but maybe that's not too bad. I guess for the API we could
special case a couple of schemes to not support reading/writing as
desired for optimizations.


-- 
https://annevankesteren.nl/

Re: [whatwg] Relative URL plan

[Boris Zbarsky]

On 6/16/15 1:57 PM, Anne van Kesteren wrote:

On Tue, Jun 16, 2015 at 7:51 PM, Boris Zbarsky  wrote:

about: is not standardized enough across UAs to really reason about.


about and mailto are the reasons query is split out. Not so much that
you can set it (you can't)


Why can't you?  If it's something you want to reason about as a separate 
entity, why doesn't it make sense to set it as a separate entity?


-Boris

Re: [whatwg] Relative URL plan

[Boris Zbarsky]

On 6/16/15 1:18 PM, Anne van Kesteren wrote:

On Tue, Jun 16, 2015 at 7:01 PM, Boris Zbarsky  wrote:

about, data, etc.


data: doesn't use query in practice.  As in, any '?' that happens to be 
in there is totally accidental.


about: is not standardized enough across UAs to really reason about.

Hence my question: which schemes are not "special", widespread, and 
actually use '?' to mean something?  Specific use cases for this would 
make it clearer whether mutating the query is a meaningful operation.


-Boris

Re: [whatwg] Relative URL plan

[Anne van Kesteren]

On Tue, Jun 16, 2015 at 7:51 PM, Boris Zbarsky  wrote:
> about: is not standardized enough across UAs to really reason about.

about and mailto are the reasons query is split out. Not so much that
you can set it (you can't), but so that you can reason about it
independently. And since non-Gecko-browsers don't have a parser
per-scheme and that didn't really seem like a viable path forward
anyway, data follows that logic.


-- 
https://annevankesteren.nl/

Re: [whatwg] Relative URL plan

[Anne van Kesteren]

On Tue, Jun 16, 2015 at 7:01 PM, Boris Zbarsky  wrote:
> What are examples of non-relative URIs that use query?  mailto:, I guess?

about, data, etc. Though note that there's no such thing as
non-relative URL. That completely depends on the first code point
after the scheme and ":" in this brave new world.

As far as I can tell apart from special casing a couple of schemes
(now named special schemes in the URL Standard), everything else can
be completely generic at the parser level. Of course there's also a
level on top, e.g. for data URLs we'd look at scheme data + (query ?
"?" + query : "").

The non-special URLs have a couple of forms:

  non-special:non-relative-path
  non-special:/null-host-and-relative-path
  non-special://host/and-relative-path
  non-special:///empty-host-and-relative-path (supporting this for
special URLs is impossible due to reparsing issues)

and apart from non-relative-path can be manipulated quite easily.
Non-special URLs also don't have their host names IDNA-parsed.

I'm actually pretty happy this seems within reach as it makes URLs
much more extensible. I suppose we might still sometimes wish to make
tweaks to the parser (as we did for e.g. blob URLs), but overall this
should be much more compatible with the IETF POV.


-- 
https://annevankesteren.nl/

Re: [whatwg] Relative URL plan

[Boris Zbarsky]

On 6/16/15 12:55 PM, Anne van Kesteren wrote:

You're right, fragments make sense. Changing path (scheme data in the
specification) or query would be painful however.


I see no particular need to support changing path.

Not sure about query; Gecko doesn't support query to start with on what 
you describe as non-relative URIs (as in, it's considered part of 
"scheme data" for our purposes and we don't parse that at all) so I'm 
not sure what use cases there might be for it.


What are examples of non-relative URIs that use query?  mailto:, I guess?

-Boris

Re: [whatwg] Relative URL plan

[Anne van Kesteren]

On Tue, Jun 16, 2015 at 6:52 PM, Boris Zbarsky  wrote:
> On 6/16/15 8:06 AM, Anne van Kesteren wrote:
>>
>> I also think we should change the API such that you cannot change
>> anything for non-relative URLs
>
> Why would you disallow setting fragment for a non-relative URL?

You're right, fragments make sense. Changing path (scheme data in the
specification) or query would be painful however.


-- 
https://annevankesteren.nl/

Re: [whatwg] Relative URL plan

[Boris Zbarsky]

On 6/16/15 8:06 AM, Anne van Kesteren wrote:

I also think we should change the API such that you cannot change
anything for non-relative URLs


Why would you disallow setting fragment for a non-relative URL?

-Boris

Re: [whatwg] Icon mask and theme color

[Jasper St. Pierre]

On Tue, Jun 16, 2015 at 4:37 AM, Nils Dagsson Moskopp
 wrote:

[...]

> (5) Use the shape of the path in the SVG icon as a mask and retain the
> theme color meta value. Why isn't this done? One could have a properly
> colored icon for one purpose and use the outline of the same icon for
> the flat design staff.

Because colorful icons tend to be mostly squares with the color
defining the outline. GMail would want a stylized "M", not a white
rectangle. YouTube would probably want a play button, not a rounded
rectangle. Going through your bookmarks, I imagine you can come up
with other examples.

> --
> Nils Dagsson Moskopp // erlehmann
> 



-- 
  Jasper

[whatwg] Relative URL plan

[Anne van Kesteren]

I've been trying to figure out a better data model for URLs so we can
handle relative URLs for any scheme. The motivation for supporting
relative URLs for any scheme can be found here:

  https://www.w3.org/Bugs/Public/show_bug.cgi?id=27233

Per my testing the URL parser would still need special handling for
what the URL Standard currently calls relative schemes. I will rename
those special schemes since any URL would now in principle be able to
handle relative URLs.

Testing of Chrome and Safari shows that even data and javascript URLs
have no special handling here. E.g.

  input | base URL | output
  test  | javascript:/ | javascript:/test
  data:/../ | (none)   | data:/

If fore the first example you then set host to "test:81" you get
"javascript://test:81/test" in Safari. (Though if you set host to
"/test:81" you get "javascript:///test:81/test" which seems bad. I
will treat that as a bug.)

This gives us three types of URLs:

* Special URLs. file/http/https/etc. These need to handle three
slashes after the scheme as two, can treat lack of slashes as
relative, etc.
* Relative URLs. All non-special URLs where the scheme is followed by a slash.
* Non-relative URLs. All non-special-non-relative URLs.

Non-relative URLs consist of {scheme, scheme data, query, fragment}.
Relative URLs and special URLs consist of {scheme, username, password,
host, port, path, query, fragment}. Special URLs cannot have an empty
host (as that would lead to reparsing issues), relative URLs can.
Relative URLs can also have a missing host (see javascript:/ above).

I think we should try to restrict backslash replacement and the
encoding override to special URLs.

I also think we should change the API such that you cannot change
anything for non-relative URLs (setters are no-ops, already largely
the case). And that you cannot change the scheme from a special URL to
a relative URL. Given the different handling of hosts that might lead
to security issues.

I will start rolling this out and write a bunch of tests. Even though
both Chrome and Safari implement this they have differences and some
logical inconsistencies that I think would be great to remove. I hope
to get feedback on what we cannot do from the above. Hopefully Firefox
not implementing any of this provides some wiggle room.


-- 
https://annevankesteren.nl/

Re: [whatwg] Icon mask and theme color

[Nils Dagsson Moskopp]

Maciej Stachowiak  writes:

> […]
>
> 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.

(4) Set a MIME type like application/vnd.apple.svg-mask+xml. This might
prevent breakage in other browsers and allow opt-in without introducing
new attributes. The source of the theme color could then be in the file
or in the theme color meta value.

(5) Use the shape of the path in the SVG icon as a mask and retain the
theme color meta value. Why isn't this done? One could have a properly
colored icon for one purpose and use the outline of the same icon for
the flat design staff.

-- 
Nils Dagsson Moskopp // erlehmann