[whatwg] <link rel=icon width="" height="">
mjs at apple.com
Wed Apr 30 00:19:22 PDT 2008
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?
More information about the whatwg