[whatwg] <link rel=icon width=

[Ernest Cline]

-----Original Message-----
>From: Smylers <Smylers at stripey.com>
>Sent: May 1, 2008 3:02 AM
>
>Ernest Cline writes:
>
>> > ... proposal to add "height" and "width" attributes to <link>
>> > specifically for the case of rel=icon, so that authors can provide
>> > multiple icons and let the UA decide which to use based on their
>> > size
>> 
>> Maybe I'm missing something obvious, but why wouldn't:
>> <link rel=icon style="width: 16px; height:16px"> 
>> serve to mark width and height adequately?
>
>* The style attribute says _how_ to display something, not what that
>  something _is_.  The above says: "Ignore the icon's intrinsic size and
>  scale it to 16 x 16."

Unless width and height attributes for link are going to behave differently than they do on other elements, that's the behavior they'd have anyway. (See section 3.12.17 Dimension attributes)  If new attributes are added to the link element to represent the intrinsic size of an object, then at the very least they should have different names and not confuse things by assigning two separate meanings to height and width based on the element they are attached to.

>* CSS is optional, so browsers shouldn't be forced to use it to find out
>  some meta-data.  And if a user had elected to turn off CSS for
>  displaying in pages, would a browser still be permitted to use it for
>  this purpose?

The whole use of <link rel=icon> is a stylistic concern in the first place.  Limiting the optimal use of rel=icon to instances in which CSS is used does not strike me as an excessive burden.

>* Nested attribute syntax is more awkward and error-prone than having
>  width and height directly on the element.

Maybe slightly, but is it enough of an advantage to outweigh the added browser overhead needed to add support for two attributes to every instance of link even tho it is useful to only one particular linktype, particularly since support for the alternative I offered needs to be available in the first place. 

>> It's even perfectly fine HTML 4 syntax.
>
>Why is that interesting?  If it's syntax that current browsers already
>do something useful with then that's a big point in its favour; but if
>it's something which is currently a no-op then that it happens to be
>syntactically permitted in an older standard doesn't seem like a benefit
>over any other syntax which browsers currently ignore.

I can't say if any current browsers currently make use of it, but it is syntax they need to be able to handle in some manner.  One strong argument for using the style attribute instead of adding new attributes is that it does not increase the amount of overhead a browser is expected to handle.