[whatwg] Implementation complexity with elements vs an attribute (responsive images)
simonp at opera.com
Fri May 11 11:52:43 PDT 2012
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.
More information about the whatwg