Re: [whatwg] link rel=icon width= height=aRe:
Ian Hickson wrote: 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. Fair enough. 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. Would it not be better to explitly say that media queries are not appropriate for this, for interoperability? 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. In general I agree that attributes are not a scarce resource, but if you need to add use-specific attributes to a supposedly-generic element I think that indicates that the generic element is inappropriate for the use-case. I don't know what link rel type uses disabled, but I would have had the same objection to that. If the meaning of title is something different for stylesheets than for other link rel types then that was an inappropriate use of that attribute as well. It's too late to change it now, but that's no reason to continue overloading generic elements/attributes with special cases. link is also interesting in that unlike input type=... rel can contain several values. Is it conforming to use width and height attributes on a link element that contains both icon and a another, non-icon keyword? What about a rel=icon ... width=... height=... ? Finally, what is the process for contributors to the RelExtensions page to include extension attributes? link rel=icon type=image/gif; width=24, height=24 href=... 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.) Presumably this would be defined (if at all) for everything under image/, just as charset is defined for everything under text/. (In theory, at least.)
Re: [whatwg] link rel=icon width= height=aRe:
The integers should be separated by times; and not by x. In case you care about semantics, that is. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Thursday, May 08, 2008 4:18 AM To: WHATWG Subject: [whatwg] link rel=icon width= height=aRe: 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.
Re: [whatwg] link rel=icon width= height=aRe:
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. I'm sorry. I missed that there already was an image/*; width=...; height=... proposal. I saw only the image/*; sizes=... proposal. Won't happen again :)
Re: [whatwg] link rel=icon width= height=
On Thu, 08 May 2008 03:17:38 +0100, Ian Hickson [EMAIL PROTECTED] wrote: I've added a sizes attribute to link for the icon keyword. The spec now contains: If multiple icons are provided, the user agent must select the most appropriate icon according to the media and sizes attributes. If there are multiple equally appropriate icons, user agents must use the first one declared in tree order. Does this disallow composing .ico files from multiple separate files? UAs like Fluid or Prism can't know which sizes OS is going to use, so all valid ico sizes are 'equally appropriate'. Also this algorithm doesn't match current browser behaviour, is this intentional? I did a quick test with a bunch of random favicons: * Opera 9.5b2 loads all icons (that's pretty bad if one decides to provide Leopard's monsterous 300KB icons) and displays last icon loaded, * Firefox 3b5 picks last icon regardless of attributes. It loads all icons when I reload page after restoring session. * WebKit nightly and Fluid pick last icon that has type attribute (even if type is bogus), or just last if none have type. I'm afraid that this could cause trouble (every visitor downloading icon that's 20–300 times larger than typical favicon). Why not use rel=application-icon or rel=appicon? I don't like the any keyword. SVG icons are scallable, but it's not the same as being usable at any size. For example Tango icons project provides PNG for 16, 22 and 32px icons in addition to SVG, because lines and finer details in SVG become illegible at small sizes. Does the specified size imply that UA is required to display icon at given size only? (i.e. is any obligatory to have icon scaled at all?) What if sizes attribute is absent? -- regards, Kornel Lesiński
Re: [whatwg] link rel=icon width=
I'd like to plug the approach with MIME parameters again, because it seems by far the most elegant and clean to me. However, instead of specifying multiple sizes in one MIME parameter, couldn't we just define two parameters width and heigth (and perhaps a ratio for graphics without inherent boundaries) and use Charles' mechanism with multiple link elements to list multiple sizes? An example would be: 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 link type=icon type=image/x-apple-icons; width=16; height=16 href=whatwg.icns link type=icon type=image/x-apple-icons; width=32; height=32 href=whatwg.icns link type=icon type=image/x-apple-icons; width=64; height=64 href=whatwg.icns link type=icon type=image/x-apple-icons; width=128; height=128 href=whatwg.icns link type=icon type=image/x-apple-icons; width=256; height=256 href=whatwg.icns link type=icon type=image/x-apple-icons; width=512; height=512 href=whatwg.icns link type=icon type=image/png; width=59; height=60 href=whatwg.png I agree that this looks ugly at first glance, but it has a certain inner beauty if you think about it a bit longer. I think Maciej is right, that the least thing we need is yet another micro language that tries to cram more values into an attribute than it's healthly. However, in this case, we can leave out the yet another. MIME types are already widely used and the capabillites to process them already exist on both client side and server side. Also, as already mentioned, width and heigth attributes don't make much sense on link, because they are only applicable for a very small subset of link use cases. However, they do make sense as parameters for the top level MIME type image/*. Almost all images have - if not an intrinsic size - at least a number of bounds they can be viewed best in. So if you define those parameters as optimal size for this image, it would both solve the requested problem and fit nicely in the whole content negiotation scheme that MIME is mostly used for on the web. UAs that already use the type attribute to choose the most suitable URI for a link might not need to add much existing functionality. If they preferred, let's say, favicons in 16x16, they would just need to priorize images of the type image/microsoft.vnd.icon; width=16; height=16 in the same way they would priorize - let's say - image/png over image/gif before. What are the opinions on this?
[whatwg] link rel=icon width= height=aRe:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: [whatwg] link rel=icon width= height=aRe:
I think specifying aspect ratio and specifying duration of sound clip are less compelling information to provide than icon sizes. We haven't had any requests for anything but height/width. An in the SVG case, if you have a height/width you already have the aspect ratio anyway. -- Charles
Re: [whatwg] link rel=icon width= height=aRe:
On Wed, May 7, 2008 at 7:17 PM, Ian Hickson [EMAIL PROTECTED] wrote: 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. Cool. Thanks for being so responsive on this. - a
Re: [whatwg] link rel=icon width=
On Sun, 04 May 2008 02:38:03 +0200, Ernest Cline [EMAIL PROTECTED] 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 icon would not be backwards compatible. In some user agents (at least Opera and Firefox) that would imply a body element for instance. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] link rel=icon width= height=
On Wed, 30 Apr 2008 03:52:08 +0200, Ian Hickson [EMAIL PROTECTED] wrote: (With my rarely-used Google hat on:) 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. 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). Opinions? 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. -- Simon Pieters Opera Software
Re: [whatwg] link rel=icon width=
-Original Message- From: Anne van Kesteren [EMAIL PROTECTED] Sent: May 5, 2008 5:27 AM On Sun, 04 May 2008 02:38:03 +0200, Ernest Cline [EMAIL PROTECTED] 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 icon would not be backwards compatible. In some user agents (at least Opera and Firefox) that would imply a body element for instance. 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.
Re: [whatwg] link rel=icon width=
On May 5, 2008, at 10:28 AM, Ernest Cline wrote: -Original Message- From: Anne van Kesteren [EMAIL PROTECTED] Sent: May 5, 2008 5:27 AM On Sun, 04 May 2008 02:38:03 +0200, Ernest Cline [EMAIL PROTECTED] 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 icon would not be backwards compatible. In some user agents (at least Opera and Firefox) that would imply a body element for instance. 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. I agree with this, and continue to like the idea of a specialized element for the icon. ~Brady
Re: [whatwg] link rel=icon width=
On May 5, 2008, at 10:28 AM, Ernest Cline wrote: -Original Message- From: Anne van Kesteren [EMAIL PROTECTED] Sent: May 5, 2008 5:27 AM On Sun, 04 May 2008 02:38:03 +0200, Ernest Cline [EMAIL PROTECTED] 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 icon would not be backwards compatible. In some user agents (at least Opera and Firefox) that would imply a body element for instance. 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. 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: titleicon src=foo.jpgThis 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. 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. Regards, Maciej
Re: [whatwg] link rel=icon width= height=
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. -- regards, Kornel Lesiński
Re: [whatwg] link rel=icon width= height=
On Mon, May 5, 2008 at 1:57 PM, Kornel Lesinski [EMAIL PROTECTED] wrote: There isn't much bandwidth to be saved. These icons are going to be downloaded only once. 128x128 PNG icons take only 20-30kb. 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. 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. Why should web developers have to settle for good enough, while desktop application developers get to create many differently sized icons optimized for use in different contexts? 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. I don't think that ico or icns format is going to be the common case. These formats require specialized software to create correctly, whereas any image editor can create pngs. - a
Re: [whatwg] link rel=icon width= height=
On Mon, 05 May 2008 23:36:51 +0100, Aaron Boodman [EMAIL PROTECTED] wrote: There isn't much bandwidth to be saved. These icons are going to be downloaded only once. 128x128 PNG icons take only 20-30kb. Without hints as to which file contains which size, the user agent must download up to four separate images before using them. 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. 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. Why should web developers have to settle for good enough, while desktop application developers get to create many differently sized icons optimized for use in different contexts? I didn't say authors have to settle for good enough. 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). 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. I don't think that ico or icns format is going to be the common case. These formats require specialized software to create correctly, whereas any image editor can create pngs. There are free, open-source tools to convert between .ico and set of PNG images. OS X comes with Icon Composer and there's 3rd party IconBuilder that works on MS Windows. Favicons in .ico format are popular and supported by all major browsers today. -- regards, Kornel Lesiński
Re: [whatwg] link rel=icon width=
On Sat, May 3, 2008 at 5:38 PM, Ernest Cline [EMAIL PROTECTED] 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 Can't that happen anyway? For example, link rel=stylesheet icon16x16 is just as nonsensical. - a
Re: [whatwg] link rel=icon width= height=
Maciej Stachowiak wrote: 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. That's fine, but we shouldn't pick a solution here that requires adding attributes every time we have a similar problem. ~fantasai
Re: [whatwg] link rel=icon width= height=
On Sat, May 3, 2008 at 8:13 AM, fantasai [EMAIL PROTECTED] wrote: Maciej Stachowiak wrote: 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. That's fine, but we shouldn't pick a solution here that requires adding attributes every time we have a similar problem. 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. - a
Re: [whatwg] link rel=icon width=
-Original Message- From: Aaron Boodman [EMAIL PROTECTED] Sent: May 3, 2008 2:33 PM On Sat, May 3, 2008 at 8:13 AM, fantasai [EMAIL PROTECTED] wrote: Maciej Stachowiak wrote: 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. That's fine, but we shouldn't pick a solution here that requires adding attributes every time we have a similar problem. 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. 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
Re: [whatwg] link rel=icon width= height=
Maciej Stachowiak wrote: 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. I don't think it can. This seems pretty wrong to me: the right place for this information would be, as Jeff Walden said, in the 'type' attribute. ~fantasai
Re: [whatwg] link rel=icon width= height=
Maciej Stachowiak 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. 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. If I'm reading the spec correctly http://www.faqs.org/rfcs/rfc2045.html you could use '+' as a separator. sizes=16x16+32x32+64x64 For SVG icons, you'd probably want the ability to specify a ratio instead. (And I suppose for sound icons, you'd want the length of the sound clip...) Also, I didn't see anything in the spec about parameters needing to be prefixed, only subtypes. Maybe I missed it. ~fantasai
Re: [whatwg] link rel=icon width= height=
On May 2, 2008, at 12:24 AM, fantasai wrote: Maciej Stachowiak 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. 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. If I'm reading the spec correctly http://www.faqs.org/rfcs/rfc2045.html you could use '+' as a separator. sizes=16x16+32x32+64x64 For SVG icons, you'd probably want the ability to specify a ratio instead. (And I suppose for sound icons, you'd want the length of the sound clip...) Also, I didn't see anything in the spec about parameters needing to be prefixed, only subtypes. Maybe I missed it. That seems like an adequate solution, though syntactically less elegant than a new attribute IMO. 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. Regards, Maciej
Re: [whatwg] link rel=icon width= height=
I think it should be possible to embed rendered bit map images in SVG for lower resolution, just as TrueTypeT fonts embed ideograms. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak Sent: Friday, May 02, 2008 12:28 PM To: fantasai Cc: [EMAIL PROTECTED]; Jeff Walden Subject: Re: [whatwg] link rel=icon width= height= 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. Regards, Maciej
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.
Re: [whatwg] link rel=icon width= height=
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). Opinions? 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. 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 type=icon type=application/svg sizes=any href=whatwg.svg link type=icon type=image/microsoft.vnd.icon sizes=16x16 32x32 href=whatwg.ico link type=icon type=image/x-apple-icons sizes=16x16 32x32 64x64 128x128 256x256 512x512 href=whatwg.icns link type=icon type=image/png sizes=59x60 href=whatwg.png 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. Jeff -- Life would be so much easier if humans had a natural affinity for remembering 128-bit integers.
Re: [whatwg] link rel=icon width= height=
On Apr 29, 2008, at 10:24 PM, Charles Iliya Krempeaux wrote: Hello, On Tue, Apr 29, 2008 at 10:13 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Apr 29, 2008, at 6:52 PM, Ian Hickson wrote: [...] link type=icon type=application/svg sizes=any href=whatwg.svg link type=icon type=image/microsoft.vnd.icon sizes=16x16 32x32 href=whatwg.ico link type=icon type=image/x-apple-icons sizes=16x16 32x32 64x64 128x128 256x256 512x512 href=whatwg.icns link type=icon type=image/png sizes=59x60 href=whatwg.png Couldn't this also be done as... 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 link type=icon type=image/x-apple-icons width=16 height=16 href=whatwg.icns link type=icon type=image/x-apple-icons width=32 height=32 href=whatwg.icns link type=icon type=image/x-apple-icons width=64 height=64 href=whatwg.icns link type=icon type=image/x-apple-icons width=128 height=128 href=whatwg.icns link type=icon type=image/x-apple-icons width=256 height=256 href=whatwg.icns link type=icon type=image/x-apple-icons width=512 height=512 href=whatwg.icns link type=icon type=image/png width=59 height=60 href=whatwg.png Basically link'ing to the same icon more that once for each size it is good for. a) This may not be obvious to authors. b) It's more boilerplate for the author. c) It's more 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). d) 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). I fail to see the advantages of this approach. - Maciej See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ Vlog Razor... Vlogging News... http://vlograzor.com/
Re: [whatwg] link rel=icon width= height=
On Apr 29, 2008, at 10:33 PM, Michael(tm) Smith wrote: Ian Hickson [EMAIL PROTECTED], 2008-04-30 01:52 +: 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. 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). 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 [EMAIL PROTECTED] 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? Not all platforms use icons that have the same width and height. For example, the standard size for iPhone icons is 59x60. Regards, Maciej
Re: [whatwg] link rel=icon width= height=
On Apr 29, 2008, at 11:17 PM, Jeff Walden wrote: 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). Opinions? 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. 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 type=icon type=application/svg sizes=any href=whatwg.svg link type=icon type=image/microsoft.vnd.icon sizes=16x16 32x32 href=whatwg.ico link type=icon type=image/x-apple-icons sizes=16x16 32x32 64x64 128x128 256x256 512x512 href=whatwg.icns link type=icon type=image/png sizes=59x60 href=whatwg.png 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. 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. Regards, Maciej
Re: [whatwg] link rel=icon width= height=
Hello, On Tue, Apr 29, 2008 at 11:24 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Apr 29, 2008, at 10:24 PM, Charles Iliya Krempeaux wrote: Hello, On Tue, Apr 29, 2008 at 10:13 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Apr 29, 2008, at 6:52 PM, Ian Hickson wrote: [...] link type=icon type=application/svg sizes=any href=whatwg.svg link type=icon type=image/microsoft.vnd.icon sizes=16x16 32x32 href=whatwg.ico link type=icon type=image/x-apple-icons sizes=16x16 32x32 64x64 128x128 256x256 512x512 href=whatwg.icns link type=icon type=image/png sizes=59x60 href=whatwg.png Couldn't this also be done as... 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 link type=icon type=image/x-apple-icons width=16 height=16 href=whatwg.icns link type=icon type=image/x-apple-icons width=32 height=32 href=whatwg.icns link type=icon type=image/x-apple-icons width=64 height=64 href=whatwg.icns link type=icon type=image/x-apple-icons width=128 height=128 href=whatwg.icns link type=icon type=image/x-apple-icons width=256 height=256 href=whatwg.icns link type=icon type=image/x-apple-icons width=512 height=512 href=whatwg.icns link type=icon type=image/png width=59 height=60 href=whatwg.png Basically link'ing to the same icon more that once for each size it is good for. a) This may not be obvious to authors. b) It's more boilerplate for the author. c) It's more 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). d) 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). I fail to see the advantages of this approach. 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 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. See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ Vlog Razor... Vlogging News... http://vlograzor.com/
Re: [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
Re: [whatwg] link rel=icon width= height=
Hello, On Wed, Apr 30, 2008 at 12:19 AM, Maciej Stachowiak [EMAIL PROTECTED] 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/
Re: [whatwg] link rel=icon width= height=
On Apr 30, 2008, at 12:41 AM, Charles Iliya Krempeaux wrote: Hello, On Wed, Apr 30, 2008 at 12:19 AM, Maciej Stachowiak [EMAIL PROTECTED] 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.) 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. 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.) I'm not in favor of a CSS-like metadata language or a metadata attribute. I don't think your suggested extra attributes are very useful either so I am not sure how it is relevant to discuss different syntax alternatives for them. That being said, this: link rel=enclosure type=image/xxx sizes=640x480 1280x960 2560x1920 compressioning=lossy coloring=truecolor href=A.xxx Does not introduce a CSS-like metadata language any more than your first alternative. So I still do not see your point. Regards, Maciej
Re: [whatwg] link rel=icon width= height=
On Wed, Apr 30, 2008 at 8:33 AM, Michael(tm) Smith [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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? 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.
Re: [whatwg] link rel=icon width= height=
Charles Iliya Krempeaux wrote: 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 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) -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] link rel=icon width= height=
Ian Hickson wrote: (With my rarely-used Google hat on:) 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. 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). Opinions? I recall that another group[1] 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. [1] Sadly, I cannot remember which group it was at the moment.
Re: [whatwg] link rel=icon width= height=
Lachlan Hunt wrote: Charles Iliya Krempeaux wrote: 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 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) 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
Re: [whatwg] link rel=icon width= height=
I am agaist using compound attributes like this; make it 16times;16 if you insist. Best regards, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak Sent: Wednesday, April 30, 2008 7:13 AM To: Ian Hickson Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] link rel=icon width= height= link type=icon type=image/microsoft.vnd.icon sizes=16x16 32x32 href=whatwg.ico Regards, Maciej
Re: [whatwg] link rel=icon width= height=
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? ~Brady
Re: [whatwg] link rel=icon width= height=
On Wed, Apr 30, 2008 at 11:32 AM, Brady Eidson [EMAIL PROTECTED] wrote: 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? That would work for us, too. - a
Re: [whatwg] link rel=icon width= height=
Brady Eidson wrote: what are people's thoughts on adding a new element for icon badging, one that would only be valid within the head? Funny I wrote just that same question to the editor an hour ago. Since someone else brought it up, now I'm just adding to the thought. :-) 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. best regards, Matt -- Matt Bonner Hewlett-Packard Company -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brady Eidson Sent: Wednesday, April 30, 2008 11:32 AM To: WHATWG Mailing List Cc: Ian Hickson Subject: Re: [whatwg] link rel=icon width= height= 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? ~Brady smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] link rel=icon width= height=
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. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] link rel=icon width=
-Original Message- From: Ian Hickson [EMAIL PROTECTED] Sent: Apr 29, 2008 9:52 PM To: [EMAIL PROTECTED] Subject: [whatwg] link rel=icon width= height= (With my rarely-used Google hat on:) 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. 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). Opinions? 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. Ernest Cline
Re: [whatwg] link rel=icon width= height=
On Apr 30, 2008, at 11:32 AM, 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? 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. Regards, Maciej
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) You are using HTTP accept-parameters in a context where a media type with optional parameters is expected; in other words, this is non- compliant at the moment since there is no 'q' parameter for the type. 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. If you read the definition of the media atteribute, you'll find that it has a dual nature, specifically, it can describe for which media the document in question was designed. While this is not currently the case for 'icon', it could easily be made so, and if, the above would mean the icon was designed for a viewport or page box of at most 16x16px. If the icon is rendered into a 16x16px viewport, well, I'd find that fitting. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] link rel=icon width= height=
On Tue, Apr 29, 2008 at 6:52 PM, Ian Hickson [EMAIL PROTECTED] 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). Opinions? +1 :) 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. - a
Re: [whatwg] link rel=icon width= height=
On Apr 29, 2008, at 6:52 PM, Ian Hickson wrote: (With my rarely-used Google hat on:) 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. 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). Opinions? 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. 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 type=icon type=application/svg sizes=any href=whatwg.svg link type=icon type=image/microsoft.vnd.icon sizes=16x16 32x32 href=whatwg.ico link type=icon type=image/x-apple-icons sizes=16x16 32x32 64x64 128x128 256x256 512x512 href=whatwg.icns link type=icon type=image/png sizes=59x60 href=whatwg.png Regards, Maciej
Re: [whatwg] link rel=icon width= height=
Hello, On Tue, Apr 29, 2008 at 10:13 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Apr 29, 2008, at 6:52 PM, Ian Hickson wrote: [...] link type=icon type=application/svg sizes=any href=whatwg.svg link type=icon type=image/microsoft.vnd.icon sizes=16x16 32x32 href=whatwg.ico link type=icon type=image/x-apple-icons sizes=16x16 32x32 64x64 128x128 256x256 512x512 href=whatwg.icns link type=icon type=image/png sizes=59x60 href=whatwg.png Couldn't this also be done as... 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 link type=icon type=image/x-apple-icons width=16 height=16 href=whatwg.icns link type=icon type=image/x-apple-icons width=32 height=32 href=whatwg.icns link type=icon type=image/x-apple-icons width=64 height=64 href=whatwg.icns link type=icon type=image/x-apple-icons width=128 height=128 href=whatwg.icns link type=icon type=image/x-apple-icons width=256 height=256 href=whatwg.icns link type=icon type=image/x-apple-icons width=512 height=512 href=whatwg.icns link type=icon type=image/png width=59 height=60 href=whatwg.png Basically link'ing to the same icon more that once for each size it is good for. See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ Vlog Razor... Vlogging News... http://vlograzor.com/
Re: [whatwg] link rel=icon width= height=
Ian Hickson [EMAIL PROTECTED], 2008-04-30 01:52 +: 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. 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). 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 [EMAIL PROTECTED] 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? If [EMAIL PROTECTED] icons in practice actually always have the same height and width, it seems like just adding just size attribute (e.g., link rel=icon size=32 ...) could achieve the same effect. Or if we wanted to really get declarative, I guess another way to do it might be to have an icontype (or whatever) attribute with an enumerated list of values that describe the intended purpose of the icon (instead of its size). So, icontype=favicon or icontype=desktop -- or whatever terms describe what the various (de facto) standard sizes of icons are used for. Or if not that, maybe the value should just be an enumerated list of size names -- e.g., small, medium, large, x-large. --Mike -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/ smime.p7s Description: S/MIME cryptographic signature
