Re: [whatwg] link rel=icon width= height=
Lachlan Hunt wrote: Martin Atkins wrote: 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) Could this be said about size as well? link type=image/png media=all and (max-width:16px and max-height:16px) 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. 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.
Re: [whatwg] link rel=icon width= height=
Martin Atkins wrote: Lachlan Hunt wrote: Martin Atkins wrote: Could this be said about size as well? link type=image/png media=all and (max-width:16px and max-height:16px) 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. 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. 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. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] link rel=icon width=
-Original Message- From: Smylers [EMAIL PROTECTED] Sent: May 1, 2008 3:02 AM Ernest Cline writes: ... 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 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? * 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. Unless width and height attributes for link are going to behave differently than they do on other elements, that's the behavior they'd have anyway. (See section 3.12.17 Dimension attributes) 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. * 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? The whole use of link rel=icon is a stylistic concern in the first place. Limiting the optimal use of rel=icon to instances in which CSS is used does not strike me as an excessive burden. * Nested attribute syntax is more awkward and error-prone than having width and height directly on the element. Maybe slightly, but is it enough of an advantage to outweigh the added browser overhead needed to add support for two attributes to every instance of link even tho it is useful to only one particular linktype, particularly since support for the alternative I offered needs to be available in the first place. It's even perfectly fine HTML 4 syntax. Why is that interesting? If it's syntax that current browsers already do something useful with then that's a big point in its favour; but if it's something which is currently a no-op then that it happens to be syntactically permitted in an older standard doesn't seem like a benefit over any other syntax which browsers currently ignore. I can't say if any current browsers currently make use of it, but it is syntax they need to be able to handle in some manner. One strong argument for using the style attribute instead of adding new attributes is that it does not increase the amount of overhead a browser is expected to handle.
Re: [whatwg] link rel=icon width= height=
On Apr 29, 2008, at 10:13 PM, 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. 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 OK, 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. Regards, Maciej
Re: [whatwg] link rel=icon width=
-Original Message- From: Maciej Stachowiak [EMAIL PROTECTED] Sent: May 1, 2008 9:34 PM To: Maciej Stachowiak [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Ian Hickson [EMAIL PROTECTED] Subject: Re: [whatwg] link rel=icon width= height= On Apr 29, 2008, at 10:13 PM, 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. 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 OK, 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. Regards, Maciej 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.
