- From: Charles Iliya Krempeaux <supercanadian@gmail.com>
- Date: Wed, 30 Apr 2008 00:41:49 -0700
Hello, On Wed, Apr 30, 2008 at 12:19 AM, Maciej Stachowiak <mjs at apple.com> wrote: > > On Apr 29, 2008, at 11:54 PM, Charles Iliya Krempeaux wrote: > [...] > > 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. True... for an iPhone that might be the case. Or even Mac OS X or Windows Vista. But it might become important in usages of this metadata beyond just icons. For example, consider a photo blogging example... <link rel="enclosure" type="image/png" width="64" height="48" compressioning="lossless" coloring="paletted" href="A.png"> <link rel="enclosure" type="image/png" width="640" height="480" compressioning="lossless" coloring="truecolor" href="B.png"> <link rel="enclosure" type="image/png" width="640" height="480" compressioning="lossless" coloring="grayscale" href="C.png"> <link rel="enclosure" type="image/jpeg" width="2560" height="1920" compressioning="lossy" coloring="truecolor" href="D.jpg"> (The bottom <link> if the original image. The 2 640x480 onews are scaled version... one color and one grayscale. And the top one is a thumbnail.) > > > > > > 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? > It leads to a CSS-like language only if we start adding more metadata in there besides just the width and height. For example, this... <link rel="enclosure" type="image/xxx" width="640" height="480" compressioning="lossy" coloring="truecolor" href="A.xxx"> <link rel="enclosure" type="image/xxx" width="1280" height="960" compressioning="lossy" coloring="truecolor" href="A.xxx"> <link rel="enclosure" type="image/xxx" width="2560" height="1920" compressioning="lossy" coloring="truecolor" href="A.xxx"> ... could become... <link rel="enclosure" type="image/xxx" metadata="size:640x480, 1280x960, 2560x1920; compressioning:lossy; coloring:truecolor;" href="A.xxx"> The "metadata" attribute is where you start to get a CSS-like language. (Which seems to complicate the <link> element.) See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ Vlog Razor... Vlogging News... http://vlograzor.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080430/79a7e30f/attachment.htm>
Received on Wednesday, 30 April 2008 00:41:49 UTC