[whatwg] The sizes="" attribute for rel=icon

[Ian Hickson]

On Thu, 8 May 2008, Martin Atkins wrote:
> > 
> > That isn't to say that media queries shouldn't be allowed, though, and 
> > if people use them then they should work, if the UA supports them.
> 
> Would it not be better to explitly say that media queries are not 
> appropriate for this, for interoperability?

I'd rather not preclude that people implement support for it, I just don't 
want such support to be required. Sometimes we get lucky and things like 
this take off, at which point I'd be more than happy to require it. :-)


> In general I agree that attributes are not a scarce resource, but if you 
> need to add use-specific attributes to a supposedly-generic element I 
> think that indicates that the generic element is inappropriate for the 
> use-case.

I disagree. Look at <input>, for instance.


> I don't know what link rel type uses "disabled", but I would have had 
> the same objection to that.

rel=stylesheet.


> If the meaning of "title" is something different for stylesheets than 
> for other link rel types then that was an inappropriate use of that 
> attribute as well. It's too late to change it now, but that's no reason 
> to continue overloading generic elements/attributes with special cases.

I don't think the overloading in this case is a big deal. It's not like 
<object>, it's not even as bad as <input>.


> link is also interesting in that unlike <input type="..."> rel can 
> contain several values. Is it conforming to use [sizes] on a link 
> element that contains both "icon" and a another, non-icon keyword?

Sure.


> What about <a rel="icon" ... width="..." height="..."> ?

rel=icon doesn't apply to <a href>.


> Finally, what is the process for contributors to the RelExtensions page 
> to include extension attributes?

They can't.


> > > <link rel="icon" type="image/gif; width=24, height=24" href="...">
> > 
> > This doesn't really work because we would need to add parameters to 
> > types we might not yet know. It also results in potentially 
> > complicated parsing rules, which I don't think people would get right. 
> > (See the comments I made for media queries.)
> 
> Presumably this would be defined (if at all) for everything under 
> "image/", just as "charset" is defined for everything under "text/". (In 
> theory, at least.)

Getting the relevant RFCs changed would likely be non-trivial. (Though we 
should probably look into it, actually, to fix text/*.)


On Fri, 9 May 2008, Kornel Lesinski wrote:
> > 
> > If multiple icons are provided, the user agent must select the most 
> > appropriate icon according to the media and sizes attributes. If there 
> > are multiple equally appropriate icons, user agents must use the first 
> > one declared in tree order.
> 
> Does this disallow composing .ico files from multiple separate files? 
> UAs like Fluid or Prism can't know which sizes OS is going to use, so 
> all valid ico sizes are 'equally appropriate'.

Sure, the OS just becomes part of the UA in that case. The effect is the 
same.


> Also this algorithm doesn't match current browser behaviour, is this
> intentional?
> I did a quick test with a bunch of random favicons:
> * Opera 9.5b2 loads all icons (that's pretty bad if one decides to provide
> Leopard's monsterous 300KB icons) and displays last icon loaded,
> * Firefox 3b5 picks last icon regardless of attributes. It loads all icons
> when I reload page after restoring session.
> * WebKit nightly and Fluid pick last icon that has type attribute (even if
> type is bogus), or just last if none have type.

I've changed the spec to say to use the last one specified in case of 
ties.


> I'm afraid that this could cause trouble (every visitor downloading icon 
> that's 20–300 times larger than typical favicon). Why not use 
> rel=application-icon or rel=appicon?

I don't understand the question.


> I don't like the "any" keyword. SVG icons are scallable, but it's not 
> the same as being usable at any size. For example Tango icons project 
> provides PNG for 16, 22 and 32px icons in addition to SVG, because lines 
> and finer details in SVG become illegible at small sizes.

The spec allows the UA to make that distinction.


> Does the specified size imply that UA is required to display icon at 
> given size only? (i.e. is "any" obligatory to have icon scaled at all?)

The spec doesn't say what the UA is to do with the icon.


> What if sizes attribute is absent?

I've clarfieid this case.


On Thu, 8 May 2008, Ernest Cline wrote:
> 
> Mainly, I am troubled by the statement:
>   "The keywords specified on the sizes attribute must not represent icon 
> sizes that are not actually available in the linked resource."
> 
> No matter what the spec says, I think we can all agree that once this 
> enters the real world there will be times when the icon size given is 
> wrong.  So what to do?

I've added a requirement in the spec that if an icon is found unsuitable, 
the next one must be tried.


On Thu, 8 May 2008, Aaron Boodman wrote:
> 
> I agree that mismatches will occur in the real world. I think it can be 
> left to the UA as to what to do in that case, as it is a developer 
> mistake.

HTML5 defines handling of developer mistakes. :-)


On Fri, 9 May 2008, Aaron Boodman wrote:
> 
> I think the difference is that there is no defined use for the hints in 
> the first place, hence it is not a big deal to define what to do in the 
> case of error. The UA can decide whether to use the hints, and for what, 
> and what to do in the case of them being wrong.

As the spec is defined, it's left up to the UA to decide whether or not an 
icon is "appropriate", so yes, what you suggest is allowed.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'