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

[Ian Hickson]

I've added a "sizes" attribute to <link> for the "icon" keyword. It takes 
a space separated list of keywords consisting of two integers separated by 
an "x" or the keyword "any".


GENERAL NEED

On Wed, 30 Apr 2008, Ian Hickson wrote:
> 
> The Gears team has an API that allows authors to specify a set of icons:
> 
>    http://code.google.com/apis/gears/upcoming/api_desktop.html
> 
> They used a scripted API, but when I tried to get them to use a 
> declarative API, they said that the main reason they used a scripted one 
> is that the declarative options didn't have a way to specify dimensions.

On Tue, 29 Apr 2008, Maciej Stachowiak wrote:
> 
> I think a way to specify multiple icons at different sizes is a good 
> idea. However, I do not think width and height attributes sufficiently 
> cover the available options. We need to be able to handle:
> 
> 1) Scalable vector formats such as SVG or PDF. These work well at any 
> size. On some Linux desktop environments, SVG is used as a native icon 
> format.
> 
> 2) Formats that include bitmaps at multiple sizes. These include the 
> Windows native ICO format and the Mac OS X native ICNS format. At least 
> for Mac OS X, the HI guidelines strongly recommend providing multiple 
> sizes for best integration with the system UI. It is possible in theory 
> for a UA to download multiple icons at different sizes and build a 
> multi-size file, but more network transactions is less efficient.
> 
> Therefore, I think it needs to be possible to specify multiple sizes, or 
> to specify that an icon is scalable and thus usable at any size.

On Tue, 29 Apr 2008, Aaron Boodman wrote:
> 
> FWIW, the reason we want this as opposed to just trying all the icons is 
> that we want to be able to render a confirmation UI that contains the 
> icon immediately, without having to wait for all the icons to download.

On Wed, 30 Apr 2008, Michael(tm) Smith wrote:
> 
> I notice the docs for the "icons" param of the Gears createShortcut() 
> method describe four discrete sizes that all have the same height and 
> width ("An object containing one or more of these named properties: 
> 128x128, 48x48, 32x32, 16x16...").
> 
> So do UAs expect link at rel=icon icons to always have the same height and 
> width, and if so should the HTML5 spec make it clear that their height 
> and width should be the same?

On Tue, 29 Apr 2008, Maciej Stachowiak wrote:
> 
> Not all platforms use icons that have the same width and height. For 
> example, the standard size for iPhone icons is 59x60.

On Wed, 30 Apr 2008, timeless wrote:
>
> i have an icons collection from when microb team did favicon work and i 
> distinctly recall one of the icons as being non square :)
> 
> http://www.linuxworld.com/favicon.ico
> 
> a quick recheck shows it's the only one. it's 50x51, which always struck 
> me as odd.

On Wed, 30 Apr 2008, Michael(tm) Smith wrote:
> 
> I'd suppose along with that and Maciej's example of the iPhone 59x60 
> icons, there are probably a few other examples and that non-square icons 
> are maybe not so uncommon after all.
> 
> Anyway, I guess I don't understand what the current (or expected) 
> behavior is for handling the general case of multiple link at rel=icon 
> instances within the same document, when the icons can be of any 
> arbitrary size (whether or not the size is given explicitly as is being 
> proposed).
> 
> I can understand the specific case like that of building a Gears 
> application and including link markup to provide a set of icons in the 
> particular dimensions that conform to the Gears Desktop API.
> 
> But especially if we were to add some means for dimensional markup to 
> link (height/width attribute, sizes attribute, or whatever), and we want 
> UAs to interoperably handle the case of multiple icons of various sizes 
> being present, I'd wonder if the spec should describe what the behavior 
> is meant to be.
> 
> In fact, since it's already possible to have multiple link icon 
> instances in arbitrary sizes (just without the sizes being given 
> explicitly in the markup), it seems like regardless of whether some new 
> means for dimensional markup does end up being added, the expected 
> behavior for the case of multiple link icons is already something that 
> the spec maybe should try to address (that is, along with the case it 
> already addresses of multiple instances with different media 
> attributes).

