Re: [whatwg] add html-attribute for responsive images
I'm also late in this discussion but followed it globally. Maybe a structure like Microdata's itemref= is an option too. You could do: img src=default.jpg alt=An image srcref=placeholder img1-a img1-b img1-c img src=default2.jpg alt=Another image srcref=placeholder img2-a img2-b img2-c src href=placeholder.jpg id=placeholder media=max-width:320px src href=small.jpg id=img1-a media=min-width:320px src href=medium.jpg id=img1-b media=min-width:720px src href=large.jpg id=img1-c media=min-width:1200px src href=small2.jpg id=img2-a media=min-width:320px src href=medium2.jpg id=img2-b media=min-width:720px src href=large2.jpg id=img2-c media=min-width:1200px This gives you the ability to share the sources with multiple img elements. For example when you have a placeholder image for devices that you do not support. Tim On Feb 8, 2012, at 7:29 PM, Jason Grigsby wrote: On Feb 8, 2012, at 8:54 AM, FOUSHEE, SEAN wrote: I'm late to this discussion so pardon me if this has already been discussed, by using the same logic as thesrclist why not just createfiglist to go along with thefigure element? When a bunch of us discussed this on an etherpad a while back, we ruledfigure out because: * Completely redefines semantics and content model of an already new element. * Current use includes multiple images * Current use includes non-images like code samples, video, etc. https://etherpad.mozilla.org/responsive-assets Of course, this doesn’t mean we were right about ruling it out. :-) -Jason Thanks for the clarification. The fact that thefigure element is structured to allow us to define multiple images seems like a good fit for this approach, especially since it's going to end up using the new tag(s) anyway if the page needs to group multiple responsive images together: figure img src=default1.jpg alt= list=firstimage srclist id=firstimage source href=small1.jpg media=min-width:320px source href=medium1.jpg media=min-width:720px source href=fullsize1.jpg media=min-width:1200px /srclist img src=default2.jpg alt= list=secondimage srclist id=secondimage source href=small2.jpg media=min-width:320px source href=medium2.jpg media=min-width:720px source href=fullsize2.jpg media=min-width:1200px /srclist !-- etc etc etc -- figcaptionMultiple responsive images grouped in the figure element/figcaption /figure But I agree with David that this feels very bloated, and honestly I'd hate to think of the things my students would throw at me if I were to present this as the approach to handle responsive images in HTML. It's bad enough we have to encode and serve up at least three different video formats with a possible fallback just to utilize thevideo tag, but to do this for every image would be a nightmare. Sean Fousheé Instructor, Graphic Communications Tarrant County College, NE Campus 828 Harwood Rd. Hurst, TX 76054 (817) 515.6596 sean.fous...@tccd.edumailto:sean.fous...@tccd.edu
Re: [whatwg] add html-attribute for responsive images
Tim, Very good suggestion. This would allow us to keep our markup clean and stash these extra references elsewhere in the code as we see fit. +1 -- Jordan Dobson • Designer / Developer • 425-444-8014 • JordanDobson.com On Thu, Feb 9, 2012 at 3:11 AM, Tim van Oostrom t...@depulz.nl wrote: I'm also late in this discussion but followed it globally. Maybe a structure like Microdata's itemref= is an option too. You could do: img src=default.jpg alt=An image srcref=placeholder img1-a img1-b img1-c img src=default2.jpg alt=Another image srcref=placeholder img2-a img2-b img2-c src href=placeholder.jpg id=placeholder media=max-width:320px src href=small.jpg id=img1-a media=min-width:320px src href=medium.jpg id=img1-b media=min-width:720px src href=large.jpg id=img1-c media=min-width:1200px src href=small2.jpg id=img2-a media=min-width:320px src href=medium2.jpg id=img2-b media=min-width:720px src href=large2.jpg id=img2-c media=min-width:1200px This gives you the ability to share the sources with multiple img elements. For example when you have a placeholder image for devices that you do not support. Tim On Feb 8, 2012, at 7:29 PM, Jason Grigsby wrote: On Feb 8, 2012, at 8:54 AM, FOUSHEE, SEAN wrote: I'm late to this discussion so pardon me if this has already been discussed, by using the same logic as thesrclist why not just createfiglist to go along with thefigure element? When a bunch of us discussed this on an etherpad a while back, we ruledfigure out because: * Completely redefines semantics and content model of an already new element. * Current use includes multiple images * Current use includes non-images like code samples, video, etc. https://etherpad.mozilla.org/**responsive-assetshttps://etherpad.mozilla.org/responsive-assets Of course, this doesn’t mean we were right about ruling it out. :-) -Jason Thanks for the clarification. The fact that thefigure element is structured to allow us to define multiple images seems like a good fit for this approach, especially since it's going to end up using the new tag(s) anyway if the page needs to group multiple responsive images together: figure img src=default1.jpg alt= list=firstimage srclist id=firstimage source href=small1.jpg media=min-width:320px source href=medium1.jpg media=min-width:720px source href=fullsize1.jpg media=min-width:1200px /srclist img src=default2.jpg alt= list=secondimage srclist id=secondimage source href=small2.jpg media=min-width:320px source href=medium2.jpg media=min-width:720px source href=fullsize2.jpg media=min-width:1200px /srclist !-- etc etc etc -- figcaptionMultiple responsive images grouped in the figure element/figcaption /figure But I agree with David that this feels very bloated, and honestly I'd hate to think of the things my students would throw at me if I were to present this as the approach to handle responsive images in HTML. It's bad enough we have to encode and serve up at least three different video formats with a possible fallback just to utilize thevideo tag, but to do this for every image would be a nightmare. Sean Fousheé Instructor, Graphic Communications Tarrant County College, NE Campus 828 Harwood Rd. Hurst, TX 76054 (817) 515.6596 sean.fous...@tccd.edumailto:s**ean.fous...@tccd.edusean.fous...@tccd.edu
Re: [whatwg] add html-attribute for responsive images
On Wed, 08 Feb 2012 17:16:36 -, Anselm Hannemann - Novolo Designagentur ans...@novolo.de wrote: Okay, I talked with some disabled web developers and Accessibility experts today and talked about the proposal of markup in alt-text. This seems not to be a good idea as screenreader would read the tags which would confuse many users then. So we would get into trouble with that approach according to current screenreader features, etc. This applies only to attributes. Elements can and do have element children, while attributes can only contain plain text. We should not redefine the alt attribute. A new element has been proposed in the list whose contents can be defined to be an alternative representation of the linked resource. Preferably we could just reuse elements and semantics where appropriate. Object data=lolcats.gif title=An animated image macro of mine type=image/gif pbNazi Cats/b/p pHumans have been obsoleted./p /Object Object data=lolcat.gif title=An animated image macro of mine type=image/gif Img src=lolcat.jpeg title=An image macro of mine alt=Nazi Cats. Humans are now obsolete. /Object As has been pointed out in the thread already, using object fallbacks of different media types may result in strange behavior, and is hard to implement correctly.
Re: [whatwg] add html-attribute for responsive images
On Feb 9, 2012, at 6:36 AM, Jordan Dobson jordandob...@gmail.com wrote: Tim, Very good suggestion. This would allow us to keep our markup clean and stash these extra references elsewhere in the code as we see fit. +1 -- Jordan Dobson • Designer / Developer • 425-444-8014 • JordanDobson.com On Thu, Feb 9, 2012 at 3:11 AM, Tim van Oostrom t...@depulz.nl wrote: I'm also late in this discussion but followed it globally. Maybe a structure like Microdata's itemref= is an option too. You could do: img src=default.jpg alt=An image srcref=placeholder img1-a img1-b img1-c img src=default2.jpg alt=Another image srcref=placeholder img2-a img2-b img2-c src href=placeholder.jpg id=placeholder media=max-width:320px src href=small.jpg id=img1-a media=min-width:320px src href=medium.jpg id=img1-b media=min-width:720px src href=large.jpg id=img1-c media=min-width:1200px src href=small2.jpg id=img2-a media=min-width:320px src href=medium2.jpg id=img2-b media=min-width:720px src href=large2.jpg id=img2-c media=min-width:1200px This gives you the ability to share the sources with multiple img elements. For example when you have a placeholder image for devices that you do not support. Unfortunately we were informed early on that it was very unlikely we’d ever get a vendor to sign off on a pattern that involves “looking ahead” on an img tag. Modifying the behavior of img itself doesn’t sound viable. I worry that we’re all getting hung up on throwing ideas around—which is understandable for sure, and this is some great conversation. I think the bottom line is that we’re all in agreement on what’s needed, exact implementation aside: a markup-based means of delivering alternate image sources based on device capabilities, to prevent wasted bandwidth and optimize display on screen and in print. From an accessibility standpoint, it should at the very least equal img’s alt tag. For non-supporting browsers, fallback content should be displayed. If we all agree on these key points—and that there’s a clear need and an obvious benefit to the users—I should think we’re ready to carry this conversation forward and start ironing out the technical details elsewhere, alongside the vendors.
Re: [whatwg] add html-attribute for responsive images
2012/2/8 Kornel Lesiński kor...@geekhood.net: For DPI/filesize selection I'd prefer something simpler: picture src=large.jpg lowsrc=small.jpg !-- or source high-dpi-href= or such -- alternative emtext/em /picture Authors want the flexibility of having as few or as many source elements as they want with whatever media queries they want, not preset attributes. I don't think this would be adopted. When browser has a high-quality image the cached already, but media query for network-connection: gprs matches, it would be shame to force it to switch to a lousy image. True. But that's mostly likely to happen on a phone, where its most unlikley to have a high-quality image cached in the first place. For me the immediate use case today is not serving an unnecessarily large image (e.g bigger than the screen) to a browser, so it's less wasteful, faster to load, and faster to render (whatever the connection speed). It's not just about size or speed though. For example, your layout might be different in landscape than in portrait, so you might want a different aspect ratio version of the image. The structure of sources with media queries keeps it flexible for whatever the requirements are going forward (they will evolve).
Re: [whatwg] add html-attribute for responsive images
On 8 February 2012 07:42, Anselm Hannemann ans...@novolo.de wrote: I only have the problem with this unordered markup. In that case we don't have any wrapper for the alt-text and it would just follow as plain on the source-elements. We always should have wrappers in my mind, we have this for noscript etc, too. So why not adding altmy alternative text here/alt to the spec? picture alt=alternative text src=default.jpg img alt=alternative text src=default.jpg / source href=large.jpg media=min-width:700px / altalt text emhere/em/alt /picture If the alt text was going to be inside picture and contain markup, then yes, I'd say it should have its own element as well, otherwise the markup and DOM both become messy...but personally I'm not convinced. The existing alt attribute does the job (when it's actually *used*), so the only difference with this alt idea is being able to have text-level markup in it. How much would this improve accessibility? The current accessibility problem with the alt attribute is that authors often omit it, and an alt element won't change that. Plus, it would only apply to picture (or whatever we call it) - img would have to be left the way it is because it has no closing tag and therefore can't wrap the alt tag. But in that cases we're now sure we don't want the solution to serve different contents, right? I mean if we, we should use an attributed version as we then need different alt and title content, too. And from discussion before that was only two people saying we don't need that. And only one person saying we do, but that's not the point. I'd love to have *ability* (just for future use-cases which might come up and I already would have some for tablet-devices and smartphones) to add different media. e.g. we could offer a cropped image for smartphone users which has another context (maybe missing important parts of the img due to crop but it's better for smartphone usage and still has it's right to be there as an diff.image). Would love to hear what you all think about that? We're thinking along the same lines here. What I was getting as yesterday was that the different sources shouldn't necessarily have to be *literally* the same image but resized. They could be derivatives of the image (your example of cropped is good). The rule I suggest is that you must be able to successfully describe all the images with the same alt text (which goes on picture), so although the images are not visually identical they are semantically the same. The question is whether the sources can have optional alt attributes themselves so authors can more specifically describe that particular variant of the image. My hesitation only comes from wanting to keep it clean and simple, and from wanting to reinforce the requirement that the images be semantically the same.
Re: [whatwg] add html-attribute for responsive images
On 8.2.2012 10:18, David Goss wrote: On 8 February 2012 07:42, Anselm Hannemannans...@novolo.de wrote: I'd love to have *ability* (just for future use-cases which might come up and I already would have some for tablet-devices and smartphones) to add different media. e.g. we could offer a cropped image for smartphone users which has another context (maybe missing important parts of the img due to crop but it's better for smartphone usage and still has it's right to be there as an diff.image). Would love to hear what you all think about that? We're thinking along the same lines here. What I was getting as yesterday was that the differentsources shouldn't necessarily have to be *literally* the same image but resized. They could be derivatives of the image (your example of cropped is good). The rule I suggest is that you must be able to successfully describe all the images with the same alt text (which goes onpicture), so although the images are not visually identical they are semantically the same. The question is whether thesources can have optional alt attributes themselves so authors can more specifically describe that particular variant of the image. My hesitation only comes from wanting to keep it clean and simple, and from wanting to reinforce the requirement that the images be semantically the same. Hi, I think that while talking about responsive image, introducing element that would choose image based on media-query, we should explore more generic approach... any media media media=all video media=support: video source src=blabla.ogg type=video/ogg media=min-resolution: 300dpi / source src=blabla_small.ogg type=video/ogg media=max-resolution: 150dpi / source src=blabla.mp4 type=video/mp4 media=min-resolution: 300dpi / source src=blabla_small.mp4 type=video/mp4 media=max-resolution: 150dpi / /video picture src href=small.jpg alt=a headshot of Bob Flemmingmedia=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / /picture img src=blabla.png alt=blabla / /media I can imagine e.g. car presentation using this approach, with preferences based on tree position of media content. BTW adding media attribute to video (video - source) element might be useful as well... type tells a lot, but not all regarding responsive media content all goes for audio as well Brona
Re: [whatwg] add html-attribute for responsive images
Am 08.02.2012 um 10:43 schrieb Bronislav Klučka: On 8.2.2012 10:18, David Goss wrote: On 8 February 2012 07:42, Anselm Hannemannans...@novolo.de wrote: I'd love to have *ability* (just for future use-cases which might come up and I already would have some for tablet-devices and smartphones) to add different media. e.g. we could offer a cropped image for smartphone users which has another context (maybe missing important parts of the img due to crop but it's better for smartphone usage and still has it's right to be there as an diff.image). Would love to hear what you all think about that? We're thinking along the same lines here. What I was getting as yesterday was that the differentsources shouldn't necessarily have to be *literally* the same image but resized. They could be derivatives of the image (your example of cropped is good). The rule I suggest is that you must be able to successfully describe all the images with the same alt text (which goes onpicture), so although the images are not visually identical they are semantically the same. The question is whether thesources can have optional alt attributes themselves so authors can more specifically describe that particular variant of the image. My hesitation only comes from wanting to keep it clean and simple, and from wanting to reinforce the requirement that the images be semantically the same. Okay but I don't see a problem to offer this as feature. The spec could say: Initially the alt-text of the picture element is applied to all derivates. You can set own (different) alt-attributes to a specific derivate if there's the need to do that. If not set, standard alt-attribute is applied. Same goes for other image attributes like title, etc. You don't have to set this (as you specify in parental picture-alement) but you are able to do. I think we shouldn't limit ourselves just to keep it simple. And of course it's the developer's choice to keep it simple. Hi, I think that while talking about responsive image, introducing element that would choose image based on media-query, we should explore more generic approach... any media media media=all video media=support: video source src=blabla.ogg type=video/ogg media=min-resolution: 300dpi / source src=blabla_small.ogg type=video/ogg media=max-resolution: 150dpi / source src=blabla.mp4 type=video/mp4 media=min-resolution: 300dpi / source src=blabla_small.mp4 type=video/mp4 media=max-resolution: 150dpi / /video picture src href=small.jpg alt=a headshot of Bob Flemmingmedia=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / /picture img src=blabla.png alt=blabla / /media I can imagine e.g. car presentation using this approach, with preferences based on tree position of media content. BTW adding media attribute to video (video - source) element might be useful as well... type tells a lot, but not all regarding responsive media content Why do we actually need this new wrapper element? I don't see any reason for this. And what should support: media be? A new media query? Then this is up to CSS. And as far as I understood you correct you want the video to those who support video (btw which device wouldn't as it's only about the tag, not the feature itself?) and a fallback responsive image? If you have a bit more detailed valid approach where and why to use so, I think we can discuss further. But I think this would be a new topic.
Re: [whatwg] add html-attribute for responsive images
On 8.2.2012 10:59, Anselm Hannemann - Novolo Designagentur wrote: Hi, I think that while talking about responsive image, introducing element that would choose image based on media-query, we should explore more generic approach... any media media media=all video media=support: video source src=blabla.ogg type=video/ogg media=min-resolution: 300dpi / source src=blabla_small.ogg type=video/ogg media=max-resolution: 150dpi / source src=blabla.mp4 type=video/mp4 media=min-resolution: 300dpi / source src=blabla_small.mp4 type=video/mp4 media=max-resolution: 150dpi / /video picture src href=small.jpg alt=a headshot of Bob Flemmingmedia=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / /picture img src=blabla.png alt=blabla / /media I can imagine e.g. car presentation using this approach, with preferences based on tree position of media content. BTW adding media attribute to video (video - source) element might be useful as well... type tells a lot, but not all regarding responsive media content Why do we actually need this new wrapper element? I don't see any reason for this. How else would you know what the alternatives are? Imagine previous example without the media envelope? how would you know that img is ultimate fallback and picture should be taken into consideration only if not video? Without the envelope, the only way to process that would be to display all 3 media (video and 2 images) And what should support: media be? A new media query? Then this is up to CSS. And as far as I understood you correct you want the video to those who support video (btw which device wouldn't as it's only about the tag, not the feature itself?) We already have media queries which do not describe capabilities of media but state of media (width, height, orientation), one might be on low level bandwidth or costly bandwidth, or less capable device... I can imagine settings in UA that would turn off certain browser capabilities based on users choice. and a fallback responsive image? Sorry, I do not understand this question. Brona
Re: [whatwg] add html-attribute for responsive images
On 8 February 2012 09:59, whatwg-requ...@lists.whatwg.org wrote: Date: Wed, 8 Feb 2012 10:59:34 +0100 From: Anselm Hannemann - Novolo Designagentur ans...@novolo.de To: Bronislav Klu?ka bronislav.klu...@bauglir.com Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] add html-attribute for responsive images Message-ID: 3dbe5a43-987b-47b3-8245-f11bc8843...@novolo.de Content-Type: text/plain; charset=utf-8 Am 08.02.2012 um 10:43 schrieb Bronislav Klu?ka: On 8.2.2012 10:18, David Goss wrote: On 8 February 2012 07:42, Anselm Hannemannans...@novolo.de wrote: I'd love to have *ability* (just for future use-cases which might come up and I already would have some for tablet-devices and smartphones) to add different media. e.g. we could offer a cropped image for smartphone users which has another context (maybe missing important parts of the img due to crop but it's better for smartphone usage and still has it's right to be there as an diff.image). Would love to hear what you all think about that? We're thinking along the same lines here. What I was getting as yesterday was that the differentsources shouldn't necessarily have to be *literally* the same image but resized. They could be derivatives of the image (your example of cropped is good). The rule I suggest is that you must be able to successfully describe all the images with the same alt text (which goes onpicture), so although the images are not visually identical they are semantically the same. The question is whether thesources can have optional alt attributes themselves so authors can more specifically describe that particular variant of the image. My hesitation only comes from wanting to keep it clean and simple, and from wanting to reinforce the requirement that the images be semantically the same. Okay but I don't see a problem to offer this as feature. The spec could say: Initially the alt-text of the picture element is applied to all derivates. You can set own (different) alt-attributes to a specific derivate if there's the need to do that. If not set, standard alt-attribute is applied. Same goes for other image attributes like title, etc. You don't have to set this (as you specify in parental picture-alement) but you are able to do. I think we shouldn't limit ourselves just to keep it simple. And of course it's the developer's choice to keep it simple. I take your point about keeping it simple, but I'm still concerned that the alt attribute being allowed on source at all might lead people to think that the images don't have to be semantically the same. Maybe this wording: The picture element must contain an alt attribute that accurately describes the image from the src attribute and the images in all child source elements. Authors may optionally add alt attributes to child source elements to more specifically describe a variant of the image, but the parent alt attribute must still be applicable as well. Hi, I think that while talking about responsive image, introducing element that would choose image based on media-query, we should explore more generic approach... any media media media=all video media=support: video source src=blabla.ogg type=video/ogg media=min-resolution: 300dpi / source src=blabla_small.ogg type=video/ogg media=max-resolution: 150dpi / source src=blabla.mp4 type=video/mp4 media=min-resolution: 300dpi / source src=blabla_small.mp4 type=video/mp4 media=max-resolution: 150dpi / /video picture src href=small.jpg alt=a headshot of Bob Flemmingmedia=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / /picture img src=blabla.png alt=blabla / /media I can imagine e.g. car presentation using this approach, with preferences based on tree position of media content. BTW adding media attribute to video (video - source) element might be useful as well... type tells a lot, but not all regarding responsive media content Why do we actually need this new wrapper element? I don't see any reason for this. And what should support: media be? A new media query? Then this is up to CSS. And as far as I understood you correct you want the video to those who support video (btw which device wouldn't as it's only about the tag, not the feature itself?) and a fallback responsive image? If you have a bit more detailed valid approach where and why to use so, I think we can discuss further. But I think this would be a new topic. I share your skepticism. It would be nice and neat if there was a media element with a common structure for images, video and audio, but clearly the video and audio elements are too well established already. No sense in rocking that boat now.
Re: [whatwg] add html-attribute for responsive images
2012/2/8 Bronislav Klučka bronislav.klu...@bauglir.com: On 8.2.2012 10:59, Anselm Hannemann - Novolo Designagentur wrote: Hi, I think that while talking about responsive image, introducing element that would choose image based on media-query, we should explore more generic approach... any media media media=all video media=support: video source src=blabla.ogg type=video/ogg media=min-resolution: 300dpi / source src=blabla_small.ogg type=video/ogg media=max-resolution: 150dpi / source src=blabla.mp4 type=video/mp4 media=min-resolution: 300dpi / source src=blabla_small.mp4 type=video/mp4 media=max-resolution: 150dpi / /video picture src href=small.jpg alt=a headshot of Bob Flemmingmedia=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / /picture img src=blabla.png alt=blabla / /media I can imagine e.g. car presentation using this approach, with preferences based on tree position of media content. BTW adding media attribute to video (video - source) element might be useful as well... type tells a lot, but not all regarding responsive media content Why do we actually need this new wrapper element? I don't see any reason for this. How else would you know what the alternatives are? Another option to containment would be referencing: add a @srclist attribute on img that points to a srclist container of src elements. Compare @list and @datalist: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#attr-input-list http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-datalist-element -- Benjamin Hawkes-Lewis
Re: [whatwg] add html-attribute for responsive images
On 8.2.2012 11:24, David Goss wrote: I share your skepticism. It would be nice and neat if there was a media element with a common structure for images, video and audio, but clearly the video and audio elements are too well established already. No sense in rocking that boat now. This could always be introduces specifically for responsive media media alt=My new cool car source src=my_cool_car.ogg type=video/ogg media=min-width: 200px / source src=my_cool_car.mp4 type=video/mp4 media=min-width: 200px / source src=my_cool_car_small.ogg type=video/ogg media=max-width: 200px / source src=my_cool_car_small.mp4 type=video/mp4 media=max-width: 200px / source src=my_cool_car.png media=min-width: 200px / source src=my_cool_car_small.png media=max-width: 200px / img src=my_cool_car_fallback.gif alt=My new cool car / /media Brona
Re: [whatwg] add html-attribute for responsive images
On 8.2.2012 11:23, Benjamin Hawkes-Lewis wrote: 2012/2/8 Bronislav Klučkabronislav.klu...@bauglir.com: On 8.2.2012 10:59, Anselm Hannemann - Novolo Designagentur wrote: Hi, I think that while talking about responsive image, introducing element that would choose image based on media-query, we should explore more generic approach... any media media media=all video media=support: video source src=blabla.ogg type=video/ogg media=min-resolution: 300dpi / source src=blabla_small.ogg type=video/ogg media=max-resolution: 150dpi / source src=blabla.mp4 type=video/mp4 media=min-resolution: 300dpi / source src=blabla_small.mp4 type=video/mp4 media=max-resolution: 150dpi / /video picture src href=small.jpg alt=a headshot of Bob Flemmingmedia=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / /picture img src=blabla.png alt=blabla / /media I can imagine e.g. car presentation using this approach, with preferences based on tree position of media content. BTW adding media attribute to video (video -source) element might be useful as well... type tells a lot, but not all regarding responsive media content Why do we actually need this new wrapper element? I don't see any reason for this. How else would you know what the alternatives are? Another option to containment would be referencing: add a @srclist attribute on img that points to asrclist container of src elements. Compare @list and @datalist: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#attr-input-list http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-datalist-element -- Benjamin Hawkes-Lewis Well such idea would be more messy regarding reading the code, but definitely have the advantage of possible reuse of such set. Brona
Re: [whatwg] add html-attribute for responsive images
On 8 February 2012 10:23:02 +, Benjamin Hawkes-Lewis wrote: Another option to containment would be referencing: add a @srclist attribute on img that points to a srclist container of src elements. Compare @list and @datalist: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#attr-input-list http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-datalist-element Oh, interesting. So this: picture alt=alternative text src=default.jpg source href=medium.jpg media=min-width:400px / source href=large.jpg media=min-width:700px / img alt=alternative text src=default.jpg / /picture Becomes this: img alt=alternative text src=default.jpg list=myimage / srclist id=myimage source href=medium.jpg media=min-width:400px / source href=large.jpg media=min-width:700px / /srclist In supprting browsers, the src attribute on the img is used unless it has a list attribute which refers to a valid srclist with one or more media matched source elements, in which case the last matched one of those is used. Unsupporting browsers render the img as is and ignore the srclist. Pros: nice clean markup, gets rid of that duplication of attributes between img and picture that I dislike. Also gets away from the awkward problem of having to think of a decent name for the new element (any situation where there are two different elements for images is going to confuse new authors). Con: you need a unique id attribute for the srclist of every adaptive image on your page. Bit of a headache for authors, although I suppose any use case with a large number of adaptive images on one page is going to be server-generated rather than hand-authored, so the logic can be modified to add ids easily enough. Thoughts anyone?
Re: [whatwg] add html-attribute for responsive images
If using a single object element for embedding in general would be too hard on implementations (although the markup cleanliness is tempting), can we not (re)use video for both animated and still 2D images?
Re: [whatwg] add html-attribute for responsive images
On Feb 8, 2012, at 8:38 AM, David Goss wrote: picture alt=alternative text src=default.jpg source href=medium.jpg media=min-width:400px / source href=large.jpg media=min-width:700px / img alt=alternative text src=default.jpg / /picture Becomes this: img alt=alternative text src=default.jpg list=myimage / srclist id=myimage source href=medium.jpg media=min-width:400px / source href=large.jpg media=min-width:700px / /srclist This feels a bit convoluted to me, to be honest—the addition of the non-semantic, non-display srclist gives me the creeps. It also leave us with two different markup patterns that serve the same goal, though not radically different by any means. Don’t get me wrong: I’d be okay with this pattern—hell, I’m receptive to any potential solution. I just feel there’s something to be said for keeping the element consistent and self-contained.
Re: [whatwg] add html-attribute for responsive images
I'm late to this discussion so pardon me if this has already been discussed, by using the same logic as the srclist why not just create figlist to go along with the figure element? Sean Fousheé Instructor, Graphic Communications Tarrant County College, NE Campus 828 Harwood Rd. Hurst, TX 76054 (817) 515.6596 sean.fous...@tccd.edumailto:sean.fous...@tccd.edu On Feb 8, 2012, at 7:38 AM, David Goss wrote: On 8 February 2012 10:23:02 +, Benjamin Hawkes-Lewis wrote: Another option to containment would be referencing: add a @srclist attribute on img that points to a srclist container of src elements. Compare @list and @datalist: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#attr-input-list http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-datalist-element Oh, interesting. So this: picture alt=alternative text src=default.jpg source href=medium.jpg media=min-width:400px / source href=large.jpg media=min-width:700px / img alt=alternative text src=default.jpg / /picture Becomes this: img alt=alternative text src=default.jpg list=myimage / srclist id=myimage source href=medium.jpg media=min-width:400px / source href=large.jpg media=min-width:700px / /srclist In supprting browsers, the src attribute on the img is used unless it has a list attribute which refers to a valid srclist with one or more media matched source elements, in which case the last matched one of those is used. Unsupporting browsers render the img as is and ignore the srclist. Pros: nice clean markup, gets rid of that duplication of attributes between img and picture that I dislike. Also gets away from the awkward problem of having to think of a decent name for the new element (any situation where there are two different elements for images is going to confuse new authors). Con: you need a unique id attribute for the srclist of every adaptive image on your page. Bit of a headache for authors, although I suppose any use case with a large number of adaptive images on one page is going to be server-generated rather than hand-authored, so the logic can be modified to add ids easily enough. Thoughts anyone?
Re: [whatwg] add html-attribute for responsive images
Okay, I talked with some disabled web developers and Accessibility experts today and talked about the proposal of markup in alt-text. This seems not to be a good idea as screenreader would read the tags which would confuse many users then. So we would get into trouble with that approach according to current screenreader features, etc. I think this should be postponed as it would need a whole rewrite to many (!) element-specs. We should now focus on the initial problem and let alt contents be plaintext for now. You might start a whole new discussion about this in a separate email but this would target all html-elements having alt-attributes. Am 08.02.2012 um 11:18 schrieb Kornel Lesiński: On 8 lut 2012, at 07:14, Anselm Hannemann ans...@novolo.de wrote: picture alt=alternative text src=default.jpg source href=large.jpg media=min-width:700px / img alt=alternative text src=default.jpg / /picture A new element may be an opportunity to get the alt right, i.e. in element's body, not flattened in an attribute. Is there a reason for this? I think this is more confusing than everything else. And, an alternative text shouldn't have markup. Alternative text should be all for accessibility. If my alternative text contains an abbreviation, shouldn't I be able to use abbr? If it's a comic strip, why should I be forbidden from marking up the dialog accurately? HTML already has in-element fallback for object and limited markup in button. picture src=large.jpg lowsrc=small.jpg !-- or source high-dpi-href= or such -- alternative emtext/em /picture as it's going to be very hard to write a media query that takes into account various screen sizes, DPI and bandwidth/metering at the same time. This is similar to my approach using the common img-tag. In that case we don't need a new element. But as you've said many people (also here) find it a bit hard to write. Imagine using 6 different image sizes in that case… True. I like your approach too. I think for bandwidth-saving having more than 2-3 versions (50, 100, 300 dpi) is an overkill, so length of attributes won't be a problem.
Re: [whatwg] add html-attribute for responsive images
On Wed, 08 Feb 2012 09:06:36 -, David Goss dvdg...@gmail.com wrote: When browser has a high-quality image the cached already, but media query for network-connection: gprs matches, it would be shame to force it to switch to a lousy image. True. But that's mostly likely to happen on a phone, where its most unlikley to have a high-quality image cached in the first place. I use RSS reader which preloads all images when I'm on Wi-Fi, but I read those feeds when I'm on the go, and often even off-line (BTW: which media query would match off-line?) I would be disappointed if my phone supported media queries that tell it to discard high-quality images it has preloaded and spend extra time downloading worse versions. It's not just about size or speed though. For example, your layout might be different in landscape than in portrait, so you might want a different aspect ratio version of the image. I agree with that, and I think these may be two distinct use-cases, which are best served by different solutions. If image has different ratio and/or is cropped differently for purpose of page's layout, then it's important for the browser to respect that — that's part of the design, and that has been an artistic decision by the page author. But selection between heavily compressed and higher-fidelity version of the same image (with same ratio, same content) is just an optimisation. It doesn't require authors' judgement. Selection of the version can be expressed by an algorithm, and it's fine for the browser to pick higher-resolution image if it has it in the cache, rather than respect media queries exactly as written. It's also orthogonal to the layout issue — you may want to have landscape and portrait versions of the image for both regular and high-dpi displays (or slow and fast networks). So instead of combination of four media queries (which would get quite verbose if you were going to take into account several factors, not just network speed) I think it would be better to combine two very simple media queries for orientation with simple declaration of adaptive image resolution (that makes browser automatically take into account screen size/density and network speed, without needing details spelled out by the page author). -- regards, Kornel Lesiński
Re: [whatwg] add html-attribute for responsive images
2012/2/8 Anselm Hannemann - Novolo Designagentur ans...@novolo.de: Okay, I talked with some disabled web developers and Accessibility experts today and talked about the proposal of markup in alt-text. This seems not to be a good idea as screenreader would read the tags which would confuse many users then. No, a screenreader wouldn't read the tags. Maybe the people you talked to imagined you were talking about placing escaped markup into an attribute? -- Benjamin Hawkes-Lewis
Re: [whatwg] add html-attribute for responsive images
On Wed, Feb 8, 2012 at 1:52 PM, Mathew Marquis m...@matmarquis.com wrote: On Feb 8, 2012, at 8:38 AM, David Goss wrote: picture alt=alternative text src=default.jpg source href=medium.jpg media=min-width:400px / source href=large.jpg media=min-width:700px / img alt=alternative text src=default.jpg / /picture Becomes this: img alt=alternative text src=default.jpg list=myimage / srclist id=myimage source href=medium.jpg media=min-width:400px / source href=large.jpg media=min-width:700px / /srclist This feels a bit convoluted to me, to be honest Fair enough. I'm not recommending the one pattern over the other at this point - just saying we do have an additional option. —the addition of the non-semantic, non-display srclist gives me the creeps non-semantic in what sense? Why does a non-display element give you the creeps? Do head, meta, input type=hidden, param, source, object fallback content, and @hidden also give you the creeps? I just feel there’s something to be said for keeping the element consistent and self-contained. self-contained I'll grant, but consistent with what? -- Benjamin Hawkes-Lewis
Re: [whatwg] add html-attribute for responsive images
On Feb 8, 2012, at 8:54 AM, FOUSHEE, SEAN wrote: I'm late to this discussion so pardon me if this has already been discussed, by using the same logic as the srclist why not just create figlist to go along with the figure element? When a bunch of us discussed this on an etherpad a while back, we ruled figure out because: * Completely redefines semantics and content model of an already new element. * Current use includes multiple images * Current use includes non-images like code samples, video, etc. https://etherpad.mozilla.org/responsive-assets Of course, this doesn’t mean we were right about ruling it out. :-) -Jason
Re: [whatwg] add html-attribute for responsive images
On Feb 8, 2012, at 7:29 PM, Jason Grigsby wrote: On Feb 8, 2012, at 8:54 AM, FOUSHEE, SEAN wrote: I'm late to this discussion so pardon me if this has already been discussed, by using the same logic as the srclist why not just create figlist to go along with the figure element? When a bunch of us discussed this on an etherpad a while back, we ruled figure out because: * Completely redefines semantics and content model of an already new element. * Current use includes multiple images * Current use includes non-images like code samples, video, etc. https://etherpad.mozilla.org/responsive-assets Of course, this doesn’t mean we were right about ruling it out. :-) -Jason Thanks for the clarification. The fact that the figure element is structured to allow us to define multiple images seems like a good fit for this approach, especially since it's going to end up using the new tag(s) anyway if the page needs to group multiple responsive images together: figure img src=default1.jpg alt= list=firstimage srclist id=firstimage source href=small1.jpg media=min-width:320px source href=medium1.jpg media=min-width:720px source href=fullsize1.jpg media=min-width:1200px /srclist img src=default2.jpg alt= list=secondimage srclist id=secondimage source href=small2.jpg media=min-width:320px source href=medium2.jpg media=min-width:720px source href=fullsize2.jpg media=min-width:1200px /srclist !-- etc etc etc -- figcaptionMultiple responsive images grouped in the figure element/figcaption /figure But I agree with David that this feels very bloated, and honestly I'd hate to think of the things my students would throw at me if I were to present this as the approach to handle responsive images in HTML. It's bad enough we have to encode and serve up at least three different video formats with a possible fallback just to utilize the video tag, but to do this for every image would be a nightmare. Sean Fousheé Instructor, Graphic Communications Tarrant County College, NE Campus 828 Harwood Rd. Hurst, TX 76054 (817) 515.6596 sean.fous...@tccd.edumailto:sean.fous...@tccd.edu
Re: [whatwg] add html-attribute for responsive images
Ashley, so you think about the img element attributes like I proposed? img src=myimage_xs.jpg media-xs=(min-device-width:320px and max-device-width:640px) media-src-xs=myimage_xs.jpg media-m=(min-device-width:640px and max-device-width:1024px) media-src-m=myimage_m.jpg media-xl=(min-device-width:1024px) media-src-xl=myimage_xsl.jpg (View as gist: https://gist.github.com/1158855) Or did I misunderstood you? -Anselm Am 07.02.2012 um 10:45 schrieb Ashley Sheridan: On Mon, 2012-02-06 at 23:15 +, Bjartur Thorlacius wrote: On Mon, 06 Feb 2012 21:23:37 -, Mathew Marquis m...@matmarquis.com wrote: I recently published a sum-up of our thinking at A List Apart ( http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ )—in short, using the video markup pattern as the inspiration, with the use of media attributes on the source elements to determine the rendered source, and the inclusion of an img--ideally a smaller image, to account for the lowest-common-denominator--as a fallback similar to the way Flash or an image might be used as a video fallback. Why not use a media attribute of object? That way you should get media type disambiguation for free. The main problem I see with that is that the object tag doesn't have the same accessibility attributes, so you'd effectively lock out a lot of people using browsers that don't understand the context of the tag in this case. I think the better way is to add something to the img tag as you'd still have full backwards compatibility. -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] add html-attribute for responsive images
On Tue, 2012-02-07 at 10:49 +0100, Anselm Hannemann – Novolo Designagentur wrote: Ashley, so you think about the img element attributes like I proposed? img src=myimage_xs.jpg media-xs=(min-device-width:320px and max-device-width:640px) media-src-xs=myimage_xs.jpg media-m=(min-device-width:640px and max-device-width:1024px) media-src-m=myimage_m.jpg media-xl=(min-device-width:1024px) media-src-xl=myimage_xsl.jpg (View as gist: https://gist.github.com/1158855) Or did I misunderstood you? -Anselm Am 07.02.2012 um 10:45 schrieb Ashley Sheridan: On Mon, 2012-02-06 at 23:15 +, Bjartur Thorlacius wrote: On Mon, 06 Feb 2012 21:23:37 -, Mathew Marquis m...@matmarquis.com wrote: I recently published a sum-up of our thinking at A List Apart ( http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ )—in short, using the video markup pattern as the inspiration, with the use of media attributes on the source elements to determine the rendered source, and the inclusion of an img--ideally a smaller image, to account for the lowest-common-denominator--as a fallback similar to the way Flash or an image might be used as a video fallback. Why not use a media attribute of object? That way you should get media type disambiguation for free. The main problem I see with that is that the object tag doesn't have the same accessibility attributes, so you'd effectively lock out a lot of people using browsers that don't understand the context of the tag in this case. I think the better way is to add something to the img tag as you'd still have full backwards compatibility. -- Thanks, Ash http://www.ashleysheridan.co.uk Yeah, that seems along the right lines to me, although I'd probably not use the media-xs type attributes, and just instead use one attribute with comma delimited value parameters like: img src=image_for_old_browsers.jpg media-src=min-width: 1300px and max-width: 1600px url(huge_image.jpg), min-width: 300px and max-width: 600px url(small_image.jpg)/ It does look ugly, but I think it's easier to only need to remember one attribute rather than a bunch; the fewer changes required for this to work would surely be better? -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] add html-attribute for responsive images
@Mathew Marquis - that was a good article, I was so pleased to see the thinking behind it getting some attention at last! I've been trying to push this idea since launching adaptive-images.com , and a number of people have come up with the same client-side quasi-solution independently. Bruce Lawson's mark-up suggestion was the first example I'm aware of and I've linked to it on the list before. 2012/2/7 Anselm Hannemann – Novolo Designagentur ans...@novolo.de Ashley, so you think about the img element attributes like I proposed? img src=myimage_xs.jpg media-xs=(min-device-width:320px and max-device-width:640px) media-src-xs=myimage_xs.jpg media-m=(min-device-width:640px and max-device-width:1024px) media-src-m=myimage_m.jpg media-xl=(min-device-width:1024px) media-src-xl=myimage_xsl.jpg (View as gist: https://gist.github.com/1158855) This, to me, is WAY too over-wrought to be useful. Readability is a feature of HTML and this kind of kills that a little - it looks like something some automated solution would spit out, not what a human would author. I can't imagine it getting much uptake with web developers for that reason alone (I put my hand up, I'm a member of that fickle bunch). To me this makes most sense /from an author perspective/ (I make no claims as to how practical this really is): picture src href=small.jpg alt=a headshot of Bob Flemming media=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / !-- fallback for old browsers with no support for picture element) -- img src=default.jpg alt=A photo of Bob Flemming / /picture The reason being: * it's easy to read * it uses familiar element structures and properties * it allows us to adjust to any given media requirement, not just screen size (you could query bandwidth with this syntax, though I contest bandwidth is the domain of server side adaption rather than client side)
Re: [whatwg] add html-attribute for responsive images
Am 07.02.2012 um 11:16 schrieb Matthew Wilcox: 2012/2/7 Anselm Hannemann – Novolo Designagentur ans...@novolo.de Ashley, so you think about the img element attributes like I proposed? img src=myimage_xs.jpg media-xs=(min-device-width:320px and max-device-width:640px) media-src-xs=myimage_xs.jpg media-m=(min-device-width:640px and max-device-width:1024px) media-src-m=myimage_m.jpg media-xl=(min-device-width:1024px) media-src-xl=myimage_xsl.jpg (View as gist: https://gist.github.com/1158855) This, to me, is WAY too over-wrought to be useful. Readability is a feature of HTML and this kind of kills that a little - it looks like something some automated solution would spit out, not what a human would author. I can't imagine it getting much uptake with web developers for that reason alone (I put my hand up, I'm a member of that fickle bunch). Yeah this is indeed true. I just want this as an option which is a semantically valid approach. But you're totally right at readability. To me this makes most sense /from an author perspective/ (I make no claims as to how practical this really is): picture src href=small.jpg alt=a headshot of Bob Flemming media=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / !-- fallback for old browsers with no support for picture element) -- img src=default.jpg alt=A photo of Bob Flemming / /picture The reason being: * it's easy to read * it uses familiar element structures and properties * it allows us to adjust to any given media requirement, not just screen size (you could query bandwidth with this syntax, though I contest bandwidth is the domain of server side adaption rather than client side) This is a good solution except the fallback img element would be twice loaded in your case which is not good. There should be the img element containing the standard (normal) size and src elements to add diff. other resolutions. With that the browser won't load the resource twice.
Re: [whatwg] add html-attribute for responsive images
Can you clarify why the image would be loaded twice? Can we not, as part of the logic for the picture element, say that img is ignored in supporting browsers? Thus, never called by a supporting browser. Non supporting browsers wouldn't load the src elements and would only load the img Right? On 7 February 2012 10:31, Anselm Hannemann ans...@novolo.de wrote: Am 07.02.2012 um 11:16 schrieb Matthew Wilcox: 2012/2/7 Anselm Hannemann – Novolo Designagentur ans...@novolo.de Ashley, so you think about the img element attributes like I proposed? img src=myimage_xs.jpg media-xs=(min-device-width:320px and max-device-width:640px) media-src-xs=myimage_xs.jpg media-m=(min-device-width:640px and max-device-width:1024px) media-src-m=myimage_m.jpg media-xl=(min-device-width:1024px) media-src-xl=myimage_xsl.jpg (View as gist: https://gist.github.com/1158855) This, to me, is WAY too over-wrought to be useful. Readability is a feature of HTML and this kind of kills that a little - it looks like something some automated solution would spit out, not what a human would author. I can't imagine it getting much uptake with web developers for that reason alone (I put my hand up, I'm a member of that fickle bunch). Yeah this is indeed true. I just want this as an option which is a semantically valid approach. But you're totally right at readability. To me this makes most sense /from an author perspective/ (I make no claims as to how practical this really is): picture src href=small.jpg alt=a headshot of Bob Flemming media=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / !-- fallback for old browsers with no support for picture element) -- img src=default.jpg alt=A photo of Bob Flemming / /picture The reason being: * it's easy to read * it uses familiar element structures and properties * it allows us to adjust to any given media requirement, not just screen size (you could query bandwidth with this syntax, though I contest bandwidth is the domain of server side adaption rather than client side) This is a good solution except the fallback img element would be twice loaded in your case which is not good. There should be the img element containing the standard (normal) size and src elements to add diff. other resolutions. With that the browser won't load the resource twice.
Re: [whatwg] add html-attribute for responsive images
As far as I understand browsers like Chrome preparse sites where they don't actually get the DOM but load resources they find in code. So it would be impossible to say it shouldn't be loaded. See this comment about it: http://www.alistapart.com/comments/responsive-images-how-they-almost-worked-and-what-we-need/P40/#41 Am 07.02.2012 um 11:34 schrieb Matthew Wilcox: Can you clarify why the image would be loaded twice? Can we not, as part of the logic for the picture element, say that img is ignored in supporting browsers? Thus, never called by a supporting browser. Non supporting browsers wouldn't load the src elements and would only load the img Right? On 7 February 2012 10:31, Anselm Hannemann ans...@novolo.de wrote: Am 07.02.2012 um 11:16 schrieb Matthew Wilcox: 2012/2/7 Anselm Hannemann – Novolo Designagentur ans...@novolo.de Ashley, so you think about the img element attributes like I proposed? img src=myimage_xs.jpg media-xs=(min-device-width:320px and max-device-width:640px) media-src-xs=myimage_xs.jpg media-m=(min-device-width:640px and max-device-width:1024px) media-src-m=myimage_m.jpg media-xl=(min-device-width:1024px) media-src-xl=myimage_xsl.jpg (View as gist: https://gist.github.com/1158855) This, to me, is WAY too over-wrought to be useful. Readability is a feature of HTML and this kind of kills that a little - it looks like something some automated solution would spit out, not what a human would author. I can't imagine it getting much uptake with web developers for that reason alone (I put my hand up, I'm a member of that fickle bunch). Yeah this is indeed true. I just want this as an option which is a semantically valid approach. But you're totally right at readability. To me this makes most sense /from an author perspective/ (I make no claims as to how practical this really is): picture src href=small.jpg alt=a headshot of Bob Flemming media=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / !-- fallback for old browsers with no support for picture element) -- img src=default.jpg alt=A photo of Bob Flemming / /picture The reason being: * it's easy to read * it uses familiar element structures and properties * it allows us to adjust to any given media requirement, not just screen size (you could query bandwidth with this syntax, though I contest bandwidth is the domain of server side adaption rather than client side) This is a good solution except the fallback img element would be twice loaded in your case which is not good. There should be the img element containing the standard (normal) size and src elements to add diff. other resolutions. With that the browser won't load the resource twice.
Re: [whatwg] add html-attribute for responsive images
I don't have the expertise on exactly how these things function, but from my common sense approach to it surely the browser has to have encountered the picture opening tag before it can encounter the img tag in order to read the source URL for that image. At which point, would the browser not know to apply the don't load an img if it's in a picture behaviour? And if that's not the case, can we not argue the case to vendors that the pre-fetch behaviour needs to take this into account because it's the pre-fetch behaviour that is causing the harm here? On 7 February 2012 10:37, Anselm Hannemann ans...@novolo.de wrote: As far as I understand browsers like Chrome preparse sites where they don't actually get the DOM but load resources they find in code. So it would be impossible to say it shouldn't be loaded. See this comment about it: http://www.alistapart.com/comments/responsive-images-how-they-almost-worked-and-what-we-need/P40/#41 Am 07.02.2012 um 11:34 schrieb Matthew Wilcox: Can you clarify why the image would be loaded twice? Can we not, as part of the logic for the picture element, say that img is ignored in supporting browsers? Thus, never called by a supporting browser. Non supporting browsers wouldn't load the src elements and would only load the img Right? On 7 February 2012 10:31, Anselm Hannemann ans...@novolo.de wrote: Am 07.02.2012 um 11:16 schrieb Matthew Wilcox: 2012/2/7 Anselm Hannemann – Novolo Designagentur ans...@novolo.de Ashley, so you think about the img element attributes like I proposed? img src=myimage_xs.jpg media-xs=(min-device-width:320px and max-device-width:640px) media-src-xs=myimage_xs.jpg media-m=(min-device-width:640px and max-device-width:1024px) media-src-m=myimage_m.jpg media-xl=(min-device-width:1024px) media-src-xl=myimage_xsl.jpg (View as gist: https://gist.github.com/1158855) This, to me, is WAY too over-wrought to be useful. Readability is a feature of HTML and this kind of kills that a little - it looks like something some automated solution would spit out, not what a human would author. I can't imagine it getting much uptake with web developers for that reason alone (I put my hand up, I'm a member of that fickle bunch). Yeah this is indeed true. I just want this as an option which is a semantically valid approach. But you're totally right at readability. To me this makes most sense /from an author perspective/ (I make no claims as to how practical this really is): picture src href=small.jpg alt=a headshot of Bob Flemming media=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / !-- fallback for old browsers with no support for picture element) -- img src=default.jpg alt=A photo of Bob Flemming / /picture The reason being: * it's easy to read * it uses familiar element structures and properties * it allows us to adjust to any given media requirement, not just screen size (you could query bandwidth with this syntax, though I contest bandwidth is the domain of server side adaption rather than client side) This is a good solution except the fallback img element would be twice loaded in your case which is not good. There should be the img element containing the standard (normal) size and src elements to add diff. other resolutions. With that the browser won't load the resource twice.
Re: [whatwg] add html-attribute for responsive images
On Tue, 2012-02-07 at 10:56 +, Bjartur Thorlacius wrote: On 2/7/12, Ashley Sheridan a...@ashleysheridan.co.uk wrote: The main problem I see with that is that the object tag doesn't have the same accessibility attributes, so you'd effectively lock out a lot of people using browsers that don't understand the context of the tag in this case. I think the better way is to add something to the img tag as you'd still have full backwards compatibility. What accessibility features, exactly? For compatibility, the deepest child of object would be img alt, inheriting the accessibility features of img. Alternatively, it might just as well be markup, which is surely better accessibility wise than @alt and @longdesc. Furthermore, you could theoretically link to an animation, a still and a sound and embed a hypertext fallback. (I'm sorry if object's being generally terrible for accessibility has been established already.) Because browsers about now understand how to display an image in the object tag, and so won't do anything with the nested image inside of it, thus negating any benefit of the alt tag within it. Adding images that way would prevent modern browsers from being accessible. -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] add html-attribute for responsive images
On 2/7/12, Ashley Sheridan a...@ashleysheridan.co.uk wrote: The main problem I see with that is that the object tag doesn't have the same accessibility attributes, so you'd effectively lock out a lot of people using browsers that don't understand the context of the tag in this case. I think the better way is to add something to the img tag as you'd still have full backwards compatibility. What accessibility features, exactly? For compatibility, the deepest child of object would be img alt, inheriting the accessibility features of img. Alternatively, it might just as well be markup, which is surely better accessibility wise than @alt and @longdesc. Furthermore, you could theoretically link to an animation, a still and a sound and embed a hypertext fallback. (I'm sorry if object's being generally terrible for accessibility has been established already.)
Re: [whatwg] add html-attribute for responsive images
On 7 February 2012 11:31:15 +0100, Anselm Hannemann wrote: Am 07.02.2012 um 11:16 schrieb Matthew Wilcox: To me this makes most sense /from an author perspective/ (I make no claims as to how practical this really is): picture src href=small.jpg alt=a headshot of Bob Flemming media=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / !-- fallback for old browsers with no support for picture element) -- img src=default.jpg alt=A photo of Bob Flemming / /picture The reason being: * it's easy to read * it uses familiar element structures and properties * it allows us to adjust to any given media requirement, not just screen size (you could query bandwidth with this syntax, though I contest bandwidth is the domain of server side adaption rather than client side) This is a good solution except the fallback img element would be twice loaded in your case which is not good. There should be the img element containing the standard (normal) size and src elements to add diff. other resolutions. With that the browser won't load the resource twice. Would it? I think Matthew's example implies that a supporting browser *wouldn't* load the src from the img unless none of the sources got a media match. Right? The way I proposed it would have the same behaviour but have the img as the first child element of picture, making it more apparent that it's the default content as well as the fallback content. Also, it would contain important attributes like alt. So: picture img src=default.jpg alt=A photo of Bob Flemming / source href=small.jpg alt=a headshot of Bob Flemming media=min-width:320 / source href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / source href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / /picture And: - unsupporting browsers would get default.jpg (but the author could implement some JS to run the source media queries and swap in the most appropriate image if desired) - supporting browsers narrower than 320px would also get default.jpg, because none of the sources would get a media match - supporting browsers 320px or wider would get the image from the last source to get a media match (because a 800px wide screen would match all 3 in this example) I'm not really sure whether source should get an alt attribute - my thinking is that if one alt attribute doesn't correctly describe all the sources then perhaps they are different content. Matthew's example does make sense, in that the extra alt attributes describe the way the image has been cropped (although it's still the same image). But maybe it would be better to only allow alt on the img to reinforce the idea that all the sources should basically be the same image albeit cropped/monochrome/whatever. FWIW, whatever becomes of the discussion about sending media-query-like data in headers to the server (RWD Heaven: if browsers reported device capabilities in a request header), we need this responsive image markup regardless. Thanks David
Re: [whatwg] add html-attribute for responsive images
On Tuesday, Feb 7, 2012, at 7:35 AM, David Goss wrote: On 7 February 2012 11:31:15 +0100, Anselm Hannemann wrote: Am 07.02.2012 um 11:16 schrieb Matthew Wilcox: To me this makes most sense /from an author perspective/ (I make no claims as to how practical this really is): picture src href=small.jpg alt=a headshot of Bob Flemming media=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / !-- fallback for old browsers with no support for picture element) -- img src=default.jpg alt=A photo of Bob Flemming / /picture The reason being: * it's easy to read * it uses familiar element structures and properties * it allows us to adjust to any given media requirement, not just screen size (you could query bandwidth with this syntax, though I contest bandwidth is the domain of server side adaption rather than client side) This is a good solution except the fallback img element would be twice loaded in your case which is not good. There should be the img element containing the standard (normal) size and src elements to add diff. other resolutions. With that the browser won't load the resource twice. Would it? I think Matthew's example implies that a supporting browser *wouldn't* load the src from the img unless none of the sources got a media match. Right? I’m not sure how it’s intended to work with video currently, but I believe the fallback is only loaded if video is unsupported—if none of the sources match, I believe nothing is displayed. I may be wrong, but that seems to be the most predictable behavior. The way I proposed it would have the same behaviour but have the img as the first child element of picture, making it more apparent that it's the default content as well as the fallback content. Also, it would contain important attributes like alt. So: picture img src=default.jpg alt=A photo of Bob Flemming / source href=small.jpg alt=a headshot of Bob Flemming media=min-width:320 / source href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / source href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / /picture And: - unsupporting browsers would get default.jpg (but the author could implement some JS to run the source media queries and swap in the most appropriate image if desired) - supporting browsers narrower than 320px would also get default.jpg, because none of the sources would get a media match - supporting browsers 320px or wider would get the image from the last source to get a media match (because a 800px wide screen would match all 3 in this example) I'm not really sure whether source should get an alt attribute - my thinking is that if one alt attribute doesn't correctly describe all the sources then perhaps they are different content. Matthew's example does make sense, in that the extra alt attributes describe the way the image has been cropped (although it's still the same image). But maybe it would be better to only allow alt on the img to reinforce the idea that all the sources should basically be the same image albeit cropped/monochrome/whatever. I’m with you, here. I’m hesitant to have any logic hinge on the fallback img, though, as it wouldn’t be strictly required—the fallback content could be, say, descriptive text instead (Granted I wouldn’t do it, but just trying to keep things as flexible as possible). I do think all sources should be described by a single alt tag, though, possibly on picture itself? FWIW, whatever becomes of the discussion about sending media-query-like data in headers to the server (RWD Heaven: if browsers reported device capabilities in a request header), we need this responsive image markup regardless. Hear hear! Thanks David
Re: [whatwg] add html-attribute for responsive images
On Tue, Feb 7, 2012 at 1:15 AM, Bjartur Thorlacius svartma...@gmail.com wrote: Why not use a media attribute of object? There's probably already a better answer to Why not use object for foo? in the archives of this list, but the short version is that it's nicer for implementations to have elements that support particular functionality when node is created instead of having elements that change their nature substantially depending on attributes, network fetches, presence of plug-ins, etc., etc. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] add html-attribute for responsive images
I'm glad this is making a reasonable amount of sense to people :) Please note however that this isn't just a case of the image is cropped. It could be an entirely different image *as long as* it still carries the same semantic message. In that, the image in the About example is merely to give a visual representation of someone. As long as all of the scaled images do that, they do not need to be *the same image* re-cropped. In fact, it would be better in this case to have different images. Hence why it makes sense to have the ability to over-ride the alt attribute on each source. There's nothing to stop us saying that an alt attribute can be declared on the default image, and is only over-written if the src contains a new alt attribute? -Matt On 7 February 2012 13:42, Mathew Marquis m...@matmarquis.com wrote: On Tuesday, Feb 7, 2012, at 7:35 AM, David Goss wrote: On 7 February 2012 11:31:15 +0100, Anselm Hannemann wrote: Am 07.02.2012 um 11:16 schrieb Matthew Wilcox: To me this makes most sense /from an author perspective/ (I make no claims as to how practical this really is): picture src href=small.jpg alt=a headshot of Bob Flemming media=min-width:320 / src href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / src href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / !-- fallback for old browsers with no support for picture element) -- img src=default.jpg alt=A photo of Bob Flemming / /picture The reason being: * it's easy to read * it uses familiar element structures and properties * it allows us to adjust to any given media requirement, not just screen size (you could query bandwidth with this syntax, though I contest bandwidth is the domain of server side adaption rather than client side) This is a good solution except the fallback img element would be twice loaded in your case which is not good. There should be the img element containing the standard (normal) size and src elements to add diff. other resolutions. With that the browser won't load the resource twice. Would it? I think Matthew's example implies that a supporting browser *wouldn't* load the src from the img unless none of the sources got a media match. Right? I’m not sure how it’s intended to work with video currently, but I believe the fallback is only loaded if video is unsupported—if none of the sources match, I believe nothing is displayed. I may be wrong, but that seems to be the most predictable behavior. The way I proposed it would have the same behaviour but have the img as the first child element of picture, making it more apparent that it's the default content as well as the fallback content. Also, it would contain important attributes like alt. So: picture img src=default.jpg alt=A photo of Bob Flemming / source href=small.jpg alt=a headshot of Bob Flemming media=min-width:320 / source href=medium.jpg alt=a head and shoulders shot of Bob Flemming media=min-width:480 / source href=large.jpg alt=a full body portrait of Bob Flemming media=min-width:640 / /picture And: - unsupporting browsers would get default.jpg (but the author could implement some JS to run the source media queries and swap in the most appropriate image if desired) - supporting browsers narrower than 320px would also get default.jpg, because none of the sources would get a media match - supporting browsers 320px or wider would get the image from the last source to get a media match (because a 800px wide screen would match all 3 in this example) I'm not really sure whether source should get an alt attribute - my thinking is that if one alt attribute doesn't correctly describe all the sources then perhaps they are different content. Matthew's example does make sense, in that the extra alt attributes describe the way the image has been cropped (although it's still the same image). But maybe it would be better to only allow alt on the img to reinforce the idea that all the sources should basically be the same image albeit cropped/monochrome/whatever. I’m with you, here. I’m hesitant to have any logic hinge on the fallback img, though, as it wouldn’t be strictly required—the fallback content could be, say, descriptive text instead (Granted I wouldn’t do it, but just trying to keep things as flexible as possible). I do think all sources should be described by a single alt tag, though, possibly on picture itself? FWIW, whatever becomes of the discussion about sending media-query-like data in headers to the server (RWD Heaven: if browsers reported device capabilities in a request header), we need this responsive image markup regardless. Hear hear! Thanks David
Re: [whatwg] add html-attribute for responsive images
PS: I am a strong believer that we need both a server-side and client-side solution to this problem of adaptive media. They solve different aspects of what seem superficially the same things :)
Re: [whatwg] add html-attribute for responsive images
On 7 February 2012 13:42, Mathew Marquis m...@matmarquis.com wrote: On Tuesday, Feb 7, 2012, at 7:35 AM, David Goss wrote: On 7 February 2012 11:31:15 +0100, Anselm Hannemann wrote: This is a good solution except the fallback img element would be twice loaded in your case which is not good. There should be the img element containing the standard (normal) size and src elements to add diff. other resolutions. With that the browser won't load the resource twice. Would it? I think Matthew's example implies that a supporting browser *wouldn't* load the src from the img unless none of the sources got a media match. Right? I’m not sure how it’s intended to work with video currently, but I believe the fallback is only loaded if video is unsupported—if none of the sources match, I believe nothing is displayed. I may be wrong, but that seems to be the most predictable behavior. Ah, good point. video has its own src attrribute, which is where the default source goes. Then it can be overridden by the last source element with a media match, if any. I'm not really sure whether source should get an alt attribute - my thinking is that if one alt attribute doesn't correctly describe all the sources then perhaps they are different content. Matthew's example does make sense, in that the extra alt attributes describe the way the image has been cropped (although it's still the same image). But maybe it would be better to only allow alt on the img to reinforce the idea that all the sources should basically be the same image albeit cropped/monochrome/whatever. I’m with you, here. I’m hesitant to have any logic hinge on the fallback img, though, as it wouldn’t be strictly required—the fallback content could be, say, descriptive text instead (Granted I wouldn’t do it, but just trying to keep things as flexible as possible). I do think all sources should be described by a single alt tag, though, possibly on picture itself? I guess I've moved away from similarities with video, in that I've been thinking of the img as the default content, not the fallback content. Going with your angle for a simple example with two sizes: picture alt=alternative text src=default.jpg source href=large.jpg media=min-width:700px / img alt=alternative text src=default.jpg / /picture The duplication of the alt and default src attributes bothers me, but on reflection perhaps it's better to have consistency with video.
Re: [whatwg] add html-attribute for responsive images
On 7 February 2012 14:00, Matthew Wilcox m...@matthewwilcox.com wrote: I'm glad this is making a reasonable amount of sense to people :) Please note however that this isn't just a case of the image is cropped. It could be an entirely different image *as long as* it still carries the same semantic message. In that, the image in the About example is merely to give a visual representation of someone. As long as all of the scaled images do that, they do not need to be *the same image* re-cropped. In fact, it would be better in this case to have different images. Hence why it makes sense to have the ability to over-ride the alt attribute on each source. There's nothing to stop us saying that an alt attribute can be declared on the default image, and is only over-written if the src contains a new alt attribute? -Matt On Tuesday, Feb 7, 2012, at 7:35 AM, David Goss wrote: I'm not really sure whether source should get an alt attribute - my thinking is that if one alt attribute doesn't correctly describe all the sources then perhaps they are different content. Matthew's example does make sense, in that the extra alt attributes describe the way the image has been cropped (although it's still the same image). But maybe it would be better to only allow alt on the img to reinforce the idea that all the sources should basically be the same image albeit cropped/monochrome/whatever. My point is that if the two images are supposed to have the same semantic message, then you should be able to describe them both with the same alt text (even if the differences between those images make the alt text a little more vague than it might be). So, as you say, you could have two different photos of the same person for different media, but the alt text photo of Matthew Wilcox would be applicable for both, so that's fine. I'm with you in that I want the flexibility (e.g. the sources shouldn't all have to be literally the same image just resized), I just think saying all sources must correspond with same alt text gives a nice clear definition of what's okay for authors.
Re: [whatwg] add html-attribute for responsive images
That's a fair enough point. I'd /like/ to be able to over-ride the alt with something even more specific, but I do agree the core semantics should be the same - so a 'generalised' alt would work too, just be a little less informative than it could be. I could see the advantage of not allowing alt over-riding in that it forces the alt to be applicable to all sources which then strengthens the vibe that the images, although different, should have the same semantics. On 7 February 2012 14:59, David Goss dvdg...@gmail.com wrote: On 7 February 2012 14:00, Matthew Wilcox m...@matthewwilcox.com wrote: I'm glad this is making a reasonable amount of sense to people :) Please note however that this isn't just a case of the image is cropped. It could be an entirely different image *as long as* it still carries the same semantic message. In that, the image in the About example is merely to give a visual representation of someone. As long as all of the scaled images do that, they do not need to be *the same image* re-cropped. In fact, it would be better in this case to have different images. Hence why it makes sense to have the ability to over-ride the alt attribute on each source. There's nothing to stop us saying that an alt attribute can be declared on the default image, and is only over-written if the src contains a new alt attribute? -Matt On Tuesday, Feb 7, 2012, at 7:35 AM, David Goss wrote: I'm not really sure whether source should get an alt attribute - my thinking is that if one alt attribute doesn't correctly describe all the sources then perhaps they are different content. Matthew's example does make sense, in that the extra alt attributes describe the way the image has been cropped (although it's still the same image). But maybe it would be better to only allow alt on the img to reinforce the idea that all the sources should basically be the same image albeit cropped/monochrome/whatever. My point is that if the two images are supposed to have the same semantic message, then you should be able to describe them both with the same alt text (even if the differences between those images make the alt text a little more vague than it might be). So, as you say, you could have two different photos of the same person for different media, but the alt text photo of Matthew Wilcox would be applicable for both, so that's fine. I'm with you in that I want the flexibility (e.g. the sources shouldn't all have to be literally the same image just resized), I just think saying all sources must correspond with same alt text gives a nice clear definition of what's okay for authors.
Re: [whatwg] add html-attribute for responsive images
I’ve read that comment three times and still don’t grok it. :-) It seems the comment mixes lookahead pre-parsing behavior with pre-fetching and pre-rendering behavior. Compare the definitions of pre-fetching and pre-rendering in the Google Chrome documentation that the comment points to: http://code.google.com/chrome/whitepapers/prerender.html With the definition of the lookahead pre-parser from the IE team: http://blogs.msdn.com/b/ieinternals/archive/2011/07/18/optimal-html-head-ordering-to-avoid-parser-restarts-redownloads-and-improve-performance.aspx The comment also states “A pre-_render_, on the other hand, loads a page and all its content, but keeps it hidden. At the moment, it only happens on Chrome.” That was the biggest clue to me that the person was talking about something different because the IE team has written about their lookahead pre-parser. That said, it wouldn’t be the first time something went over my head. Am I wrong that the comment is talking about something different? -Jason On Feb 7, 2012, at 5:37 AM, Anselm Hannemann wrote: As far as I understand browsers like Chrome preparse sites where they don't actually get the DOM but load resources they find in code. So it would be impossible to say it shouldn't be loaded. See this comment about it: http://www.alistapart.com/comments/responsive-images-how-they-almost-worked-and-what-we-need/P40/#41
Re: [whatwg] add html-attribute for responsive images
On Tue, 07 Feb 2012 14:49:16 -, David Goss dvdg...@gmail.com wrote: I guess I've moved away from similarities with video, in that I've been thinking of the img as the default content, not the fallback content. Going with your angle for a simple example with two sizes: picture alt=alternative text src=default.jpg source href=large.jpg media=min-width:700px / img alt=alternative text src=default.jpg / /picture A new element may be an opportunity to get the alt right, i.e. in element's body, not flattened in an attribute. picture source href=wide.jpg media=orientation: landscape / source href=narrow.jpg media=orientation: portrait / img alt=alternative text src=default.jpg / alternative emtext/em /picture For DPI/filesize selection I'd prefer something simpler: picture src=large.jpg lowsrc=small.jpg !-- or source high-dpi-href= or such -- alternative emtext/em /picture as it's going to be very hard to write a media query that takes into account various screen sizes, DPI and bandwidth/metering at the same time. When browser has a high-quality image the cached already, but media query for network-connection: gprs matches, it would be shame to force it to switch to a lousy image. -- regards, Kornel Lesiński
Re: [whatwg] add html-attribute for responsive images
Am 08.02.2012 um 01:54 schrieb Kornel Lesiński: On Tue, 07 Feb 2012 14:49:16 -, David Goss dvdg...@gmail.com wrote: I guess I've moved away from similarities with video, in that I've been thinking of the img as the default content, not the fallback content. Going with your angle for a simple example with two sizes: picture alt=alternative text src=default.jpg source href=large.jpg media=min-width:700px / img alt=alternative text src=default.jpg / /picture A new element may be an opportunity to get the alt right, i.e. in element's body, not flattened in an attribute. Is there a reason for this? I think this is more confusing than everything else. And, an alternative text shouldn't have markup. Alternative text should be all for accessibility. What you thinking about might be the title-attribute. But I'm totally against this approach to do this inside the element w/o attribute. And I think screenreader won't be happy with that, too? (not sure about that). picture source href=wide.jpg media=orientation: landscape / source href=narrow.jpg media=orientation: portrait / img alt=alternative text src=default.jpg / alternative emtext/em /picture For DPI/filesize selection I'd prefer something simpler: picture src=large.jpg lowsrc=small.jpg !-- or source high-dpi-href= or such -- alternative emtext/em /picture as it's going to be very hard to write a media query that takes into account various screen sizes, DPI and bandwidth/metering at the same time. This is similar to my approach using the common img-tag. In that case we don't need a new element. But as you've said many people (also here) find it a bit hard to write. Imagine using 6 different image sizes in that case… You can read arguments some mails before on my approach. When browser has a high-quality image the cached already, but media query for network-connection: gprs matches, it would be shame to force it to switch to a lousy image. -- regards, Kornel Lesiński -Anselm
Re: [whatwg] add html-attribute for responsive images
2012/2/7 Anselm Hannemann ans...@novolo.de: Am 08.02.2012 um 01:54 schrieb Kornel Lesiński: On Tue, 07 Feb 2012 14:49:16 -, David Goss dvdg...@gmail.com wrote: I guess I've moved away from similarities with video, in that I've been thinking of the img as the default content, not the fallback content. Going with your angle for a simple example with two sizes: picture alt=alternative text src=default.jpg source href=large.jpg media=min-width:700px / img alt=alternative text src=default.jpg / /picture A new element may be an opportunity to get the alt right, i.e. in element's body, not flattened in an attribute. Is there a reason for this? I think this is more confusing than everything else. And, an alternative text shouldn't have markup. Alternative text should be all for accessibility. What you thinking about might be the title-attribute. But I'm totally against this approach to do this inside the element w/o attribute. And I think screenreader won't be happy with that, too? (not sure about that). No, definitely not. @alt is useful for accessibility, yes, but it's also useful even for sighted people if the image is temporarily unavailable. I have found this ability useful in several concrete instances in my webdev career. Having the ability to do structured fallback would be even better. Screenreaders only have a problem insofar as they don't currently have the ability to recognize such markup, because it doesn't exist yet. There's nothing theoretically difficult about it, though. ~TJ
Re: [whatwg] add html-attribute for responsive images
Am 08.02.2012 um 08:23 schrieb Tab Atkins Jr.: 2012/2/7 Anselm Hannemann ans...@novolo.de: Am 08.02.2012 um 01:54 schrieb Kornel Lesiński: On Tue, 07 Feb 2012 14:49:16 -, David Goss dvdg...@gmail.com wrote: I guess I've moved away from similarities with video, in that I've been thinking of the img as the default content, not the fallback content. Going with your angle for a simple example with two sizes: picture alt=alternative text src=default.jpg source href=large.jpg media=min-width:700px / img alt=alternative text src=default.jpg / /picture A new element may be an opportunity to get the alt right, i.e. in element's body, not flattened in an attribute. Is there a reason for this? I think this is more confusing than everything else. And, an alternative text shouldn't have markup. Alternative text should be all for accessibility. What you thinking about might be the title-attribute. But I'm totally against this approach to do this inside the element w/o attribute. And I think screenreader won't be happy with that, too? (not sure about that). No, definitely not. @alt is useful for accessibility, yes, but it's also useful even for sighted people if the image is temporarily unavailable. I have found this ability useful in several concrete instances in my webdev career. Having the ability to do structured fallback would be even better. Screenreaders only have a problem insofar as they don't currently have the ability to recognize such markup, because it doesn't exist yet. There's nothing theoretically difficult about it, though. Thanks for clarifying. Then it would be okay to use this style. I only have the problem with this unordered markup. In that case we don't have any wrapper for the alt-text and it would just follow as plain on the source-elements. We always should have wrappers in my mind, we have this for noscript etc, too. So why not adding altmy alternative text here/alt to the spec? picture alt=alternative text src=default.jpg img alt=alternative text src=default.jpg / source href=large.jpg media=min-width:700px / altalt text emhere/em/alt /picture But in that cases we're now sure we don't want the solution to serve different contents, right? I mean if we, we should use an attributed version as we then need different alt and title content, too. And from discussion before that was only two people saying we don't need that. I'd love to have *ability* (just for future use-cases which might come up and I already would have some for tablet-devices and smartphones) to add different media. e.g. we could offer a cropped image for smartphone users which has another context (maybe missing important parts of the img due to crop but it's better for smartphone usage and still has it's right to be there as an diff.image). Would love to hear what you all think about that? -Anselm
Re: [whatwg] add html-attribute for responsive images
Am 25.01.2012 16:39 schrieb Matthew Wilcox: It's also worth noting another use case for this being in mark-up and not just server-negotiated rescaling of a single image: Imagine a profile photo on an About page. At large sizes you want to use a full body shot, at smaller sizes you need to retain what's important but no longer clear at small scales: a recognisable face - so you substiture a head and shoulders shot. That's a strong use case where the semantic meaning of the content is the same but requires a different resource to be properly conveyed at differing scales. This use case shows some kind of consistency issue: The printed version of a page might match a different media query, and thus use a different image. If the images have different contents, this can result in a confusing user experience. In order to work around this, UAs might want to keep the first image loaded, when the content is used for a different type of media, such as print or PDF output. (That could also be the case for changes of window size.) I think Matthew has it about right with the about page example. I think as long as the user can recognise that it's the same image (albeit cropped/zoomed in some way to adapt to the media) then we're okay. I’m late to the conversation! It looks like a bunch of us have been thinking in parallel with some of the folks in this thread--we've reached many of the same conclusions you guys have, and ended up with pseudo-markup nearly identical to yours—albeit under the working name picture. Our brainstorming (be warned, some of it ain’t pretty) can be found here: https://etherpad.mozilla.org/responsive-assets I recently published a sum-up of our thinking at A List Apart ( http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ )—in short, using the video markup pattern as the inspiration, with the use of media attributes on the source elements to determine the rendered source, and the inclusion of an img--ideally a smaller image, to account for the lowest-common-denominator--as a fallback similar to the way Flash or an image might be used as a video fallback. I'd love to start this conversation up again, so we can talk through any potential issues!
Re: [whatwg] add html-attribute for responsive images Mathew Marquis
Mathew, thanks for raising that point. I think we need to decide whether markup-based solution is a workaround forced on us because there was no good solution or whether it is a solution we should pursue, if implemented properly. And this brings us to a very technical discussion about RESTfulness of either approaches (server-side negotiation vs. markup-based descriptors). -- Pros of server-side negotiation: If you look at an image as a unique resource, then representing it with a unique URL and adjusting diff crops or resolutions of the image for device-targeting based on HTTP headers is very much like using unique resource URL and altering output format based on accept headers, which is the RESTful and recommended approach. I can see an argument that diff crops of the same image are not the same resource, but esp. in the context of targeting diff. devices, I think that's not true. If XML and JSON versions of a document are the same resource, then device-specific versions of an image should be as well. Good food for thought, however. Thanks, Irakli
Re: [whatwg] add html-attribute for responsive images Mathew Marquis
Irakli, I think it is not about markup vs server-side-solution. Server-side is not a solution at all I think. But it's about wether it's markup based (which means we also could serve different content in images on different resolutions which would be a feature!) or file-based as responsive (progressively downloading) image-format in WebP or other formats. But even if WebP gets such a feature it takes time to implement this in format and in browsers which would be quite more complicated as we have the codec-problems again here. So I think we at least need a markup based solution. If we then will get a responsive file format some time it's great but we can't expect that now. --- For the element's name I think either image (seems to cause trouble in older browsers but not sure if we have to support them? Mean it should work well and standardized in future not now…) or picture would be fine. --- -Anselm Mathew, thanks for raising that point. I think we need to decide whether markup-based solution is a workaround forced on us because there was no good solution or whether it is a solution we should pursue, if implemented properly. And this brings us to a very technical discussion about RESTfulness of either approaches (server-side negotiation vs. markup-based descriptors). -- Pros of server-side negotiation: If you look at an image as a unique resource, then representing it with a unique URL and adjusting diff crops or resolutions of the image for device-targeting based on HTTP headers is very much like using unique resource URL and altering output format based on accept headers, which is the RESTful and recommended approach. I can see an argument that diff crops of the same image are not the same resource, but esp. in the context of targeting diff. devices, I think that's not true. If XML and JSON versions of a document are the same resource, then device-specific versions of an image should be as well. Good food for thought, however. Thanks, Irakli
Re: [whatwg] add html-attribute for responsive images Mathew Marquis
I think we need to decide whether markup-based solution is a workaround forced on us because there was no good solution or whether it is a solution we should pursue, if implemented properly. To your first point: I figure we do have solutions already, even if they’re not spectacular. A completely JS-based approach is perfectly viable, if a bit wasteful on larger screens; we have one in place on BostonGlobe.com right now. I wouldn't say this is a gut reaction from a handful of developers backed into a corner, by any means. Really, it follows the same logic that seems to have gone into the media aspect of video’s sources: if we can prevent wasteful requests in a way that predictably falls back for older browsers, why shouldn’t we? Where the source logic would only be limited by MQ it would allow us to, say, serve high-res images to higher DPI screens without incurring any cost to lower DPI screens, without requiring UA detection or server-side logic. On the other hand: if one were to want to automate the cropping process, the various sources could be generated by server-side logic and output to the page. And this brings us to a very technical discussion about RESTfulness of either approaches (server-side negotiation vs. markup-based descriptors). -- Pros of server-side negotiation: If you look at an image as a unique resource, then representing it with a unique URL and adjusting diff crops or resolutions of the image for device-targeting based on HTTP headers is very much like using unique resource URL and altering output format based on accept headers, which is the RESTful and recommended approach. I can see an argument that diff crops of the same image are not the same resource, but esp. in the context of targeting diff. devices, I think that's not true. If XML and JSON versions of a document are the same resource, then device-specific versions of an image should be as well. Good food for thought, however. Thanks, Irakli
Re: [whatwg] add html-attribute for responsive images
On Mon, 06 Feb 2012 21:23:37 -, Mathew Marquis m...@matmarquis.com wrote: I recently published a sum-up of our thinking at A List Apart ( http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ )—in short, using the video markup pattern as the inspiration, with the use of media attributes on the source elements to determine the rendered source, and the inclusion of an img--ideally a smaller image, to account for the lowest-common-denominator--as a fallback similar to the way Flash or an image might be used as a video fallback. Why not use a media attribute of object? That way you should get media type disambiguation for free. -- -,Bjartur
Re: [whatwg] add html-attribute for responsive images
Am 25.01.2012 16:39 schrieb Matthew Wilcox: It's also worth noting another use case for this being in mark-up and not just server-negotiated rescaling of a single image: Imagine a profile photo on an About page. At large sizes you want to use a full body shot, at smaller sizes you need to retain what's important but no longer clear at small scales: a recognisable face - so you substiture a head and shoulders shot. That's a strong use case where the semantic meaning of the content is the same but requires a different resource to be properly conveyed at differing scales. This use case shows some kind of consistency issue: The printed version of a page might match a different media query, and thus use a different image. If the images have different contents, this can result in a confusing user experience. In order to work around this, UAs might want to keep the first image loaded, when the content is used for a different type of media, such as print or PDF output. (That could also be the case for changes of window size.) There was some more discussion on this type of use case: Am 25.01.2012 14:42 schrieb David Goss: On Tue, 24 Jan 2012 23:26, Ian Hickson wrote: What's the use case for doing it for images inimg elements? Typically img elements are for content images, where you don't usually want to adapt anything. On Tue, 30 Aug 2011, Karl Dubost wrote: And as I explained elsewhere it is not a question of high/low-resolution only, but about interaction contexts. Different images for different surface sizes. Desktop: Show a full photo of Anne van Kesteren riding on a plane 1024*250 px Tablet: Show the photo a closer shot of the plane (cowboy frame) 400*150 px Mobile: Show a portrait of Anne with his leather pilot helmet 100x100 px I don't understand the use case. For something like a user profile icon surely it would be rather bad UI to use a different icon on different devices. I presume you don't mean a profile icon though, since 1024x250 is a bit excessive for an icon these days, and I'm not aware of any site that lets users pick different icons for different size contexts. The use case is that you want to serve the same image (same content) to all users, but you want to serve it in different resolutions depending on their context to avoid wasting bandwidth and killing performance (especially on mobile devices where performance is key - you don't want to download a 1000px-wide image when you're scaling it down to 320px wide to display it). Karl's example is on dangerous ground, IMO. The different sizes of the image could be slightly cropped/zoomed as appropriate, but should still clearly represent the same thing - in other words, the same alt text should correctly describe all of them.
Re: [whatwg] add html-attribute for responsive images
On 26 January 2012 09:21, Markus Ernst derer...@gmx.ch wrote: Am 25.01.2012 16:39 schrieb Matthew Wilcox: It's also worth noting another use case for this being in mark-up and not just server-negotiated rescaling of a single image: Imagine a profile photo on an About page. At large sizes you want to use a full body shot, at smaller sizes you need to retain what's important but no longer clear at small scales: a recognisable face - so you substiture a head and shoulders shot. That's a strong use case where the semantic meaning of the content is the same but requires a different resource to be properly conveyed at differing scales. This use case shows some kind of consistency issue: The printed version of a page might match a different media query, and thus use a different image. If the images have different contents, this can result in a confusing user experience. In order to work around this, UAs might want to keep the first image loaded, when the content is used for a different type of media, such as print or PDF output. (That could also be the case for changes of window size.) I think Matthew has it about right with the about page example. I think as long as the user can recognise that it's the same image (albeit cropped/zoomed in some way to adapt to the media) then we're okay.
Re: [whatwg] add html-attribute for responsive images
Please see responses inline:
On 24 January 2012 23:26, Ian Hickson i...@hixie.ch wrote:
On Wed, 24 Aug 2011, Anselm Hannemann - Novolo Designagentur wrote:
As we now have the possibility of creating fluid and responsive layouts
in several ways we have a problem with images.
There's currently no good feature to implement something like responsive
images which adapt to the different device-resolutions. We only can
implement one image with one resolution scaling-up and down.
You can do adaptive sites using media queries.
!-- HTML --
h1My Site/h1
// CSS
@media (min-width: 320px and max-width: 640px) {
h1::before { content: url(http://cdn.url.com/img/myimage_xs.jpg) }
}
@media (min-width: 640px and max-width: 1024px) {
h1::before { content: url(http://cdn.url.com/img/myimage_m.jpg) }
}
@media (min-width: 1024px) {
h1::before { content: url(http://cdn.url.com/img/myimage_xsl.jpg) }
}
This is of no use to content images - which are the real problem. CSS
supplied images are not an issue.
On Tue, 30 Aug 2011, Karl Dubost wrote:
It is easy to do right now with background images, but not at all for
images in img/ element.
What's the use case for doing it for images in img elements? Typically
img elements are for content images, where you don't usually want to
adapt anything.
Sorry, you couldn't be more wrong. Content images need to adapt because of
the performance problems with mobile. Huge effort has been expended in the
community to answer this problem - mobiles should not be delivered the same
sized images as desktop, even though the semantic value of the images are
the same. What we are talking here is device-appropriate re-scaled versions
of the same image. This saves bandwidth and allows phones with weak
hardware to perform acceptably. For more on the issue please read
http://adaptive-images.com,
http://24ways.org/2011/adaptive-images-for-responsive-designs,
http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/, or
http://filamentgroup.com/lab/responsive_images_experimenting_with_context_aware_image_sizing/to
name but a few recent in-depth articles on exactly this requirement.
Or to look at the extreme hoops we have to jump through for a client-side
solution read
http://24ways.org/2011/adaptive-images-for-responsive-designs-again - it is
not pretty.
On Tue, 30 Aug 2011, Karl Dubost wrote:
And as I explained elsewhere it is not a question of high/low-resolution
only, but about interaction contexts. Different images for different
surface sizes.
Desktop: Show a full photo of Anne van Kesteren riding on a plane
1024*250 px
Tablet: Show the photo a closer shot of the plane (cowboy frame)
400*150 px
Mobile: Show a portrait of Anne with his leather pilot helmet 100x100 px
I don't understand the use case. For something like a user profile icon
surely it would be rather bad UI to use a different icon on different
devices. I presume you don't mean a profile icon though, since 1024x250 is
a bit excessive for an icon these days, and I'm not aware of any site that
lets users pick different icons for different size contexts.
With retina displays, don't be surprised to see icons around this size very
soon.
On Wed, 31 Aug 2011, Bjartur Thorlacius wrote:
Bottom (top?) line: User agents should negotiate an appropriate
message-body size using HTTP. Sending an accept-size (or some such)
could solve both the problem of high resolution photography and lengthy
documents. The amount of split articles (Click here to go to the next
page / page 4) and long search results show clear demand.
I don't think that really works. You wouldn't want to get different
results if I started with a small window vs starting with a big window and
narrowing it. It should adapt in realtime.
By re-requesting image resources after re-scale? That's not performant. But
I do agree that it'd be nicer to getreal-time resource re-requests, if only
the penalty didn't involve page layout jumps. The fact os, it's rare anyone
resizes the browser. The adaptive image agenda is mostly about supporting
massively differing viewport sizes and device configurations. Dynamic
rescaling is a side-agenda.
On Tue, 6 Sep 2011, Ashley Sheridan wrote:
Yes, but the point is, the alternative images you may want to display
for visitors on a smaller screen/resolution could be completely
different from the original image (cropped shot not showing all the
detail, etc).
Note that resolution and number of pixels on the screen are orthogonal
issues. Also, note that the number of pixels on the screen is irrelevant,
it's the number of pixels on the viewport that matters.
Yes and no. It depends on how the image request happens. For example, AI
(linked above) cares only about the number of pixels on the screen. Why?
Because given HTML at the moment you can't re-request an image when you
grow the window - meaning if you start
Re: [whatwg] add html-attribute for responsive images
On Tue, 24 Jan 2012 23:26, Ian Hickson wrote: What's the use case for doing it for images in img elements? Typically img elements are for content images, where you don't usually want to adapt anything. On Tue, 30 Aug 2011, Karl Dubost wrote: And as I explained elsewhere it is not a question of high/low-resolution only, but about interaction contexts. Different images for different surface sizes. Desktop: Show a full photo of Anne van Kesteren riding on a plane 1024*250 px Tablet: Show the photo a closer shot of the plane (cowboy frame) 400*150 px Mobile: Show a portrait of Anne with his leather pilot helmet 100x100 px I don't understand the use case. For something like a user profile icon surely it would be rather bad UI to use a different icon on different devices. I presume you don't mean a profile icon though, since 1024x250 is a bit excessive for an icon these days, and I'm not aware of any site that lets users pick different icons for different size contexts. The use case is that you want to serve the same image (same content) to all users, but you want to serve it in different resolutions depending on their context to avoid wasting bandwidth and killing performance (especially on mobile devices where performance is key - you don't want to download a 1000px-wide image when you're scaling it down to 320px wide to display it). Karl's example is on dangerous ground, IMO. The different sizes of the image could be slightly cropped/zoomed as appropriate, but should still clearly represent the same thing - in other words, the same alt text should correctly describe all of them. On Wed, 31 Aug 2011, Bjartur Thorlacius wrote: Bottom (top?) line: User agents should negotiate an appropriate message-body size using HTTP. Sending an accept-size (or some such) could solve both the problem of high resolution photography and lengthy documents. The amount of split articles (Click here to go to the next page / page 4) and long search results show clear demand. I don't think that really works. You wouldn't want to get different results if I started with a small window vs starting with a big window and narrowing it. It should adapt in realtime. I agree: this needs to be done in markup, not on the server with headers. Not that users resize their browsers all that much (except orientation changes on phones and tablets). But, yeah. Note that resolution and number of pixels on the screen are orthogonal issues. Also, note that the number of pixels on the screen is irrelevant, it's the number of pixels on the viewport that matters. My phone has a far higher resolution than my TV, but has the same number of pixels. My phone also has a higher resolution than my desktop, but windows on my desktop typically have far more pixels. You're right - all pixels are not equal. The solution I'm going to propose involves media queries, so things like device-pixel-ratio can be used to address that issue. I'm proposing this (adapted from Bruce Lawson's picture idea, and similar to how the video element works): adaptiveimg img src=sweater-small.jpg alt=Blue v-neck sweater in soft wool source src=sweater-medium.jpg media=(min-width: 300px) and (max-width: 450px) source src=sweater-large.jpg media=(min-width: 451px) and (max-width: 600px) source src=sweater-huge.jpg media=(min-width: 601px) /adaptiveimg Yep, another new element: adaptiveimg. It doesn't have any attributes of its own (except the standard ones). It must contain one img element, which the author will furnish with an alt attribute and whatever else as normal. It then contains one or more source elements, each with a media attribute containing a valid media query. The user agent should cycle through each source element in order, updating the src of the img accordingly if the media query is matched. If there are no source elements, or none of the media queries are matched, the original src on the img is used. Only after this logic has completed should the HTTP request for the image file take place (so there are no wasted downloads). The media queries I've used in the example are very simple, using just min-width and max-width, but in reality authors would often include other things such as device-pixel-ratio and color/monochrome. Non-supporting UAs would simply ignore the new elements and render the img as normal, but the structure would allow authors to implement a JavaScript polyfill if desired. To be clear, all the sources should point to different sizes of the same image — otherwise the content is being changed, which isn't what we're looking to do here. In other words, the same alt attribute should correctly describe all the sources. I'm sure there's a lot I haven't thought of, but hopefully this is a good start. Thoughts?
Re: [whatwg] add html-attribute for responsive images
Ugh, my Gmail keeps sending mail from the wrong address, let me try again: ... In fact, please just read the blog post Bruce Lawson (Opera Software) made summarising the last few months of effort on this, and his proposal for a mark-up level solution (which I'm in broad support of, though there are a lot of knotty issues with any potential solution - as can be seen by the volume of blog-posts, comments, and articles on the topic): http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/ ... I should add that relying on mobile-networks compressing images is not a good enough solution either. Firstly, they don't always. Secondly, this is about performance and device capability not mobile network behaviour. Personally I think media should respond to detected connection speed and/or device capabilities. That involves equipping HTML with the ability to detect those things which is a big ask. But, I feel, very worth while in terms of future-proofing. I'm all for headers being sent with all HTTP requests to inform the server of device details - allowing the server to choose appropriately. But, we also need a mark-up level solution. They're not the same problem though superficially they appear similar. On 25 January 2012 13:42, David Goss dvdg...@gmail.com wrote: On Tue, 24 Jan 2012 23:26, Ian Hickson wrote: What's the use case for doing it for images in img elements? Typically img elements are for content images, where you don't usually want to adapt anything. On Tue, 30 Aug 2011, Karl Dubost wrote: And as I explained elsewhere it is not a question of high/low-resolution only, but about interaction contexts. Different images for different surface sizes. Desktop: Show a full photo of Anne van Kesteren riding on a plane 1024*250 px Tablet: Show the photo a closer shot of the plane (cowboy frame) 400*150 px Mobile: Show a portrait of Anne with his leather pilot helmet 100x100 px I don't understand the use case. For something like a user profile icon surely it would be rather bad UI to use a different icon on different devices. I presume you don't mean a profile icon though, since 1024x250 is a bit excessive for an icon these days, and I'm not aware of any site that lets users pick different icons for different size contexts. The use case is that you want to serve the same image (same content) to all users, but you want to serve it in different resolutions depending on their context to avoid wasting bandwidth and killing performance (especially on mobile devices where performance is key - you don't want to download a 1000px-wide image when you're scaling it down to 320px wide to display it). Karl's example is on dangerous ground, IMO. The different sizes of the image could be slightly cropped/zoomed as appropriate, but should still clearly represent the same thing - in other words, the same alt text should correctly describe all of them. On Wed, 31 Aug 2011, Bjartur Thorlacius wrote: Bottom (top?) line: User agents should negotiate an appropriate message-body size using HTTP. Sending an accept-size (or some such) could solve both the problem of high resolution photography and lengthy documents. The amount of split articles (Click here to go to the next page / page 4) and long search results show clear demand. I don't think that really works. You wouldn't want to get different results if I started with a small window vs starting with a big window and narrowing it. It should adapt in realtime. I agree: this needs to be done in markup, not on the server with headers. Not that users resize their browsers all that much (except orientation changes on phones and tablets). But, yeah. Note that resolution and number of pixels on the screen are orthogonal issues. Also, note that the number of pixels on the screen is irrelevant, it's the number of pixels on the viewport that matters. My phone has a far higher resolution than my TV, but has the same number of pixels. My phone also has a higher resolution than my desktop, but windows on my desktop typically have far more pixels. You're right - all pixels are not equal. The solution I'm going to propose involves media queries, so things like device-pixel-ratio can be used to address that issue. I'm proposing this (adapted from Bruce Lawson's picture idea, and similar to how the video element works): adaptiveimg img src=sweater-small.jpg alt=Blue v-neck sweater in soft wool source src=sweater-medium.jpg media=(min-width: 300px) and (max-width: 450px) source src=sweater-large.jpg media=(min-width: 451px) and (max-width: 600px) source src=sweater-huge.jpg media=(min-width: 601px) /adaptiveimg Yep, another new element: adaptiveimg. It doesn't have any attributes of its own (except the standard ones). It must contain one img element, which the author will furnish with an alt attribute and whatever else as
Re: [whatwg] add html-attribute for responsive images
Am 25.01.2012 15:07 schrieb Matthew Wilcox:
In fact, please just read the blog post Bruce Lawson (Opera Software)
made summarising the last few months of effort on this, and his proposal
for a mark-up level solution (which I'm in broad support of, though there
are a lot of knotty issues with any potential solution - as can be seen by
the volume of blog-posts, comments, and articles on the topic):
http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/
I would like to propose a use case different from the ones in this
blog-post: Scaled images.
The more physical screen densities improve, the less image pixels
actually correspond to device pixels, and thus scaling images will be
less a problem. E.g., designers might want to define an image size in em
units rather than in px, so it keeps its relation to the text size.
This use case requires a negotiation based on the dimensions of the
image element rather than the dimensions of the media. It would be nice
if a solution to the responsive images problem would address this use
case, too. AFAICS this would require a more general syntax for the
conditions.
On 25 January 2012 13:42, David Gossdvdg...@gmail.com wrote:
I'm proposing this (adapted from Bruce Lawson'spicture idea, and similar
to how thevideo element works):
adaptiveimg
img src=sweater-small.jpg alt=Blue v-neck sweater in soft wool
source src=sweater-medium.jpg media=(min-width: 300px) and
(max-width: 450px)
source src=sweater-large.jpg media=(min-width: 451px) and
(max-width: 600px)
source src=sweater-huge.jpg media=(min-width: 601px)
/adaptiveimg
If the introduction of a new element is an option, it could also be the
other way around, as image maps work:
img src=default.gif srclist=mySrcList id=myImg alt=My responsive
image style=width:5em;height:auto
srclist id=mySrcList
source src=low.gif cond=[condition]
source src=high.gif cond=[condition]
/srclist
To address my above use case, I replaced the media attribute with a more
general cond attibute, which can take a condition with a selector and a
rule. The selector can be the keyword media or a CSS selector, and the
rule either a min-width and/or max-width declaration, or some statement
about network speed or whatever, such as:
source src=small.gif cond=#myImg{max-width:49px}
source src=medium.gif cond=#myImg{min-width:50px;max-width:99px}
or:
source src=small.gif cond=#wrapper{max-width:320px}
or:
source src=small.gif cond=media{max-width:320px}
or:
source src=slow.gif cond=media{network-speed:[some slow value]}
Re: [whatwg] add html-attribute for responsive images
It's also worth noting another use case for this being in mark-up and not
just server-negotiated rescaling of a single image:
Imagine a profile photo on an About page. At large sizes you want to use a
full body shot, at smaller sizes you need to retain what's important but no
longer clear at small scales: a recognisable face - so you substiture a
head and shoulders shot.
That's a strong use case where the semantic meaning of the content is the
same but requires a different resource to be properly conveyed at differing
scales.
On 25 January 2012 15:27, Markus Ernst derer...@gmx.ch wrote:
Am 25.01.2012 15:07 schrieb Matthew Wilcox:
In fact, please just read the blog post Bruce Lawson (Opera Software)
made summarising the last few months of effort on this, and his proposal
for a mark-up level solution (which I'm in broad support of, though there
are a lot of knotty issues with any potential solution - as can be seen by
the volume of blog-posts, comments, and articles on the topic):
http://www.brucelawson.co.uk/**2011/notes-on-adaptive-images-**yet-again/http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/
I would like to propose a use case different from the ones in this
blog-post: Scaled images.
The more physical screen densities improve, the less image pixels actually
correspond to device pixels, and thus scaling images will be less a
problem. E.g., designers might want to define an image size in em units
rather than in px, so it keeps its relation to the text size.
This use case requires a negotiation based on the dimensions of the image
element rather than the dimensions of the media. It would be nice if a
solution to the responsive images problem would address this use case, too.
AFAICS this would require a more general syntax for the conditions.
On 25 January 2012 13:42, David Gossdvdg...@gmail.com wrote:
I'm proposing this (adapted from Bruce Lawson'spicture idea, and
similar
to how thevideo element works):
adaptiveimg
img src=sweater-small.jpg alt=Blue v-neck sweater in soft wool
source src=sweater-medium.jpg media=(min-width: 300px) and
(max-width: 450px)
source src=sweater-large.jpg media=(min-width: 451px) and
(max-width: 600px)
source src=sweater-huge.jpg media=(min-width: 601px)
/adaptiveimg
If the introduction of a new element is an option, it could also be the
other way around, as image maps work:
img src=default.gif srclist=mySrcList id=myImg alt=My responsive
image style=width:5em;height:auto
srclist id=mySrcList
source src=low.gif cond=[condition]
source src=high.gif cond=[condition]
/srclist
To address my above use case, I replaced the media attribute with a more
general cond attibute, which can take a condition with a selector and a
rule. The selector can be the keyword media or a CSS selector, and the
rule either a min-width and/or max-width declaration, or some statement
about network speed or whatever, such as:
source src=small.gif cond=#myImg{max-width:49px}
source src=medium.gif cond=#myImg{min-width:50px;**max-width:99px}
or:
source src=small.gif cond=#wrapper{max-width:**320px}
or:
source src=small.gif cond=media{max-width:320px}
or:
source src=slow.gif cond=media{network-speed:[**some slow value]}
Re: [whatwg] add html-attribute for responsive images
On Wed, 24 Aug 2011, Anselm Hannemann - Novolo Designagentur wrote:
As we now have the possibility of creating fluid and responsive layouts
in several ways we have a problem with images.
There's currently no good feature to implement something like responsive
images which adapt to the different device-resolutions. We only can
implement one image with one resolution scaling-up and down.
You can do adaptive sites using media queries.
!-- HTML --
h1My Site/h1
// CSS
@media (min-width: 320px and max-width: 640px) {
h1::before { content: url(http://cdn.url.com/img/myimage_xs.jpg) }
}
@media (min-width: 640px and max-width: 1024px) {
h1::before { content: url(http://cdn.url.com/img/myimage_m.jpg) }
}
@media (min-width: 1024px) {
h1::before { content: url(http://cdn.url.com/img/myimage_xsl.jpg) }
}
On Tue, 30 Aug 2011, Karl Dubost wrote:
It is easy to do right now with background images, but not at all for
images in img/ element.
What's the use case for doing it for images in img elements? Typically
img elements are for content images, where you don't usually want to
adapt anything.
On Tue, 30 Aug 2011, Karl Dubost wrote:
And as I explained elsewhere it is not a question of high/low-resolution
only, but about interaction contexts. Different images for different
surface sizes.
Desktop: Show a full photo of Anne van Kesteren riding on a plane 1024*250 px
Tablet: Show the photo a closer shot of the plane (cowboy frame) 400*150 px
Mobile: Show a portrait of Anne with his leather pilot helmet 100x100 px
I don't understand the use case. For something like a user profile icon
surely it would be rather bad UI to use a different icon on different
devices. I presume you don't mean a profile icon though, since 1024x250 is
a bit excessive for an icon these days, and I'm not aware of any site that
lets users pick different icons for different size contexts.
On Wed, 31 Aug 2011, Bjartur Thorlacius wrote:
Bottom (top?) line: User agents should negotiate an appropriate
message-body size using HTTP. Sending an accept-size (or some such)
could solve both the problem of high resolution photography and lengthy
documents. The amount of split articles (Click here to go to the next
page / page 4) and long search results show clear demand.
I don't think that really works. You wouldn't want to get different
results if I started with a small window vs starting with a big window and
narrowing it. It should adapt in realtime.
On Tue, 6 Sep 2011, Ashley Sheridan wrote:
Yes, but the point is, the alternative images you may want to display
for visitors on a smaller screen/resolution could be completely
different from the original image (cropped shot not showing all the
detail, etc).
Note that resolution and number of pixels on the screen are orthogonal
issues. Also, note that the number of pixels on the screen is irrelevant,
it's the number of pixels on the viewport that matters.
My phone has a far higher resolution than my TV, but has the same number
of pixels. My phone also has a higher resolution than my desktop, but
windows on my desktop typically have far more pixels.
Ergo, you lose the accessibility because you now can't textually
represent it in the alt tag.
I don't really understand the use case here. Could you elaborate, ideally
with an example showing the alternative text you had in mind?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] add html-attribute for responsive images
Am 06.09.2011 um 12:49 schrieb Karl Dubost: Ashley, Anselm, Le 6 sept. 2011 à 08:36, Ashley Sheridan a écrit : Yes, but the point is, the alternative images you may want to display for visitors on a smaller screen/resolution could be completely different from the original image (cropped shot not showing all the detail, etc). Yes already happening with background images with not text alt at all. So let's say it is progress. Le 6 sept. 2011 à 09:07, Anselm Hannemann - Novolo Designagentur a écrit : by the way, how should we work with your solution, Karl, and a CMS or CSS files from a static domain? Is no one building a dynamic site? could you clarify? How exactly can I create a dynamic CMS website today with responsive images? I could manage my CSS file with my CMS which most of them don't support. I could minify the CSS on the fly but in reality and from performance view it's recommended to serve a static css file from a cookieless domain (which is another than where my CMS is located). If I would use a CDN additionally how should I change images on the fly? And, a client wants to change an image in a WSIWYG editor not in a raw css file. We won't either as he can destroy the entire stylesheet. I hope you now understand better what I mean. -Anselm
Re: [whatwg] add html-attribute for responsive images
Am 06.09.2011 um 08:36 schrieb Ashley Sheridan: On Tue, 2011-09-06 at 07:15 +0200, Karl Dubost wrote: Le 5 sept. 2011 à 15:07, Anselm Hannemann - Novolo Designagentur a écrit : Why should we use inline-styles once again? Why should we load content images with CSS? What about accessibility? Where to add alt-attribute / title / ARIA etc.? Not exactly what is happening. There is a URI with an image without a javascript and/or CSS activated. The CSS changes the image dynamically depending on the user experience context controlled by mediaqueries. Yes, but the point is, the alternative images you may want to display for visitors on a smaller screen/resolution could be completely different from the original image (cropped shot not showing all the detail, etc). Ergo, you lose the accessibility because you now can't textually represent it in the alt tag. Right you hit the nail on the head. And, by the way, how should we work with your solution, Karl, and a CMS or CSS files from a static domain? Is no one building a dynamic site?
Re: [whatwg] add html-attribute for responsive images
Ashley, Anselm, Le 6 sept. 2011 à 08:36, Ashley Sheridan a écrit : Yes, but the point is, the alternative images you may want to display for visitors on a smaller screen/resolution could be completely different from the original image (cropped shot not showing all the detail, etc). Yes already happening with background images with not text alt at all. So let's say it is progress. Le 6 sept. 2011 à 09:07, Anselm Hannemann - Novolo Designagentur a écrit : by the way, how should we work with your solution, Karl, and a CMS or CSS files from a static domain? Is no one building a dynamic site? could you clarify? -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: [whatwg] add html-attribute for responsive images
Le 5 sept. 2011 à 15:07, Anselm Hannemann - Novolo Designagentur a écrit : Why should we use inline-styles once again? Why should we load content images with CSS? What about accessibility? Where to add alt-attribute / title / ARIA etc.? Not exactly what is happening. There is a URI with an image without a javascript and/or CSS activated. The CSS changes the image dynamically depending on the user experience context controlled by mediaqueries. -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: [whatwg] add html-attribute for responsive images
Am 31.08.2011 um 23:32 schrieb Karl Dubost:
Anselm,
(setting reply-to on www-style)
Seen this today, to remind people that it is not just
something up in the air. People need it.
http://www.webmonkey.com/2011/08/speed-up-your-responsive-designs-with-adaptive-images/
I wonder if it could be handled by CSS in fact.
I guess Anselm, you could ask there.
On the www-style mailing-list, Charles proposed [1]
content: url(img.jpg) replaced;
I'm not sure I fully understand the proposal
but we can imagine something that could fit nicely
with the CSS Generated Content Module Level 3 [2]
img class=responsive src=http://example.org/foo; alt=wiizz/
and then the CSS
@media screen and (min-width:550px) and (max-width:960px) {
img.responsive {
url(http://example.org/foobis) replaced;}
}
@media screen and (min-width:240px) and (max-width:549px) {
img.responsive {
url(http://example.org/footer) replaced;}
}
[1]: http://www.w3.org/mid/4e5d4a46.7000...@jumis.com
[2]: http://dev.w3.org/csswg/css3-content/#replacedContent
--
Karl Dubost - http://dev.opera.com/
Developer Relations Tools, Opera Software
How would you do this with a CMS? How to do with dynamic content when serving
the CSS from a cookieless, static domain as it's best practice for performance.
From my point of view it can't work with just CSS. When you look to my proposed
gist-solution you can see in history that I've already dealt with several other
approaches.
Last is the only one that could really work that I know right now.
Re: [whatwg] add html-attribute for responsive images
Am 01.09.2011 um 01:46 schrieb Charles Pritchard: On 8/31/2011 2:32 PM, Karl Dubost wrote: Oh, that's not my proposal, that syntax was brought up by Tab Atkins. It's already available. I was looking into how to handle img [no source] style=background: url(..) / It may work with the following, now, or at some point in the future: img style=content: replaced; background-color: ...; / I'd proposed visibility: content-hidden; to be used with background and border. Why should we use inline-styles once again? Why should we load content images with CSS? What about accessibility? Where to add alt-attribute / title / ARIA etc.? -Anselm
Re: [whatwg] add html-attribute for responsive images
On 9/1/2011 1:30 AM, Anselm Hannemann - Novolo Designagentur wrote: Am 01.09.2011 um 01:46 schrieb Charles Pritchard: On 8/31/2011 2:32 PM, Karl Dubost wrote: Oh, that's not my proposal, that syntax was brought up by Tab Atkins. It's already available. I was looking into how to handle img [no source] style=background: url(..) / It may work with the following, now, or at some point in the future: img style=content: replaced; background-color: ...; / I'd proposed visibility: content-hidden; to be used with background and border. Why should we use inline-styles once again? Why should we load content images with CSS? What about accessibility? Where to add alt-attribute / title / ARIA etc.? They're CSS styles, I'm using inline for demonstrative purposes. I'd load images because the CSS image spec is more powerful than the HTML image spec, offering things like -webkit-canvas (soon -element), various background sizing and fitting routines. Accessibility is maintained exactly as it was, you'd put the alt attribute in the image tag.
Re: [whatwg] add html-attribute for responsive images
Anselm,
(setting reply-to on www-style)
Seen this today, to remind people that it is not just
something up in the air. People need it.
http://www.webmonkey.com/2011/08/speed-up-your-responsive-designs-with-adaptive-images/
I wonder if it could be handled by CSS in fact.
I guess Anselm, you could ask there.
On the www-style mailing-list, Charles proposed [1]
content: url(img.jpg) replaced;
I'm not sure I fully understand the proposal
but we can imagine something that could fit nicely
with the CSS Generated Content Module Level 3 [2]
img class=responsive src=http://example.org/foo; alt=wiizz/
and then the CSS
@media screen and (min-width:550px) and (max-width:960px) {
img.responsive {
url(http://example.org/foobis) replaced;}
}
@media screen and (min-width:240px) and (max-width:549px) {
img.responsive {
url(http://example.org/footer) replaced;}
}
[1]: http://www.w3.org/mid/4e5d4a46.7000...@jumis.com
[2]: http://dev.w3.org/csswg/css3-content/#replacedContent
--
Karl Dubost - http://dev.opera.com/
Developer Relations Tools, Opera Software
Re: [whatwg] add html-attribute for responsive images
Bottom (top?) line: User agents should negotiate an appropriate
message-body size using HTTP. Sending an accept-size (or some such)
could solve both the problem of high resolution photography and lengthy
documents. The amount of split articles (Click here to go to the next
page / page 4) and long search results show clear demand.
Þann mið 31.ágú 2011 21:32, skrifaði Karl Dubost:
Anselm,
(setting reply-to on www-style)
Seen this today, to remind people that it is not just
something up in the air. People need it.
http://www.webmonkey.com/2011/08/speed-up-your-responsive-designs-with-adaptive-images/
I wonder if it could be handled by CSS in fact.
Different technologies seem appropriate depending on the relation
between the document and the images.
Use Case A
Multiple representations of a resource may exist, where all can be
deduced from the original (e.g. by downsampling). Doing the deducing on
the server is an optimization to save bandwidth.
Proposed Solutions
1) Nest objects
2) Negotiate content serverside as per HTTP
3) Negotiate content clientside as per HTTP
Use Case B
An article might link to (directly or, theoretically, via a
text/uri-list) to a number of non-critical asides (i.e. images to rest
your eyes on, background music, etc), that may be omitted, but are in no
way the same resource.
Proposed Solutions
1) Use links or as with an appropriate relation specified
2) Use your favorite linking element (be it a, area, object, img, audio,
video, link, a future media element not yet specified, or an old one not
yet deprecated) in an aside.
3) Add the rel attribute to object, and use instead of a in 1. See A.1
Expected Rendering
User agents are to render zero or more of the tolinked resources,
omitting none, some or all of the resources completely from the output
viewport, or rendered only on demand.
I guess Anselm, you could ask there.
On the www-style mailing-list, Charles proposed [1]
content: url(img.jpg) replaced;
I'm not sure I fully understand the proposal
but we can imagine something that could fit nicely
with the CSS Generated Content Module Level 3 [2]
img class=responsive src=http://example.org/foo; alt=wiizz/
and then the CSS
@media screen and (min-width:550px) and (max-width:960px) {
img.responsive {
url(http://example.org/foobis) replaced;}
}
@media screen and (min-width:240px) and (max-width:549px) {
img.responsive {
url(http://example.org/footer) replaced;}
}
And allocate every image a class, and every sample a rule in a style
sheet? Maybe, if the images are decorative, but I think you can come up
with a more clever solution using media fragments (either standardized,
or implemented per site by binding media queries to URI templates).
Re: [whatwg] add html-attribute for responsive images
On 8/31/2011 2:32 PM, Karl Dubost wrote:
Anselm,
(setting reply-to on www-style)
Seen this today, to remind people that it is not just
something up in the air. People need it.
http://www.webmonkey.com/2011/08/speed-up-your-responsive-designs-with-adaptive-images/
I wonder if it could be handled by CSS in fact.
I guess Anselm, you could ask there.
On the www-style mailing-list, Charles proposed [1]
content: url(img.jpg) replaced;
Oh, that's not my proposal, that syntax was brought up by Tab Atkins.
It's already available. I was looking into how to handle img [no
source] style=background: url(..) /
It may work with the following, now, or at some point in the future:
img style=content: replaced; background-color: ...; /
I'd proposed visibility: content-hidden; to be used with background and
border.
I'm not sure I fully understand the proposal
but we can imagine something that could fit nicely
with the CSS Generated Content Module Level 3 [2]
img class=responsive src=http://example.org/foo; alt=wiizz/
and then the CSS
@media screen and (min-width:550px) and (max-width:960px) {
img.responsive {
url(http://example.org/foobis) replaced;}
}
@media screen and (min-width:240px) and (max-width:549px) {
img.responsive {
url(http://example.org/footer) replaced;}
}
[1]: http://www.w3.org/mid/4e5d4a46.7000...@jumis.com
[2]: http://dev.w3.org/csswg/css3-content/#replacedContent
Keep in mind that min-device-pixel-ratio is also useful to monitor.
Set image dimensions in the css style to prevent reflowing.
Re: [whatwg] add html-attribute for responsive images
Anne, Le 30 août 2011 à 10:21, Anne van Kesteren a écrit : It's too much complexity for a niche problem. It is not a niche problem. * It is in fact an issue for being able to make the website responsive on Mobile devices in low banwidth. * It has also the impact that you want to send different type of images for different types of screen resolutions a full fledged logo or a logo icon depending on the size of the screen. It is easy to do right now with background images, but not at all for images in img/ element. There was a thread about this recently in May 2011. http://lists.w3.org/Archives/Public/public-html/2011May/thread.html#msg386 If you want example of Web sites doing responsive design http://mediaqueri.es/ -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: [whatwg] add html-attribute for responsive images
On Tue, 30 Aug 2011 16:31:59 +0200, Karl Dubost ka...@opera.com wrote: * It is in fact an issue for being able to make the website responsive on Mobile devices in low banwidth. The mobile devices are the ones with the high-resolution displays. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] add html-attribute for responsive images
On 2011-08-30 16:51, Anne van Kesteren wrote: On Tue, 30 Aug 2011 16:31:59 +0200, Karl Dubost ka...@opera.com wrote: * It is in fact an issue for being able to make the website responsive on Mobile devices in low banwidth. The mobile devices are the ones with the high-resolution displays. Speak for your own device :-)
Re: [whatwg] add html-attribute for responsive images
Le 30 août 2011 à 10:51, Anne van Kesteren a écrit : On Tue, 30 Aug 2011 16:31:59 +0200, Karl Dubost ka...@opera.com wrote: * It is in fact an issue for being able to make the website responsive on Mobile devices in low banwidth. The mobile devices are the ones with the high-resolution displays. And as I explained elsewhere it is not a question of high/low-resolution only, but about interaction contexts. Different images for different surface sizes. Desktop: Show a full photo of Anne van Kesteren riding on a plane 1024*250 px Tablet: Show the photo a closer shot of the plane (cowboy frame) 400*150 px Mobile: Show a portrait of Anne with his leather pilot helmet 100x100 px -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: [whatwg] add html-attribute for responsive images
On Tue, 30 Aug 2011 17:18:38 +0200, Karl Dubost ka...@opera.com wrote: Le 30 août 2011 à 10:51, Anne van Kesteren a écrit : On Tue, 30 Aug 2011 16:31:59 +0200, Karl Dubost ka...@opera.com wrote: * It is in fact an issue for being able to make the website responsive on Mobile devices in low banwidth. The mobile devices are the ones with the high-resolution displays. And as I explained elsewhere it is not a question of high/low-resolution only, but about interaction contexts. Different images for different surface sizes. Desktop: Show a full photo of Anne van Kesteren riding on a plane 1024*250 px Tablet: Show the photo a closer shot of the plane (cowboy frame) 400*150 px Mobile: Show a portrait of Anne with his leather pilot helmet 100x100 px That seems like different content. We do not really have a good solution for client-side content adaptation. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] add html-attribute for responsive images
On 30.8.2011 17:23, Anne van Kesteren wrote: On Tue, 30 Aug 2011 17:18:38 +0200, Karl Dubost ka...@opera.com wrote: Le 30 août 2011 à 10:51, Anne van Kesteren a écrit : On Tue, 30 Aug 2011 16:31:59 +0200, Karl Dubost ka...@opera.com wrote: * It is in fact an issue for being able to make the website responsive on Mobile devices in low banwidth. The mobile devices are the ones with the high-resolution displays. And as I explained elsewhere it is not a question of high/low-resolution only, but about interaction contexts. Different images for different surface sizes. Desktop: Show a full photo of Anne van Kesteren riding on a plane 1024*250 px Tablet: Show the photo a closer shot of the plane (cowboy frame) 400*150 px Mobile: Show a portrait of Anne with his leather pilot helmet 100x100 px That seems like different content. We do not really have a good solution for client-side content adaptation. But we do using CSS height, width and background-image based on media query for some div container... this could solve this problem from visual point of view... but passing semantic (not decorative) image management to CSS is not correct solution... Brona
[whatwg] add html-attribute for responsive images
Hi all, Paul Irish said I should mention my problems here. So I will: As we now have the possibility of creating fluid and responsive layouts in several ways we have a problem with images. There's currently no good feature to implement something like responsive images which adapt to the different device-resolutions. We only can implement one image with one resolution scaling-up and down. Of course the best solution would be to have a file format supporting this feature by offering diff. quality like .sid format does. But it's very unlikely to have such a feature in the next few years. So I thought of a simple html-attribute to work with media-queries and something like media-size-sources to provide different images fitting to the device-resolution. New browsers can read the new attributes but even old browsers degrade gracefully with the basic src attrobute. I shared the code in a gist here: https://gist.github.com/1158855 and will write it down here, too: !-- backwards compatible solution -- !-- the browser should read media-query and then download the right file for the actual screen size -- img src=http://cdn.url.com/img/myimage_xs.jpg; media-xs=(min-device-width:320px and max-device-width:640px) media-src-xs=http://cdn.url.com/img/myimage_xs.jpg; media-m=(min-device-width:640px and max-device-width:1024px) media-src-m=http://cdn.url.com/img/myimage_m.jpg; media-xl=(min-device-width:1024px) media-src-xl=http://cdn.url.com/img/myimage_xsl.jpg; / Tried several other ways, too, (you can see in versions) but this seems to be the best. What do you think about providing a way to use responsive media through media-queries? For now there are only some JS-Cookie solutions which are not a good approach and are very unflexible. kindest regards, -Anselm
