[whatwg] Implementation complexity with elements vs an attribute (responsive images)

[Mathew Marquis]

While that information may be available at the time the img tag is parsed, I don’t believe it will be available at the time of prefetching — I’m happy to research this further and report back with citations. I’m sure I don’t have to tell you that “disable prefetching on img tags just in case there are matching sources” is going to be a hard sell to vendors that do prefetch. If we’re left with a solution that fetches the original src before applying any custom source logic, well, we’re no better off than we would be with one of the scores of script-based solutions that have come about in the past year.

To your original point, though: as much as you can absolutely make a case that a simpler implementation will benefit developers if inherently more stable, you can’t convince me that `img set` suits the needs of developers as well as `picture`. In fact, even if you were to convince me, it wouldn’t matter. Picture is, for better or worse, what developers want and expect in a “responsive images” element. There’s certainly no shortage of proof of that, on this page alone: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/ At the moment, the Community Group server seems to be down due to excessive traffic.

I’m regret that picture would be more difficult to implement; I do. If there’s anyone that can understand that frustration, it’s another developer. But implementing a completely disparate method way of specifying media sources based on client-side information is in no way beneficial to the end author — and certainly holds no provable benefit to the end _user_. All things being equal for the end user, implementor convenience should not take priority over developer convenience. This is the syntax that the developer community almost whole-heartedly agrees upon — and when was the last time you saw that phrase used in reference to proposed standards?

If implementor convenience does take priority over that of authors, well, here we are — but let’s not frame it as though it’s doing developers some thickly-veiled favor. They’ve voiced their preference, in no uncertain terms.


Mat Marquis


On May 11, 2012, at 2:52 PM, Simon Pieters wrote:

> There seem to be two proposals for what syntax to use for the responsive images use case: several elements vs. an attribute.
> 
> I think an attribute is simpler to implement and thus likely to result in fewer bugs in browsers, which in turn benefits Web developers.
> 
> With <img src="..." srcset="...">, in the parser case, all the information is available when the tag has been parsed. Excellent! In the scripted case, we need to "await a stable state" when the src or srcset attributes are changed (because the same script might also change the other), and then process the attributes again. The spec already does this for src="" because of the crossorigin="" attribute, so it's basically a solved problem already for <img> in the spec.
> 
> With <picture><img src="..."><source ...>...</picture>, in the parser case, the browser can't know it has all the information is not available until the picture element has been popped off the stack (since there might be futher <source> elements), which necessarily delays fetching the image. Moreover, scripts might have changed things before then, because scripts can run between the time that the "picture" element is added to the document and the time it is popped off the stack, which is a potential source for bugs. In the scripted case, we need to listen for changes to img elements' parents, changes to img element's attributes, changes to source elements' parents, and changes to source elements' attributes, and "await a stable state" and then process the picture element's img and source elements' attributes (for both the old and new picture element, if you moved an element between two picture elements), which is more complex than the attribute case.
> 
> -- 
> Simon Pieters
> Opera Software