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

On Apr 29, 2008, at 11:54 PM, Charles Iliya Krempeaux wrote:

>
> I don't really prefer one to the other, just considering the  
> possibilities we have at hand.
>
> My current thinking is that you can go one of 2 ways.
>
> #1: Pack everything into in <link> element.  (I.e., what you were  
> suggesting.) Or...
> #2: Expand everything into its own <link> element.  (I.e., what I  
> was suggesting.)
>
> My thinking is that... we're now considering adding width and height  
> info (via one or two new attributes)... but I could see this  
> progressing to adding other new attributes too (... perhaps in  
> HTML5... or perhaps in version of HTML after that).
>
> For example... if we have width and height now... well why not info  
> about the number of bits used for the colors?!  Why not info about  
> if the coloring is palleted or not?!  Or if the image format uses  
> lossless compression or lossy compression?!  Or the size of the  
> file?!  Etc....

In practice, these things usually do not matter when using an icon in  
the user interface. But the sizes available do matter. I would not  
want to download a 512x512 icon for use as an iPhone homescreen icon  
(it's not anywhere near the right size) but it is irrelevant whether  
the compression is lossy or how colors are represented. I would prefer  
a multisize icon with a wide size range for Mac OS X or Windows Vista  
but not for Windows XP or most mobile platforms.

>
>
> If we have this new attribute(s) available on the <link> element,  
> then it is very likely going to be used for other things besides  
> just icons.
>
> You could use width and height for videos too.  What if video wants  
> to be able to "declare" that the video has "closed captioning"  
> embedded or not?!  Or what language the video file has audio for?!   
> ("hreflang" would almost work for that... if it let you specify more  
> than one language.)  Or`what "ratings" that version of the video is?!
>
>
> What I was getting at with this suggestion is that if we start  
> adding the ability to specify all sorts of metadata about what's  
> being linked to and go along the path of #1, then we likely need to  
> create a kind of complex language to describe this.  (Something  
> approaching the complexity of CSS.)  And perhaps that's complicating  
> the <link> element too much.
>
> Maybe it's simpler to (do #2 and) just create a <link> for each thing.

I'm not sure I understand this. Your proposal amounts to adding two  
new attributes to the <link> element, "width" and "height" (and  
possibly specifying a link of the same type to the same item multiple  
times). My proposal involves a single new attribute on <link>, with  
essentially the same information conveyed in a more compact way. Why  
does my proposal lead to a CSS-like general-purpose metadata language,  
but yours does not?

Regards,
Maciej

Received on Wednesday, 30 April 2008 00:19:22 UTC