W3C home > Mailing lists > Public > public-respimg@w3.org > October 2013

Re: What do we do with picture?

From: David Newton <david@davidnewton.ca>
Date: Thu, 17 Oct 2013 11:31:43 -0400
Cc: public-respimg@w3.org
Message-Id: <B8ED837F-29B4-40B1-B896-8F4FCA118CED@davidnewton.ca>
To: Marcos Caceres <w3c@marcosc.com>
I agree with some of the other comments that, from my perspective as a dev, <picture> is still the most attractive option in terms of readability and maintainability. If votes count, I vote not to retire <picture> yet. That said (despite the priority of constituencies), I understand that the only tool we can get is the one we can convince browser vendors to implement.

So, assuming src-n moves forward, my current biggest concerns are:

1. ability to handle file format switching (which Tab has said should be possible, but hasn't yet been integrated)
2. problems associated with reusing <img> -- polyfilling, breaking backwards compatibility with older <img>-based scripts, etc. This could potentially be solved by taking bjankord's approach @ https://gist.github.com/bjankord/6781503
3. use of max-width values instead of min-width values (trivial to solve, as I understand)
4. confusing syntax, especially around the viewport stuff
5. lack of the advanced fallback/accessibility content options we had with <picture> (though longdesc may help us out there)

Dave


On 2013-10-17, at 10:28 AM, Marcos Caceres <w3c@marcosc.com> wrote:

> Hi All, 
> The Editors of the <picture> spec been under pressure from the HTML Working Group Chairs to take some action with regards to picture. We can continue to move it forward along the recommendation track or we can "end-of-life" it by publishing it as a Note. In light of the src-n proposal, I'm inclined for us to publish it as a Note. The rationale being that src-n does exactly the same things that <picture> was doing, but overcomes the shortcomings with <picture>, in particular:
> 
> 1. we don't need a new element (picture) that represent something that semantically already exists in the platform (img). 
> 2. we don't need to special-case the <source> element. 
> 3. we don't need to have an element that accepts child elements (which browser vendors don't like).
> 4. we don't need to define all sorts of complex interactions between <source> and <picture> by monkey patching "media elements". 
> 
> The src-n proposal is by no means perfect - particularly the viewport-url syntax might need a little more love; but apart from that, it's basically all the goodness of <picture> in a nice little img package.  
> 
> So, does anyone have any objections to us publishing picture as a Note? 
> 
> -- 
> Marcos Caceres
> 
> 
> 
Received on Thursday, 17 October 2013 15:32:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:40 UTC