On Mon, 5 May 2008, Kornel Lesinski wrote:
>
> I don't think it's that important to specify exact icon sizes. Authors 
> won't bother to accurately provide such detailed information, and 
> applications don't need it anyway.
> 
> iPhone shouldn't be a concern here. It isn't limited to 59x60 
> icons—Apple's own website uses 129x129 
> (http://www.apple.com/apple-touch-icon.png) and current EDGE network 
> iPhones won't use anything else than rel=apple-touch-icon.
> 
> My suggestion is to simply define rel=application-icon without extra 
> attributes.
> 
> There isn't much bandwidth to be saved. These icons are going to be 
> downloaded only once. 128x128 PNG icons take only 20-30kb.
> 
> Large PNG file + favicon for smallest sizes may be good enough in most 
> cases. In cases when icon design doesn't scale well, authors could 
> provide additional .ico/.icns files.
> 
> When website provides application icons (not favicon) in .icns or .ico 
> files, I think it can be reasonably assumed that these files contain all 
> sizes that are needed for desktop icons, and it doesn't matter which 
> exactly.

On Mon, 5 May 2008, Aaron Boodman wrote:
> 
> Without hints as to which file contains which size, the user agent must 
> download up to four separate images before using them. The latency this 
> causes is unacceptable for many use cases.

On Tue, 6 May 2008, Kornel Lesinski wrote:
> 
> It doesn't have to download four images. For purpose of instant preview, 
> UA can display first file it downloads.
> 
> And you don't have to use many files, because larger files can (usually) 
> be scaled to smaller sizes.
>
> When one file isn't good enough, authors could provide additional 
> ico/icns which can have best quality OS can handle, e.g:
> 
> <link rel=icon href="favicon.png" type="image/png"> <!-- 16 or 32px -->
> <link rel=application-icon href="appicon.png" type="image/png"> <!-- 128px,
> ~25kb -->
> <link rel=application-icon href="appicon.ico" type="image/x-ico"> <!--
> possibly all sizes between 16 and 256px, ~90kb -->
> 
> UA could assume that ico/icns offers better quality on platform that 
> supports this file format and also that this file is going to be larger 
> (because it contains set of images as opposed to single image).

Ok so from the above we get the following requirements:

 * Allow the UA to display the best icon from a set of differently sized 
   icons that represent the page
 * Low latency (enable the UA to only fetch one image)
 * Handle non-square icons
 * Handle non-bitmap icons
 * Handle icon files that contain more than one size


PROPOSAL: height=""/width=""

On Wed, 30 Apr 2008, Ian Hickson wrote:
> 
> This is a proposal to add "height" and "width" attributes to <link> 
> specifically for the case of rel=icon, so that authors can provide 
> multiple icons and let the UA decide which to use based on their size 
> (without having to download them all to find out which is best).

On Tue, 29 Apr 2008, Charles Iliya Krempeaux wrote:
>
> [You can do this with this proposal, e.g.:]
> 
> <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">
>
> [...]
> 
> Basically <link>'ing to the same "icon" more that once for each size it 
> is "good" for.

On Tue, 29 Apr 2008, Maciej Stachowiak wrote:
> 
> This may not be obvious to authors.
>
> It's more boilerplate for the author.
>
> It's [too much] work for the UA to process (if it prefers a multisize 
> icon it has to look for all icon type links and merge references to the 
> same file).
>
> It does not distinguish between scalable icon and icon where the author 
> did not specify a size (which would be all icons present in existing 
> link attributes).

On Thu, 1 May 2008, Ernest Cline wrote:
>
> If new attributes are added to the link element to represent the 
> intrinsic size of an object, then at the very least they should have 
> different names and not confuse things by assigning two separate 
> meanings to height and width based on the element they are attached to.

