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
