W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2015

[whatwg] A mask="" advisory flag for <link rel=icon>

From: Edward O'Connor <eoconnor@apple.com>
Date: Mon, 15 Jun 2015 10:37:51 -0700
To: whatwg@whatwg.org
Message-ID: <m2h9q8swi8.fsf@apple.com>
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.


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.
Received on Monday, 15 June 2015 17:38:17 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:32 UTC