On Tue, 29 Apr 2008, Charles Iliya Krempeaux wrote:
> 
> For vector formats, that can be scaled to any size, it might be a good 
> idea to be able to specify the aspect ratio somehow.
> 
> For example, if the aspect ratio of one vector format icon is 4:3 and 
> the other 16:9, then it would be a "good" idea to be able to specify 
> those somehow.
> 
> So possibly something like...
> 
> <link type="icon" type="application/svg" width="4*" height="3*" 
> href="A.svg">
> 
> <link type="icon" type="application/svg" width="16*" height="9*" 
> href="B.svg">
> 
> (Note, I used the N* format to specify that the width and height are 
> ratios rather than pixel measurements.  For some reason I remember 
> seeing these used on <col> elements before... although I couldn't find 
> anything like it in doing a quick look over the the HTML5 spec.  So 
> maybe those didn't come from the spec.)

This proposal doesn't really handle icon files that contain more than one 
size -- specifying the same icon multiple times is ugly and annoying.


PROPOSAL: sizes=""

On Tue, 29 Apr 2008, Maciej Stachowiak wrote:
> 
> I would suggest a sizes attribute which can take a list of sizes (with x 
> as a width/height separator), or a keyword such as "any" or "scalable" 
> to indicate a scalable format suitable for any size.

I've used this proposal.


PROPOSAL: Use media queries

On Wed, 30 Apr 2008, Martin Atkins wrote:
> 
> <link type="image/png"
>       media="all and (max-width:16px and max-height:16px)">
> 
> Here I'm assuming that "the rendering surface of the output device" as 
> referred to by Media Queries[1] section 5.1 is the rectangle of pixels 
> that the icon is going to be rendered within, which I suppose is a 
> slight deviation from the meaning when rel="stylesheet", but I find it 
> to be intuitive.
> 
> [1] http://www.w3.org/TR/2007/CR-css3-mediaqueries-20070606

On Wed, 30 Apr 2008, Lachlan Hunt wrote:
> 
> No, because the media queries are related to the actual tech specs of 
> the device, not the image.  I'm fairly sure there are no 16x16px screens 
> in use, at least not for the web.  To get appropriate behaviour for what 
> you're suggesting here would require redefining and special casing media 
> queries.

On Thu, 1 May 2008, Martin Atkins wrote:
> 
> When I shrink my browser window down so that its viewport is 16x16px 
> (assuming that it'd let me do such a thing) it's quite happy to apply a 
> stylesheet with the above media query. It seems, therefore, that the 
> "width" and "height" constraints relate to the rendering viewport and 
> not to the device.
> 
> The only "leap of faith" I see here is that when rel="stylesheet" we're 
> talking about the width of the source document's viewport -- because 
> stylesheets don't have a viewport of their own -- but in the icon case 
> we'd be describing the *icon* viewport i.e. the box into which the icon 
> will be rendered.
> 
> device-width and device-height seem to be more like what you're 
> describing, though I'm not sure why you'd ever want to use these since 
> browsers rarely inhabit the entire physical display even on mobile 
> devices.

On Thu, 1 May 2008, Lachlan Hunt wrote:
> 
> Yes, I meant "device and viewport" above.  But even if you want to apply 
> this to a special icon viewport, it still wouldn't work as you expect, 
> because what we need is something that describes the properties of the 
> image, not the properties of viewport it's being rendered in.
> 
> Given a UA that can display any icon size up to, e.g., 128px square, the 
> above media query wouldn't match.  But what if the author only provided 
> icons up to 64x64px, then no media query would match and no icon would 
> be used.  However, for this use case, the UA would need to pick the 
> highest quality image that is suitable for the environment.
> 
> You couldn't eve get away with using min-width/height here, because UAs 
> generally stretch and scew icons to fit the necessary size, and say a 
> 60x60 icon provided, and specified as:
> 
>   "all and (min-width:60px) and (min-height:60px)"
> 
> Then the iPhone, for example, wouldn't pick it because it needs 59x60. 
> Where there isn't a perfect size available, the UA needs to be able to 
> pick one that is slightly smaller or larger and stretch it to fit.

On Fri, 2 May 2008, Martin Atkins wrote:
> 
> I believe the use-case we're discussing is the selection of an 
> appropriate icon to display at a size determined by the UA. Specifying 
> the physical dimensions of the image itself is one way to do that. 
> Allowing the author to make statements like "this icon is only suitable 
> at 16x16px" is another.
> 
> The latter allows the author rather than the UA the chance to specify 
> what icon will be best for a given size.

Using media queries for this is serious overkill. I can easily imagine 
uses for this that are from code that doesn't have a media queries 
implementation available, and this isn't something that implementors are 
going to implement media queries for. We need a solution that is easy to 
adopt from the implementation point of view.

That isn't to say that media queries shouldn't be allowed, though, and if 
people use them then they should work, if the UA supports them.


PROPOSAL: A generic attribute

On Wed, 30 Apr 2008, Jeff Walden wrote:
> 
> Given that <link/> is more intended as a generic element, I'm somewhat 
> leery of adding attributes specifically for one individual use of it.  
> If you're going to add an attribute (but see below), I think it makes 
> sense that it be something that any use of <link/> could use to store 
> extra data -- so an opaque attribute whose semantics are specified by 
> the rel attribute of the link.

On Sat, 3 May 2008, fantasai wrote:
> 
> [...] we shouldn't pick a solution here that requires adding attributes 
> every time we have a similar problem.

On Sat, 3 May 2008, Aaron Boodman wrote:
> 
> Why? To me it seems much preferable to separate the attributes of an 
> object into separate name/value pairs then trying to mash them all 
> together into one value.

I don't really agree with the premise that we somehow need to be frugal 
with attributes. We should use them when they are appropriate. Sure, we 
shouldn't waste them, but they're not a resource in scarce supply or that 
has some insane cost to them.

Note that we already have a DOM attribute on <link> that is specific to 
one rel type, namely "disabled".

In fact, generic attributes are a pain in the neck. Consider "title", 
whose behaviour changes radically if we're talking about rel=stylesheet 
versus something else.


PROPOSAL: MIME type parameters

On Wed, 30 Apr 2008, Jeff Walden 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.
 
On Tue, 29 Apr 2008, Maciej Stachowiak wrote:
> 
> 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.

On Wed, 30 Apr 2008, Martin Atkins wrote:
> 
> I recall that another group in a similar situation were considering 
> something like the following:
> 
> <link rel="icon" type="image/gif; width=24, height=24" href="...">
> 
> Presumably the above would be more the bailiwick of the MIME standard 
> than the HTML standard, but this seems cleaner to me than adding some 
> special-case attributes to the html LINK element.

This doesn't really work because we would need to add parameters to types 
we might not yet know. It also results in potentially complicated parsing 
rules, which I don't think people would get right. (See the comments I 
made for media queries.)


On Thu, 8 May 2008, Philipp Serafin wrote:
>
> I'd like to plug the approach with MIME parameters again, because it 
> seems by far the most elegant and clean to me.

There's no need to request things more than once -- I base my editing 
decisions on the quality of the arguments put forward, not the quantity. 
By all means, if you have new information, bring it forward, but merely 
repeating what has already been said doesn't do anything.


PROPOSAL: New rel="" keywords

On Thu, 1 May 2008, Maciej Stachowiak wrote:
> 
> I'm sure the last thing that is needed is more syntax suggestions, but 
> here's an alternate proposal with no new attributes, specify size info 
> as additional rel keywords:
> 
> <link rel="icon scalable" type="application/svg" href="whatwg.svg">
> <link rel="icon 16x16 32x32" type="image/microsoft.vnd.icon" 
> href="whatwg.ico">
> <link rel="icon 16x16 32x32 64x64 128x128 256x256 512x512" type="image/ 
> x-apple-icons" href="whatwg.icns">
> <link rel="icon 59x60" type="image/png" href="whatwg.png">
> 
> This would however effectively define an open-ended set of rel values, 
> and also it is dubious whether a size can be considered a relationship.

On Thu, 1 May 2008, Ernest Cline wrote:
> 
> If this approach is taken, rather than preempt any possible use of size 
> related values for icons, how about:
> 
> <link rel="icon" type="application/svg" href="whatwg.svg">
> <link rel="icon icon-16 icon-32" type="image/microsoft.vnd.icon" href="whatwg.ico">
> <link rel="icon icon-16 icon-32 icon-64 icon-128 icon-256 icon-512" type="image/x-apple-icons" href="whatwg.icns">
> <link rel="icon icon-59x60" type="image/png" href="whatwg.png">
> 
> Using "icon-*" to indicate square icons and "icon-*-*" to indicate 
> non-square icons would give a specific relationship of it being an icon 
> a specific size for a particular rel value and not be quite so open 
> ended.  Scalability is already indicated by the type attribute and could 
> be left to be implied by the use of just plain "icon" without any of the 
> more specific markers.  The use of the plain icon keyword on the ones 
> with specific sizes indicated would only be needed for backward 
> compatability with UAs that don't understand the extended forms proposed 
> here.

I don't think this fits the semantics of the rel="" attribute. The 
keywords are supposed to stand alone (even if they sometimes reinforce 
each other). Also, this is somewhat hard to parse (see the media queries 
comments again).


PROPOSAL: <icon>

On Wed, 30 Apr 2008, Bonner, Matt (IPG) wrote:
>
> Would I be crazy to propose an <icon> tag to the list?
> 
> If icons have unique need to describe size, etc, it strikes me as 
> parallel to the unique needs of video that justified creating a <video> 
> tag separate from <object>.

On Mon, 5 May 2008, Simon Pieters wrote:
> 
> I think that before going ahead and brainstorming syntax for this, we 
> should think about what the desired behavior in legacy browsers should 
> be and test what actually happens in legacy browsers for different 
> syntaxes. For instance, a new <icon> element would not show an icon in 
> legacy browsers and it would imply <body> in some browsers.

On Wed, 30 Apr 2008, Brady Eidson wrote:
>
> Following this thread, I just decided to throw this out there to see if 
> I'm way off base or not...
> 
> Since this is obviously a topic that has sparked a tad of passionate 
> interest and there's not necessarily a clear solution that doesn't make 
> <link> ugly, what are people's thoughts on adding a new element for icon 
> badging, one that would only be valid within the <head>?

On Wed, 30 Apr 2008, Aaron Boodman wrote:
>
> That would work for us, too.

On Wed, 30 Apr 2008, Bonner, Matt (IPG) wrote:
> 
> The idea of an <icon> tag that forks from <link> strikes me as analagous 
> to the <video> tag forking from <object>. Both new tags seem to come 
> from the need to have attributes more specific to their contents than 
> makes sense to load on the general tag.
> 
> Obviously, this brings "tag bloat" and yet more work for user agent 
> authors, so we'd want to hear from them...  But a separate icon tag 
> would permit unconstrained design of its attributes and preserve the 
> generality of <link>.

On Wed, 30 Apr 2008, Maciej Stachowiak wrote:
> 
> That would solve the use case, but since <link rel="icon"> is already 
> defined, it seems more elegant to extend it with the needed information.

On Sat, 3 May 2008, Ernest Cline wrote:
> 
> Perhaps, but it means adding attributes to <link> elements that will 
> only be needed for a single link type.  If the use case for these 
> attributes is strong enough to add special purpose attributes for use 
> with only <link rel=icon> then I dare say that it is strong enough to 
> have a special purpose <icon> element so as to keep user agents from 
> having to deal with nonsense such as <link rel=stylesheet height=32 
> width=32>

On Mon, 5 May 2008, Anne van Kesteren wrote:
>
> <icon> would not be backwards compatible. In some user agents (at least 
> Opera and Firefox) that would imply a <body> element for instance.

On Mon, 5 May 2008, Maciej Stachowiak wrote:
> 
> In addition, if we add <icon>, UAs will have to parse both <link 
> rel="icon"> (since many sites already specify icons this way, sometimes 
> 16x16 but sometimes bigger) and the new <icon>, but the old way will 
> have no way to specify size data. In fact, if a site has icons with 
> sizes from 16x16 up to anything you could reasonably want, it will have 
> to link it with <link rel="icon"> to support older browsers and then 
> again with <icon> to specify the size data.
> 
> So, on further reflection, I think a new <icon> element would be a bad 
> way to go.

I share the backwards compatibility concerns described above.


PROPOSAL: style="" attribute

On Wed, 30 Apr 2008, Ernest Cline wrote:
> 
> Maybe I'm missing something obvious, but why wouldn't:
> <link rel=icon style="width: 16px; height:16px">
> serve to mark width and height adequately?
> 
> It's even perfectly fine HTML 4 syntax.

On Thu, 1 May 2008, Smylers wrote:
> 
> The style attribute says _how_ to display something, not what that 
> something _is_.  The above says: "Ignore the icon's intrinsic size and 
> scale it to 16 x 16."
> 
> CSS is optional, so browsers shouldn't be forced to use it to find out 
> some meta-data.  And if a user had elected to turn off CSS for 
> displaying in pages, would a browser still be permitted to use it for 
> this purpose?
> 
> Nested attribute syntax is more awkward and error-prone than having 
> width and height directly on the element.

I agree with Smylers' reasoning; CSS seems inappropriate here. It would 
also be complicated to parse (see my earlier media queries comments).


PROPOSAL: Some hack with <title>

On Mon, 5 May 2008, Ernest Cline wrote:
> 
> Would making <icon> an optional content of <title> break backwards 
> compatibility?  The incompatibility problem you mention comes from the 
> start and end tags of both <head> and <body> being optional.  That isn't 
> the case for title and it makes sense syntactically to place it there as 
> the icon is part of the identifying information for the document.

On Mon, 5 May 2008, Maciej Stachowiak wrote:
> 
> <title> is parsed as CDATA, so tags inside it are not processed as such, 
> and instead become part of the title. Try opening a document containing 
> this to see:
> 
> <title><icon src="foo.jpg">This is some fancy title</title>
> 
> Thus, putting <icon> in the <title> would look terrible in all existing 
> user agents (at least ones that display the title), in addition to being 
> a total hack.

This would work for backwards compatibility reasons as Maciej describes.


RATHOLES

On Tue, 29 Apr 2008, Charles Iliya Krempeaux wrote:
> 
> 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....
> 
> 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.

On Wed, 30 Apr 2008, Maciej Stachowiak 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.

On Wed, 30 Apr 2008, Charles Iliya Krempeaux wrote:
> 
> 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.)

