[whatwg] <imgset> responsive imgs proposition (Re: The src-N proposal)

Mon Nov 11 19:43:35 PST 2013

Here is a complementary approach to the src-N syntax, I'd like to present
for discussion.

The goal is:

1. Address all use cases in a similar way as src-N does without the 'N'
part.
2. Cut the verbose to a 'strict' minimum with reusable OO definitions.
3. Provide a vocabulary that is easy to parse and easily interpretable by
javascript.

It's not src-N or srcset, because the new inline semantic refers to
'sizes' instead,
and require only the one original 'src' for all images.

First we provide the image set definitions in the <head> for the preloader
as:

<imgset>
  1: 1080, 1024, 960, 900, 854, 840, 800, 720, 640, 600, 540, 500, 420,
300, 240;
  2: 200, 150, 100, 75, 50;
  logo: small 150 1x 300 2x, medium 200 1x, large 250 1x;
  custom: /(?<=\-)(.*)(?=\.)/s;     //<-- regex pattern value
</imgset>

Set 1 and 2 define all widths available for those particular sets.
It assumes the 'image-WxH.ext' format by default.
(I omitted a regex for those, we'll consider this a default pattern for
now)

The third set (logo), is one that defines a keyword relationship with img
sizes.
(note: 'logo:small' is both 150px at 1x resolution and 300px at 2x
resolution)
Then 'custom', is the regex pattern used at the platform level for naming
the different sizes.

Here is the first img example using the 'image-WxH.ext' image name syntax.

<img width="600" height="300" src="image-600x300.jpg" res="1x" imgset="1"
sizing="ratio" sizes="100% (360px) 66% (800px) 33%">

The new 'res' attribute would define the pixel density the author chooses
to provide.
The 'imgset' attribute refers to the imgset target definition list  by ID
or keyword.
The 'sizing' attributes provides the custom matching pattern for how
images are stored, and for the browser to replace the original src with
its current width+resolution match.
Finally the 'sizes' attribute is similar to src-N as far as handling
variable size imgs.

The browser can figure out the width/height ratio given by the 'width' and
'height' attributes.

Here is another example which use the imgset '2' with a pixel size, and
indicated resolution at 1x and 2x:

<img width="100" height="100" src="gravatar-100x100.jpg" res="1x,2x"
imgset="2" sizing="ratio" sizes="50px (360px) 75px (800px) 100px">

Even though the breakpoint sizes are in pixel, the browser can do the math
using the 'ratio' sizing and the given 'res' values. No need to specify
multiple pixel densities in the imgset(s) when a pixel ratio is involved.

Finally the 'custom' case which uses the 'logo' imgset as reference.

<img width="250" height="100" src="logo-large.jpg" res="1x,2x"
sizing="custom"  
imgset="logo" sizes="small (360px) medium (800px) large">

The 'custom' regex pattern is used to determine what image name correspond
to the appropriate breakpoint sizes. With the above applied to an iPhone
3, logo-large.jpg becomes logo-small.jpg, and stays logo-large.jpg for the
iPhone 4.

Overall this solution cuts off the fat by a very large margin. And the
introduction of a regex way seem like a good approach (and probably the
only one) to also remove the 'src' verbose, with the advantage of reusable
definitions by multiple images.

Also the head's <imgset> can be converted to (or even given as) json for
javascript interpretation readiness.

Anyhow, this is the complementary and optimized approach I am suggesting.

-BR

On 11/10/13 9:29 AM, "Ilya Grigorik" <igrigorik at gmail.com> wrote:

>On Sun, Nov 10, 2013 at 8:59 AM, Tab Atkins Jr.
><jackalmage at gmail.com>wrote:
>
>> It's easy to look at something more complex than what you're used to
>> and dismiss all the excess as unneeded, but it's really, seriously not
>> in this case.  The things I'm addressing are the things that RICG
>> research found were common and necessary, no more and no less.
>>
>
>Big +1 to that -- src-N addresses all the RICG use cases in a consistent
>and coherent way.. and is the only option that does so. Serving images in
>our new multi-device / responsive design world *is* a much harder problem
>and the "complexity" of src-N is simply a reflection of that.. Sticking
>our
>heads in the sand and pretending that this is not the case, or punting the
>problem down the road (as we've already done for the past few years), is
>not a sound strategy.