[whatwg] <link rel=icon width="" height="">

[Maciej Stachowiak]

On May 2, 2008, at 12:24 AM, fantasai wrote:

> Maciej Stachowiak wrote:
>>
>>>
>>> This might require that existing browsers cope correctly (or  
>>> exploit duplication/error behaviors), but could a MIME parameter  
>>> address this without needing another attribute at all?  That's the  
>>> most narrowly scoped change I can imagine that would address the  
>>> need.
>>>
>>>> <link rel="icon" type="application/svg; sizes=any"  
>>>> href="whatwg.svg">
>>>> <link rel="icon" type='image/microsoft.vnd.icon;  
>>>> sizes="16x16,32x32"' href="whatwg.ico">
>>>> <link rel="icon" type='image/x-apple-icons;  
>>>> sizes="16x16,32x32,64x64,128x128,256x256,512x512"'  
>>>> href="whatwg.icns">
>>>> <link rel="icon" type="image/png; sizes=59x60" href="whatwg.png">
>>>
>>> Restrictions on what a parameter value may be (basically can't  
>>> contain any separators or whitespace) are a touch confounding here  
>>> because you don't have any separators unless you quote; that  
>>> probably factors into the equation here.
>> I'm not against using a MIME parameter per se, but it would have to  
>> be x-prefixed (unless we register it) and I'd strongly prefer a  
>> syntax that does not require use of nested quotes.
>
> If I'm reading the spec correctly
>  http://www.faqs.org/rfcs/rfc2045.html
> you could use '+' as a separator.
>  sizes=16x16+32x32+64x64
>
> For SVG icons, you'd probably want the ability to specify a ratio  
> instead.
> (And I suppose for sound icons, you'd want the length of the sound  
> clip...)
>
> Also, I didn't see anything in the spec about parameters needing to be
> prefixed, only subtypes. Maybe I missed it.

That seems like an adequate solution, though syntactically less  
elegant than a new attribute IMO.

I think specifying aspect ratio and specifying duration of sound clip  
are less compelling information to provide than icon sizes. This  
information is intended to help determine which of possibly several  
icons are appropriate for use in native UI contexts, without having to  
download them. The last 3 of my 4 examples would be the best choices  
for Windows XP, Mac OS X, and iPhone respectively, as icons for  
documents or applications in the native UI. The Apple ICNS format  
would actually be a better choice for Windows Vista, despite the file  
format, because Vista HI guidelines call for availability of large  
icons and format conversion would be a better choice than the large  
sizes. So this information is not just redundant with the MIME type.

My first example (the SVG) could be used anywhere if UA understands  
SVG and can render down to the specific sizes needed by the computing  
environment. But it may not be feasible for all artwork to be provided  
in vector format and in any case it may not scale well to tiny sizes  
such as 16x16.

By contrast, I do not know of any actual need to determine the aspect  
ratio of an SVG icon or the duration of a sound icon. I do not know of  
cases where HI guidelines for particular platforms would recommend  
different choices of icon aspect ratio or sound icon duration. Thus, I  
suggest we limit ourselves to adding only the info that is actually  
known to be needed at this time. If UI innovation creates a need for  
more info, we can add it to the spec then.

Regards,
Maciej