the proposed spec

There are many use cases to consider and there are as many different opinions as there are people in the front-end business. Art direction, performance and implementation methodologies are all part of the problem that make or break a responsive image technique (Chris Coyier made a nice overview). The problem with the proposed spec isn't so much the syntax (or variations of it) though, but the choice to make it part of the html spec. I'm clearly not the only one that thinks responsive images shouldn't be part of the html spec, the question is if there is still time left to do anything about it.

responsive lives in css

Up until now responsive behavior lived primarily in css files. Sure there are some back-end options (particularly when certain content is excluded from smaller resolutions), but for the bigger part it's always been about css breakpoints and changing css rules. No actual html changes are needed to make a decent responsive version of your site and that's awesome, because responsive is all about displaying content and performance, which suits css just fine.

Html on the other hand is about structure and semantics, and those are not impacted when you want to serve a responsive image. Sure enough there may be some art direction involved between the different sizes, but even that doesn't go beyond cropping and resizing. You may end up loading a different image file, but the content of that file is semantically the same as the related responsive images.

site version 2.0

What bugs me the most is that redesigns including new breakpoints could have a major impact on the html code. If a new breakpoint is introduced and it impacts the images, you're bound to end up fiddling with the html code, which just plain sucks. It's not very future-proof, it's expensive development and it is completely unnecessary. CMSes will need to be extended to allow for this behavior and control over responsive will be spread even further between the different levels of front-end development.

It's a shame to see that a solution like this will hamper my (our) quest for unified, robust and reusable html. It's another html setback that shouldn't be allowed, if only because css has been putting enough strain on html already these past couple of years. It's time to revert that sentiment and go back to the good old separation of content,style and functionality paradigm to actually improve our profession rather than try to fix it McGuyver style. It's hard enough (I'd say almost impossible) to stay on top of everything these days and further mixing responsibilities isn't going to help us in the long run.

performance concerns

While I understand that performance is a big motivator these days, it's equally important to realize that it's a very context-dependent and contemporary issue that is impacted by every technological move forward. It's good to have build-in options that allow us to optimize performance for certain contexts, but it's also good to realize that in two (or three, or five) years time some or most of those concerns could be obsolete.

conclusion

I don't even care much about the final syntax, as long as it becomes a part of the html spec I'll be pretty damn disappointed with whatever working group or standards organ that approves this solution. It's definitely not a good move and one I'm certain we'll regret at a later time. Then again, some people may start to think that's part of the charm of our profession.

I feel this is a clearly a result of the "pragmatic" vibe that has been running through our community. While it definitely brought us some good, I'm equally confident that it will introduce it's own set of drawbacks when time is due. Sometimes it's just better to think something through then to apply a quick fix that may save your hide for a couple of months but will kill you when it really matters.