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.

~fantasai

Reply via email to