[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 <source>s 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 <source>s 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 <source>s 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 <source>s 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

Received on Tuesday, 7 February 2012 05:42:27 UTC