Re: [whatwg] Resolutions meta tag proposal
G'day, since the discussion is more or less trying to find a solution in the markup realm (which I thoroughly support), I'm gonna focus on Roger's proposal of @dpi. I believe the proposal might work. But assuming you might want to target 3x resolutions on all img the size of the document will increase. Like Roger said, it's very important to have this working on a several of ways. 1) content negotiation, at the server level. 2) markup, @dpi or other attribute specifying an alt resource for each resolution ( img src resolutions=?) 3) css, media queries are able to do this.. right? 4) javascript, give access to the document's current resolution in dpi's, under screen.resolution? Although, on point 2, i still prefer the way I suggested earlier, to make img work like the other media tags: video audio, with child source elements that could have either a resolution=96 (per proposal of Roger) attribute or a media query... Anyway, is it still time to have this conversation? Will additions to the spec be considered? Since this Retina (high res screens) business is very new, there isn't much real-world usage to harvest proof of... but is there a process or a set of steps a proposal must go through? -- André Luís http://id.andr3.net/ On 4 July 2010 21:57, Roger Hågensen resca...@emsai.net wrote: On 2010-07-04 14:34, Marques Johansson wrote: Another way about handling this PPI ratio business would be with HTTP 300 multiple choice. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1 This may not be the best answer for every image on a page, but the first HTML page in a server controlled session could store the PPI ratio setting based on the page the UA chooses and then modify the HTML or content-negotiation setting. A problem with this is that the browsers wouldn't be likely to render a page correctly unless they were modified for this image request yields 300 behavior. I still like something like this for client content negotiation: GET /image/dog HTTP/1.1 Accept: image/*; ppiratio=2 ... HTTP/1.1 200 OK Content-type: image/jpeg ... d...@2x.jpg Apache rewrite rules could even handle this by detecting ppiratio in the Accept header and then looking for a matching images/ratio/2/dog file. If it didn't exist the rewrite would fail resulting in the server responding with images/dog which is suitable if not optimal. This has me thinking Accept: image/*; x=400; y=300 could be attached with any image request based on clients intent for the image. (The HTML said 'width=400 height=300' so I don't need anything better.) The server can ignore this or return something better suited than the 1200x1200 image that it would otherwise return. I still don't have a handle on this retinal / ppi stuff so ppiratio may be the wording. I also like Accept: video/*; kbps=500 for a similar purpose. Again this is negotiation related, and although I'm able to do fancy apache stuff on my site I'd rather not have to. This however takes advantage of CSS http://www.alistapart.com/articles/hiresprinting/ Not exactly ideal, but I think it's the better approach, it just need to be refined and standardized some way. But here's an idea I have that would fit into HTML5. Examples: 1. img src=img/test.png width=512 height=256 dpi=96;;300;image/test300.png work better? (96 dpi is current thus empty ;; while 300 dpi is alternative hence specified. 2. img src=img/test.png width=512 height=256 dpi=300 woould also be valid, indicating that the image is 300 dpi and no alternatives. 3. img src=img/test.png width=512 height=256 dpi=300;image/test300.png same as example 1, 96 dpi default assumed. 4. img src=img/test.png width=512 height=256 dpi=*;image/test.svg 96 dpi default assumed, the * indicate any DPI and in this case it's a vector format. If dpi= or is not specified, then the image should be assumed to be 96dpi, unless the image format has it's own dpi info (JPG support this, but does PNG?) that is. This would make printouts look better, and allows the author to specify displayed size (width and height being logical pixels for non-96 dpi images obviously) High DPI displays would make the browser get the high dpi image instead of the default. The only parts of a site that has issues currently is fixed pixel graphics (and fixed pixel based layout as well I guess), it is only pixel based (bitmapped) images that has issues with scaling, embed video already tend to offer multiple resolutions. So a dpi param for img might just be a nice way to fix the issue. The CSS folks might have to add some support for this too, as well as scripting support. This is just something I came up with right now, but it's at least simple in use which is the important thing I guess. -- Roger Rescator Hågensen. Freelancer - http://EmSai.net/
Re: [whatwg] Resolutions meta tag proposal
On Tue, 06 Jul 2010 13:52:24 +0200, André Luís andreluis...@gmail.com wrote: [...] i still prefer the way I suggested earlier, to make img work like the other media tags: video audio, with child source elements that could have either a resolution=96 (per proposal of Roger) attribute or a media query... We cannot have child elements for img. Content (legacy and new) constraints how img is and will be parsed. Anyway, is it still time to have this conversation? Will additions to the spec be considered? Yes, though extensions to the meta element can be done independently from the specification. As a standalone specification. Since this Retina (high res screens) business is very new, there isn't much real-world usage to harvest proof of... but is there a process or a set of steps a proposal must go through? There is a somewhat informal process, yes: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F Personally I do not think detailed control is needed at all. It requires way too much configuration and hassle for little benefit. What Dave Hyatt outlined in http://webkit.org/blog/55/high-dpi-web-sites/ for the img element is good enough. I.e. always load the high resolution version and scale it down for lesser displays using height/width. Sure, some more bandwidth is used, but that is not a big deal, especially if you consider that the higher resolution version goes to the device with less bandwidth. So if bandwidth was a concern we would not be having this discussion. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Resolutions meta tag proposal
Another way about handling this PPI ratio business would be with HTTP 300 multiple choice. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1 This may not be the best answer for every image on a page, but the first HTML page in a server controlled session could store the PPI ratio setting based on the page the UA chooses and then modify the HTML or content-negotiation setting. A problem with this is that the browsers wouldn't be likely to render a page correctly unless they were modified for this image request yields 300 behavior. I still like something like this for client content negotiation: GET /image/dog HTTP/1.1 Accept: image/*; ppiratio=2 ... HTTP/1.1 200 OK Content-type: image/jpeg ... d...@2x.jpg Apache rewrite rules could even handle this by detecting ppiratio in the Accept header and then looking for a matching images/ratio/2/dog file. If it didn't exist the rewrite would fail resulting in the server responding with images/dog which is suitable if not optimal. This has me thinking Accept: image/*; x=400; y=300 could be attached with any image request based on clients intent for the image. (The HTML said 'width=400 height=300' so I don't need anything better.) The server can ignore this or return something better suited than the 1200x1200 image that it would otherwise return. I still don't have a handle on this retinal / ppi stuff so ppiratio may be the wording. I also like Accept: video/*; kbps=500 for a similar purpose. 2010/7/3 timeless timel...@gmail.com 2010/7/3 André Luís andreluis...@gmail.com: (alt-option 1) Trying to step away from the solution presented, I can only imagine something along the lines of different src attributes for different resolutions: img src=imgs/standard-def.png src-2x=imgs/high-def.png video src=movs/sd.ogv src-2x=movs/hd.ogv img lowsrc used to exist: http://www.htmlcodetutorial.com/images/_IMG_LOWSRC.html it's mostly gone now. I think that if someone wants to be fancy they can use the existing features (min-device-pixel-ratio, alternate stylesheets) and hide the img content and replace it with background images or something.
Re: [whatwg] Resolutions meta tag proposal
On 2010-07-04 14:34, Marques Johansson wrote: Another way about handling this PPI ratio business would be with HTTP 300 multiple choice. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1 This may not be the best answer for every image on a page, but the first HTML page in a server controlled session could store the PPI ratio setting based on the page the UA chooses and then modify the HTML or content-negotiation setting. A problem with this is that the browsers wouldn't be likely to render a page correctly unless they were modified for this image request yields 300 behavior. I still like something like this for client content negotiation: GET /image/dog HTTP/1.1 Accept: image/*; ppiratio=2 ... HTTP/1.1 200 OK Content-type: image/jpeg ... d...@2x.jpg Apache rewrite rules could even handle this by detecting ppiratio in the Accept header and then looking for a matching images/ratio/2/dog file. If it didn't exist the rewrite would fail resulting in the server responding with images/dog which is suitable if not optimal. This has me thinking Accept: image/*; x=400; y=300 could be attached with any image request based on clients intent for the image. (The HTML said 'width=400 height=300' so I don't need anything better.) The server can ignore this or return something better suited than the 1200x1200 image that it would otherwise return. I still don't have a handle on this retinal / ppi stuff so ppiratio may be the wording. I also like Accept: video/*; kbps=500 for a similar purpose. Again this is negotiation related, and although I'm able to do fancy apache stuff on my site I'd rather not have to. This however takes advantage of CSS http://www.alistapart.com/articles/hiresprinting/ Not exactly ideal, but I think it's the better approach, it just need to be refined and standardized some way. But here's an idea I have that would fit into HTML5. Examples: 1. img src=img/test.png width=512 height=256 dpi=96;;300;image/test300.png work better? (96 dpi is current thus empty ;; while 300 dpi is alternative hence specified. 2. img src=img/test.png width=512 height=256 dpi=300 woould also be valid, indicating that the image is 300 dpi and no alternatives. 3. img src=img/test.png width=512 height=256 dpi=300;image/test300.png same as example 1, 96 dpi default assumed. 4. img src=img/test.png width=512 height=256 dpi=*;image/test.svg 96 dpi default assumed, the * indicate any DPI and in this case it's a vector format. If dpi= or is not specified, then the image should be assumed to be 96dpi, unless the image format has it's own dpi info (JPG support this, but does PNG?) that is. This would make printouts look better, and allows the author to specify displayed size (width and height being logical pixels for non-96 dpi images obviously) High DPI displays would make the browser get the high dpi image instead of the default. The only parts of a site that has issues currently is fixed pixel graphics (and fixed pixel based layout as well I guess), it is only pixel based (bitmapped) images that has issues with scaling, embed video already tend to offer multiple resolutions. So a dpi param for img might just be a nice way to fix the issue. The CSS folks might have to add some support for this too, as well as scripting support. This is just something I came up with right now, but it's at least simple in use which is the important thing I guess. -- Roger Rescator Hågensen. Freelancer - http://EmSai.net/
Re: [whatwg] Resolutions meta tag proposal
2010/7/3 André Luís andreluis...@gmail.com: (alt-option 1) Trying to step away from the solution presented, I can only imagine something along the lines of different src attributes for different resolutions: img src=imgs/standard-def.png src-2x=imgs/high-def.png video src=movs/sd.ogv src-2x=movs/hd.ogv img lowsrc used to exist: http://www.htmlcodetutorial.com/images/_IMG_LOWSRC.html it's mostly gone now. I think that if someone wants to be fancy they can use the existing features (min-device-pixel-ratio, alternate stylesheets) and hide the img content and replace it with background images or something.
Re: [whatwg] Resolutions meta tag proposal
On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan a...@aralbalkan.com wrote: ... http://wiki.whatwg.org/wiki/MetaExtensions#Proposals In this case, the developer would provide 2x, 4x, and 8x versions of all images. So, in the running example, she would make flower.jpg, flo...@2x.jpg, flo...@4x.jpg, and And what if the image was named images/flower (using the accept header to send a jpg vs png vs gif) instead of flower.jpg. The browser would need to have rules about how to rewrite the name of the file. I think @ in the filename would break the many Dos 6.22 based web servers ;-). I don't think a single element with a single attribute can handle this problem. What about an HTTP header like: Accept: image/*;ppiratio=2 This would allow the server to send the correct images for that client or return a 307 to the rewritten filename as the server deems fit. A new Accept property doesn't seem to require changing any specs. I'ld like to think that image/*;q=x could be used in some way for this. On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan a...@aralbalkan.com wrote: I just submitted a proposal for a new meta tag to flag that high-resolution images are available and should be loaded in place of low-resolution ones for users with high-PPI displays (like the new iPhone 4's Retina display). Please see: http://wiki.whatwg.org/wiki/MetaExtensions#Proposals (Currently, although you can use the min-device-pixel-ratio CSS Media Query to achieve this for background images, no such mechanism exists for images displayed via the img tag short of setting a flag in CSS and using image substitution via JavaScript. This new meta tag proposes a JavaScript-free and easy-to-author mechanism to handle the above use case.) I look forward to hearing your thoughts :) All the best, Aral
Re: [whatwg] Resolutions meta tag proposal
Hi Marques, I'm an interaction designer/developer, not a rocket scientist. :) A meta tag, I can easily add. If you start talking about HTTP headers, you've lost me. i.e., this is meant to be a pragmatic, easy-to-author solution. Thanks, Aral On Fri, Jul 2, 2010 at 2:13 PM, Marques Johansson marq...@displague.com wrote: snip And what if the image was named images/flower (using the accept header to send a jpg vs png vs gif) instead of flower.jpg. The browser would need to have rules about how to rewrite the name of the file. I think @ in the filename would break the many Dos 6.22 based web servers ;-). I don't think a single element with a single attribute can handle this problem. What about an HTTP header like: Accept: image/*;ppiratio=2 This would allow the server to send the correct images for that client or return a 307 to the rewritten filename as the server deems fit. A new Accept property doesn't seem to require changing any specs. I'ld like to think that image/*;q=x could be used in some way for this. On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan a...@aralbalkan.com wrote: I just submitted a proposal for a new meta tag to flag that high-resolution images are available and should be loaded in place of low-resolution ones for users with high-PPI displays (like the new iPhone 4's Retina display). Please see: http://wiki.whatwg.org/wiki/MetaExtensions#Proposals snip
Re: [whatwg] Resolutions meta tag proposal
On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan a...@aralbalkan.com wrote: I just submitted a proposal for a new meta tag to flag that high-resolution images are available and should be loaded in place of low-resolution ones for users with high-PPI displays (like the new iPhone 4's Retina display). Please see: http://wiki.whatwg.org/wiki/MetaExtensions#Proposals I don't know what the right solution is for this problem (other than use SVG :) ), but I don't think your proposal is workable. Inevitably, some images will be available in different sizes and some not, but your proposed meta tag will affect all images on the page. Also, the author needs to be able to control the names of the resized images to fit their needs -- on a site allowing user-uploaded images, for instance, you might not be able to guarantee that there isn't already a file named flo...@2x.jpg in the directory. The most natural way to do something like this is probably along the lines of content negotiation, but as we all know, that doesn't work well in practice because it's hard for authors to set up. Ideally, you could have the browser include a Resolution: header or something like that, saying what resolution it expects to see, and then the web server should automatically try resizing the image to match (using appropriate caching). But this is too hard to deploy and control. So I don't have any really good ideas.
Re: [whatwg] Resolutions meta tag proposal
On 2 July 2010 14:28, Aral Balkan a...@aralbalkan.com wrote: Hi Marques, I'm an interaction designer/developer, not a rocket scientist. :) A meta tag, I can easily add. If you start talking about HTTP headers, you've lost me. i.e., this is meant to be a pragmatic, easy-to-author solution. I think this point Aral made is very important. This is the kind of stuff that falls under the sphere of the designer/markup author, who might not have control on the webserver configuration. If there is a solution (or solutions), there should exist at least one in the realm of the markup. That's not to say there can't be more than one way of doing this.. content negotiation sounds good, too. I've been musing over this since I read Aral's post... I've been leaning towards a mixture of media queries and a base tag... to specify a different folder for each resolution... but, as it's been pointed out here this would apply to all img tags. This brings me to another question... shouldn't the same exist for all kinds of visual media resources? Thinking img, video, object and possibly iframe. (alt-option 1) Trying to step away from the solution presented, I can only imagine something along the lines of different src attributes for different resolutions: img src=imgs/standard-def.png src-2x=imgs/high-def.png video src=movs/sd.ogv src-2x=movs/hd.ogv But this might be pushing the syntax a bit too further... but it gracefully degrades and can be controlled on a per element basis. (alt-option 2) Or maybe allow an approach similiar to video tag for imgs? img source src= media=..insert media query here.. ? -- André Luís http://id.andr3.net/ On 2 July 2010 18:22, Aryeh Gregor simetrical+...@gmail.com wrote: On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan a...@aralbalkan.com wrote: I just submitted a proposal for a new meta tag to flag that high-resolution images are available and should be loaded in place of low-resolution ones for users with high-PPI displays (like the new iPhone 4's Retina display). Please see: http://wiki.whatwg.org/wiki/MetaExtensions#Proposals I don't know what the right solution is for this problem (other than use SVG :) ), but I don't think your proposal is workable. Inevitably, some images will be available in different sizes and some not, but your proposed meta tag will affect all images on the page. Also, the author needs to be able to control the names of the resized images to fit their needs -- on a site allowing user-uploaded images, for instance, you might not be able to guarantee that there isn't already a file named flo...@2x.jpg in the directory. The most natural way to do something like this is probably along the lines of content negotiation, but as we all know, that doesn't work well in practice because it's hard for authors to set up. Ideally, you could have the browser include a Resolution: header or something like that, saying what resolution it expects to see, and then the web server should automatically try resizing the image to match (using appropriate caching). But this is too hard to deploy and control. So I don't have any really good ideas.
