- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 02 May 2008 00:24:08 -0700
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
Received on Friday, 2 May 2008 00:24:08 UTC