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
