Re: What do we do with picture?

It's been something like two years the issue of responsive images is 
discussed in all possible ways. I believe we now have enough data on the 
matter to be able to make some wise decisions. They may not represent 
everyone's dream solution, but web development has as much compromise to 
make as any other domain in order to progress toward its Graal. As web 
developers, what we need is a solution that can be implemented as soon 
as possible, ideally two years ago.
It seems that Tab and John have been able to produce a proposal that 
tackles most of the problems at hand with an approach that is acceptable 
for developer as well as for browser vendors.
It doesn't require a new element, which is good for browser's testing 
suite as well as for backward compatibility. This probably also helps on 
the prefetching concerns and polyfilling. It is way less verbose than 
the picture element, thanks to its DRYer approach, and might even be 
more intuitive after a while. And it has the advantage of being already 
quite well spec'ed.
Not to mention that it has already gained a decent traction in a fairly 
short amount of time.
I think we should focus on that and try to fix the few glitches left in 
the proposal, in order to push things forward. We'll probably find it's 
not the perfect solution yet, but with the amount of thought that has 
already been spent on that, it's worth trying to push something forward 
now rather than trying endlessly to find the perfect fit.
So let's get things done. Support srcN !

Le 17/10/2013 18:20, Aaron Gustafson a écrit :
> I completely agree that we need to find one proposal we’re happy with 
> and put our weight behind it.
>
> My main concern right now is "teachability". Thinking back on the 
> history of HTML & CSS (especially when it comes to accessibility 
> APIs), lack of a clear understanding of the spec (and sometimes the 
> lack of a clear spec) has directly undermined the usefulness of 
> certain techniques (see display:none, generated content, etc.). I am a 
> little concerned that if this syntax is not immediately grok-able by 
> the workaday author, it could cause us more long-term headaches.
>
> Picture was simple and intuitive IMHO, despite how complex the work 
> would be for the implementors. SrcN is a little more complicated (and 
> potentially confusing in a "view source" scenario). I am still mulling 
> over this syntax, but I think the current state of offering multiple 
> approaches (some of which are easier to grasp immediately) is a good one.
>
> I have three long flights ahead of me today so I’ll think on it a bit 
> more, but as of right now I am a tentative +1.
>
>
>
>
> On Thu, Oct 17, 2013 at 8:49 AM, Odin Hørthe Omdal <odinho@opera.com 
> <mailto:odinho@opera.com>> wrote:
>
>     On Thu, Oct 17, 2013, at 17:14, Ilya Grigorik wrote:
>     > +1 for more wood behind fewer arrows. (i.e. publish as Note).
>
>     I agree with this as well. I think it will wise to have a clear path
>     forward that implementors can live with.
>
>     Also, I prefer this proposal to all we've had. It's a very good one. I
>     just ache to use it. That would hopefully happen faster if we're all
>     pulling in the same direction :)
>
>     --
>       Odin Hørthe Omdal
>     odinho@opera.com <mailto:odinho@opera.com>
>
>