Part of the <img> vs <picture> discussion, has been to define what features are actually required of this element. Primarily this has come down to:
a) responsive handling of bandwidth vs image-quality (aka bandwidth vs file-size) b) pixel density of display devices c) art direction [ Did I miss any? ] Breaking them down: a) bandwidth is completely out of control of the website designer... (eg: 3G bandwidth varies x10 with time) so there is next to no reason for markup (HTML or CSS) to be related to bandwidth. If the designer chose to use JPEG2000, SVG, HDF or some other tileable/scalable format, then changes the scope somewhat, as the browser could implement "range requests" to the webserver to indicate which block of data would suit its currently available bandwidth. b) Pixel density depends completely on the target device... again outside of the designers control (unless you want to design for every version of every device in existence). And again the best a designer can do is offer multiple images. In which case, srcset seems like a nice way to go, as it leverage's an existing element thus allowing backwards compatibility. c) The art-direction aspect can be solved using variations of "clip(...)" combined with range-requests. An extra mention... the "media: max-width" variations are really not all that useful (unless you are targeting an exact screen size + density)... my eyes work well enough so that I can read small text, so would happily like to use tablet-width layouts on a small screen. The idea of "context" would seem appropriate... just need to remember that some of that context is not in the hands of the designer. Just my $0.02... cheers, Mathew Robertson On 14 September 2012 17:03, Dominic Hey <dominic....@gmail.com> wrote: > To paraphrase your own words.. if "an <img src=...> is descriptive of the > target image" then srcset would be descriptive of the *set* of target > images, no styling information there. Where I would be more inclined to > agree with you would be the "media" attribute, however if you abstract the > essence of a media query it is not, in itself, concerned with styling. It > is a conditional test. > > Perhaps we need a fourth element - context - to join the separate channels > of content, behaviour and appearance? > > > On 14 September 2012 16:43, <wsg@webstandardsgroup.org> wrote: > >> ********************************************************************* >> WEB STANDARDS GROUP MAIL LIST DIGEST >> ********************************************************************* >> >> >> From: Mathew Robertson <mathew.blair.robert...@gmail.com> >> Date: Fri, 14 Sep 2012 10:53:34 +1000 >> Subject: responsive images >> >> In this week's links for light reading, there is a reference to responsive >> images, eg: >> >> http://www.netmagazine.com/features/road-responsive-images >> >> I'd be interested to hear this lists' opinion on the proposed syntax. >> >> >> To me this screams of putting styling information, into the document. For >> comparison, we now use media queries to change font sizes and element >> locations, based on viewport size and/or direction. I would have expected >> responsive images to be implemented in a similar manner, not with new html >> tags. >> >> In other words, an <img src=...> is descriptive of the target image, and >> we >> add alt-attributes to describe it as such. Simply showing a higher >> quality image of the same thing, shouldn't change the document structure. >> >> >> Thoughts? >> Mathew Robertson >> >> >> >> ************************************************************** >> Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm >> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm >> Help: memberh...@webstandardsgroup.org >> ************************************************************** >> >> >> > > ******************************************************************* > List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm > Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm > Help: memberh...@webstandardsgroup.org > ******************************************************************* > ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *******************************************************************
