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

[Martin Atkins]

Ian Hickson wrote:
> 
>> 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 wouldn't have designed <input> as it is either. It seems arbitrary 
(and initially, confusing) to me that most form elements share one 
element but then a random handful have their own custom elements. (I 
guess you might argue, though, that <textarea> and <button> ought to be 
<input> types rather than the other way around.)

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

Without wishing to take this thread off on a tangent (in other words, 
feel free not to address this here except as relates to the discussion 
at hand) I wonder what use-case motivated that attribute that couldn't 
have been satisfied by merely removing the LINK element from the DOM. 
Or, if you wish to attack it from the other direction, why a generic 
solution for causing browsers to temporarily ignore *any* HTML element 
(a use case for which might be pop-up dialogs that are hidden at certain 
points) wasn't more appropriate.

Also, I note that the spec as it currently stands defines "disabled" 
only as a property of the HTMLLinkElement and not as an attribute of the 
LINK element. I don't know if this was intentional. Of course, I could 
very well make the same objection about a type-specific property on a 
class being better implemented by creating a new class.

(In other words, I don't find the disabled attribute on LINK to be a 
compelling argument for overloading elements either.)

> 
>> Finally, what is the process for contributors to the RelExtensions page 
>> to include extension attributes?
> 
> They can't.
> 

Given that you obviously consider it useful for third-parties to be able 
to introduce new rel values without changing the HTML5 spec, and that 
you also obviously consider it useful for certain rel values to carry 
additional attributes, I find it likely that some of these third-parties 
will also find it useful to introduce additional attributes. Would you 
not agree?


>>>> <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/*.)
> 

Given that (for now, at least) these type attributes would be of little 
use outside of HTML, could HTML not define them itself? Sure, it's a bit 
of a layering violation, but I would put it in the same boat as 
modifying MathML/SVG so that it works inside HTML: you just reference 
the bits of the other spec that suit you, and make your own exceptions, 
right? (loud objections from the MathML guys notwithstanding, of course. 
The MIME type RFC isn't authored by a W3C working group, so they won't 
find it so easy to complain!)

> On Fri, 9 May 2008, Kornel Lesinski wrote:
>> 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.
> 
[snip]
> 
>> 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 know exactly what Kornel was asking, but this seems to be a 
backward-compatibility concern. When given the following:

<link rel="icon" sizes="16x16" ... />
<link rel="icon" sizes="512x512" ... />

...current Opera will download both, which is suboptimal however you 
look at it. Current Firefox, though, will presumably download the 
512x512 version in preference to the 16x16 one even though its icon slot 
is (usually) 16x16 pixels.

I guess this concern would be solved (aside from Opera's behavior) if 
the spec were to say that a 16x16 icon, if specified, should be the last 
one listed for compatibility with legacy browsers.

(Also, a 9.5 beta tester should probably inform Opera of that issue if 
they aren't already aware of it.)