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

Mon Nov 11 23:58:11 PST 2013

Unfortunately, we can't add new tags to head.  If the parser sees a
tag it doesn't recognize in the head, it creates a fake body tag and
pushes the tag down into the body.

Adam

On Mon, Nov 11, 2013 at 7:43 PM, Bruno Racineux <bruno at hexanet.net> wrote:
> 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.
>
>