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