On Wed, 30 Apr 2008, Maciej Stachowiak wrote:
> 
> Has anyone actually asked for this kind of functionality or is this a 
> hypothetical use case? I don't think we should tie solving a real 
> problem (the need to specify icons at different sizes and let the UA 
> know these sizes) to an open-ended metadata annotation mechanism.

On Wed, 30 Apr 2008, Lachlan Hunt wrote:
> 
> For color, you are reinventing Media Queries. For compression, you are 
> basically reinventing q values for MIME types.
> 
> <link type="image/png;q=1.0" media="all and (min-color:8)">
> <link type="image/jpeg;q=0.8" media="all and (min-color:8)">

On Fri, 2 May 2008, Maciej Stachowiak wrote:
> 
> I think specifying aspect ratio and specifying duration of sound clip 
> are less compelling information to provide than icon sizes. This 
> information is intended to help determine which of possibly several 
> icons are appropriate for use in native UI contexts, without having to 
> download them. The last 3 of my 4 examples would be the best choices for 
> Windows XP, Mac OS X, and iPhone respectively, as icons for documents or 
> applications in the native UI. The Apple ICNS format would actually be a 
> better choice for Windows Vista, despite the file format, because Vista 
> HI guidelines call for availability of large icons and format conversion 
> would be a better choice than the large sizes. So this information is 
> not just redundant with the MIME type.
> 
> My first example (the SVG) could be used anywhere if UA understands SVG 
> and can render down to the specific sizes needed by the computing 
> environment. But it may not be feasible for all artwork to be provided 
> in vector format and in any case it may not scale well to tiny sizes 
> such as 16x16.
> 
> By contrast, I do not know of any actual need to determine the aspect 
> ratio of an SVG icon or the duration of a sound icon. I do not know of 
> cases where HI guidelines for particular platforms would recommend 
> different choices of icon aspect ratio or sound icon duration. Thus, I 
> suggest we limit ourselves to adding only the info that is actually 
> known to be needed at this time. If UI innovation creates a need for 
> more info, we can add it to the spec then.

We haven't had any requests for anything but height/width. We do not want 
to fall into second system syndrome before even having a first system 
here... There is a proper order to spec design!

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'