[whatwg] <link rel=icon width=

[Philipp Serafin]

I'd like to plug the approach with MIME parameters again, because it
seems by far the most elegant and clean to me.

However, instead of specifying multiple sizes in one MIME parameter,
couldn't we just define two parameters "width" and "heigth" (and
perhaps a "ratio" for graphics without inherent boundaries) and use
Charles' mechanism with multiple <link> elements to list multiple
sizes?

An example would be:

<link type="icon" type="application/svg" href="whatwg.svg">

<link type="icon" type="image/microsoft.vnd.icon; width=16; height=16"
href="whatwg.ico">
<link type="icon" type="image/microsoft.vnd.icon; width=32; height=32"
href="whatwg.ico">

<link type="icon" type="image/x-apple-icons; width=16; height=16"
href="whatwg.icns">
<link type="icon" type="image/x-apple-icons; width=32; height=32"
href="whatwg.icns">
<link type="icon" type="image/x-apple-icons; width=64; height=64"
href="whatwg.icns">
<link type="icon" type="image/x-apple-icons; width=128; height=128"
href="whatwg.icns">
<link type="icon" type="image/x-apple-icons; width=256; height=256"
href="whatwg.icns">
<link type="icon" type="image/x-apple-icons; width=512; height=512"
href="whatwg.icns">

<link type="icon" type="image/png; width=59; height=60" href="whatwg.png">

I agree that this looks ugly at first glance, but it has a certain
inner beauty if you think about it a bit longer.

I think Maciej is right, that the least thing we need is yet another
micro language that tries to cram more values into an attribute than
it's healthly. However, in this case, we can leave out the "yet
another". MIME types are already widely used and the capabillites to
process them already exist on both client side and server side.

Also, as already mentioned, width and heigth attributes don't make
much sense on <link>, because they are only applicable for a very
small subset of <link> use cases. However, they do make sense as
parameters for the top level MIME type image/*. Almost all images have
- if not an intrinsic size - at least a number of bounds they can be
viewed best in. So if you define those parameters as "optimal size for
this image", it would both solve the requested problem and fit nicely
in the whole content negiotation scheme that MIME is mostly used for
on the web.

UAs that already use the "type" attribute to choose the most suitable
URI for a <link> might not need to add much existing functionality. If
they preferred, let's say, favicons in 16x16, they would just need to
priorize images of the "type" "image/microsoft.vnd.icon; width=16;
height=16" in the same way they would priorize - let's say - image/png
over image/gif before.

What are the opinions on this?