I'll take "deficient, but identically deficient on every browser I support" over "brilliant but only works correctly in Chrome v432.654+" any day.
The <picture> element is overly complex with its media query mechanism, and perhaps even worse than that, features an obnoxious piece of redundancy by requiring the legacy <img> tag AND a separate way to declare the default image at the same time. The srcset attribute has a highly questionable syntax and ridiculously expresses resolution hints in terms of multiples of the main image.
None of them are really elegant and simple, not even in a better-is-worse kind of way; none of them should have made it into the spec.
The use cases it needs to address are mostly documented at  although there are some missing (people are currently putting together a wiki page ) e.g. in order for image prefetching to work the decision on which image to choose can't depend on layout (i.e. it can only depend on things that are likely to be known when the markup is first parsed and before any CSS is applied). There is further discussion at .
But for what it's worth I strongly believe the <picture> concept has a core worth iterating on, the kinks I mentioned could be ironed out easily. Simplify the media query mechanism (there is room for extending it later) and get rid of the duplicate default declarations.
srcset on the other hand is a grossly misguided attempt by Apple to copy an iOS programming mechanism over to the web, it doesn't really have any merits by itself.
The current srcset proposal has terse syntax and just seems to be recreating media queries in another form.
Surely we should adopt a media-queries based approach and fixing media-queries where they are broken.
If the proposed idea from this "single Apple employee" is obviously inferior, then that does indeed sound like a problem. But apparently the idea was discussed for a few days. So it doesn't sound like it's conclusively worse.
When it comes to programming -- especially creating the spec for something this fundamental -- then the best idea should win, irrespective of how long that idea took to be born. If you're cheesed because months of discussion and (semi-)consensus was bumped by a better solution that took days to be discussed, then that's not a problem, that sounds like exactly what should happen.
How can you determine if it's technically superior if you discriminate on the basis of the source of the feature? Choosing between death-by-committee or trusted-auto-approval is not hard.
i.e. the vendors, and not the community of people interested, are in effect (if not necessarily intentionally) dictating the process. The upshot is we'll see features that benefit browser vendors (whether in ease of implementation or insert-conspiratorial-nefarious-Apple-vertical-integration) rather than features that benefit web developers.
Mostly what I get from the article is the sense that people are put off not because of how the Apple proposal was put up for discussion, but that they spent months of their time discussing something, and feel like they got nothing for it. And that rings false to me; either that discussion was useful and helped them identify something superior Apple proposal, or the discussion was a waste of time and resulted in nothing useful, in which case they should just be mad at themselves (or the process).
I don't get the Apple conspiracy angle here. They want something that works better with WebKit? So that means that all of iOS, Android, Chrome and Safari browsers benefit.
The implication is that the long-debated solution lost out not because it was inferior but because it didn't come from a browser vendor. After all, the difference in timescale and hoop jumping is stark.
They aren't even angry that they spent months for the proposal to be rejected.
They're angry that they go through the standard processes for months, when vendors seem to just throw an idea out there and it's in the spec within days.
Nobody's blaming Apple. It just appears from the outside that there is a rule for vendors, and a rule for everyone else.
> The developer community did everything asked of them. They followed procedure, they thoroughly discussed the options available. They were careful enough to consider what to do for browsers that wouldn’t support the element—a working polyfill is readily available. Their solution even emulates the existing standardized audio and video elements. Meanwhile an Apple representative writes one email about a new attribute that only partially solves the problem and the 5 days later it’s in the spec.
So yes, it appears that not only does the standards discussion start with working code, it ends with it.
Unfortunately, the WHATWG seems to do whatever the heck it wants to most of the time and having an idea collaborated on by the development community (the <picture> element) or working code (the <time> element from that whole fiasco a few months back) doesn't seem to amount to much.
Reading the community group, i don't see some "broad support", i see a few web developers saying "this sucks, this thing is better", and on the other side, a few browser vendors saying "no that sucks, this is better".
Someone has to make a real decision, and that seems to be what happened here (from what i understand, the W3C process usually ended up in everyone talking about their feelings for 6-10 years)
BTW, nowhere in the discussion, do i see anyone on the "picture is better" side describe any of the arguments against it, and it seems to hard to believe it is so amazingly perfect that nobody had any issues to with.
TL;DR If this article is representative of the attitude and arguments put forth in favor of the suggested proposal, it is completely understandable that something else was done.
<picture alt="A giant stone" src="stone.jpg, firstname.lastname@example.org, email@example.com">
<img src="stone.jpg" />
I'm not a great fan of "picture" either. We already have <figure>. Why not <image>?
The ideal solution IMO would be something like Progressive JPEG (with less artifacts): you serve a single high-quality image, and the browser downloads as much of it as it sees fit for the situation. Smaller images would be created from a large, lower quality download.
I thought about that as a solution as well. The issue though is that taking the half resolution portion of a progressive JPEG or PNG will result in significant aliasing.
I mean, it's not at all like the situation MS was in with OOXML and ECMA, right?
Maybe now we know to talk to Ian if we want to get things fixed.
Or did I misunderstand something about how democracy works?
 see e.g. http://www.alphabetclock.com/fulldatetime.html .
Regarding the issue: rough consensus, working code.
And beware of monopolists bearing Web standards.
Mike Taylor (at Opera) offered this advice, which I think is smart and on point:
“1) don’t get your feelings hurt 2) respond to srcset on WHATWG and list technical objections that <picture> solves”
Yes, please have a discussion on this on the list now, after it has been added. Ugh.