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

A common sentiment here seems to be that the two proposed responsive
image solutions solve two different use cases:

- <img srcset> for serving different resolutions of a content image
(for bandwidth and dpi)
- <picture> for serving different versions of a content image (for art
direction)

...and that neither solution can deal with both issues. I disagree. I
would describe it as a single, broad use case:
Serving different sources of an image based on properties of the
client. These properties could include:
- Viewport width/height
- Containing element width/height
- Device orientation
- Colour capability
- Old-fashioned media type (screen/print)
- Connection speed
- Pixel density
- Things we haven't thought about/aren't an issue yet

There are media queries already standardised and implemented for many
of the above. Others will surely follow. One of the main strengths of
<picture> is that is incorporates media queries (rather than its own
syntax for testing properties), which will be developed as time goes
on to include other client properties as they become relevant. This is
good DRY practise.

The differences in the sources could include:
- Resolution
- Compression
- Zoom
- Cropping
- Aspect ratio
- Colour/monochrome

This is all possible with <picture>. I also agree with many other
developers that <picture> is definitely the more developer-friendly
syntax, in terms of reading, writing, maintaining and scripting.

Received on Sunday, 13 May 2012 07:52:05 UTC