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

[Simon Pieters]

On Fri, 11 May 2012 20:52:43 +0200, Simon Pieters <simonp at opera.com> 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.

Just for the record if people are interested in exploring possible  
syntaxes, *multiple* attributes on <img> would have the same order of  
implementation complexity as a single attribute. Even an open-ended set of  
attributes.

Here's a straw man example of how an open-ended set of attributes could  
look like (trying to solve both use cases presented), where two images are  
decided between using media queries, and each of those have several  
available resolutions, which are decided between by the browser:

<img src="desktop.jpg" alt="..."
      src-small="mobile-zoomed-out.jpg 32dpi, mobile.jpg 96dpi,  
mobile-hires.jpg 200dpi"
      media-small="max-width: 400px"
      src-big="desktop.jpg 96dpi, desktop-hires.jpg 200dpi,  
desktop-print-res.jpg 600dpi"
      media-big="min-width: 400px">


> 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