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

[Bruno Racineux]

On 11/15/13 3:23 PM, "Tab Atkins Jr." <jackalmage at gmail.com> wrote:

>I don't understand.  You don't "repeat" any sources, you specify them
>once.  There's just a batch of sources per image.  Can't make this
>more compact.

What I mean is that with src-N you will have to repeat the paths AND the
full batch for every image that share the same source+breakpoint pattern
unless you use a template or regex model.

Assuming your RespImg EXAMPLE 5 (from the draft):

<img src-1="100% (30em) 50% (50em) calc(33% - 100px);
             pic100.png 100, pic200.png 200, pic400.png 400,
             pic800.png 800, pic1600.png 1600, pic3200.png 3200">


In the real world with clouds, this is your average prospect size of it
with just 4 imgs:

<img src="http://farm8.staticflickr.com/7325/10858537575_e6af698601_m.jpg"
src-1="100% (30em) 50% (50em) calc(33% - 100px);
http://farm8.staticflickr.com/7325/10858537575_e6af698601_s.jpg 100,
http://farm8.staticflickr.com/7325/10858537575_e6af698601_t.jpg 200,
http://farm8.staticflickr.com/7325/10858537575_e6af698601_m.jpg 400,
http://farm8.staticflickr.com/7325/10858537575_e6af698601_l.jpg 800,
http://farm8.staticflickr.com/7325/10858537575_e6af698601_xl.jpg 1600,
http://farm8.staticflickr.com/7325/10858537575_e6af698601_xxl.jpg 3200">
<img src="http://farm8.staticflickr.com/7325/10858537575_e6af698602_m.jpg"
src-1="100% (30em) 50% (50em) calc(33% - 100px);
http://farm8.staticflickr.com/7325/10858537575_e6af698602_s.jpg 100,
http://farm8.staticflickr.com/7325/10858537575_e6af698602_t.jpg 200,
http://farm8.staticflickr.com/7325/10858537575_e6af698602_m.jpg 400,
http://farm8.staticflickr.com/7325/10858537575_e6af698602_l.jpg 800,
http://farm8.staticflickr.com/7325/10858537575_e6af698602_xl.jpg 1600,
http://farm8.staticflickr.com/7325/10858537575_e6af698602_xxl.jpg 3200">
<img src="http://farm8.staticflickr.com/7325/10858537575_e6af698603_m.jpg"
src-1="100% (30em) 50% (50em) calc(33% - 100px);
http://farm8.staticflickr.com/7325/10858537575_e6af698603_s.jpg 100,
http://farm8.staticflickr.com/7325/10858537575_e6af698603_t.jpg 200,
http://farm8.staticflickr.com/7325/10858537575_e6af698603_m.jpg 400,
http://farm8.staticflickr.com/7325/10858537575_e6af698603_l.jpg 800,
http://farm8.staticflickr.com/7325/10858537575_e6af698603_xl.jpg 1600,
http://farm8.staticflickr.com/7325/10858537575_e6af698603_xxl.jpg 3200">
<img src="http://farm8.staticflickr.com/7325/10858537575_e6af698604_m.jpg"
src-1="100% (30em) 50% (50em) calc(33% - 100px);
http://farm8.staticflickr.com/7325/10858537575_e6af698604_s.jpg 100,
http://farm8.staticflickr.com/7325/10858537575_e6af698604_t.jpg 200,
http://farm8.staticflickr.com/7325/10858537575_e6af698604_m.jpg 400,
http://farm8.staticflickr.com/7325/10858537575_e6af698604_l.jpg 800,
http://farm8.staticflickr.com/7325/10858537575_e6af698604_xl.jpg 1600,
http://farm8.staticflickr.com/7325/10858537575_e6af698604_xxl.jpg 3200">

Now imagine 20 images... Or an additional src-N to each of them...
While gzip size will generally compact those fairly well, that affects the
overall size of your page (especially if images sizes are identified by
folder instead of img suffix, where the compression will not be as good)
It is also making the source difficult to read for debugging purpose
because of the length.  This what I mean by bloat.

While that doesn't seem to be of everyone's concern, the raw byte size of
pages will quadruple instantly with image galleries. That's not DRY,
and more memory consumption for mobiles.

>The repetition is in the MQs, and that's solveable quite directly and
>generically with custom MQs.

It's in the src-path(s) too as explained above.

My imgset template model only gives you this per image instead:

<img src="http://farm8.staticflickr.com/7325/10858537575_e6af698606_t.jpg"
     imgset="flick 100% (30em) 50% (50em) calc(33% - 100px);">

Or even less if that 'variable sized' MQ language is also tokenized at the
head level (which you currently seem to working on):

<img src="http://farm8.staticflickr.com/7325/10858537575_e6af698606_t.jpg"
     imgset="flick@('flexsize');">

>
>> Here is an update along my initial model with John's example, and
>> custom media-vars (with the syntax we discussed on the w3cstyle list):
>>
>> <head>
>> <style>
>>  @media-var 'smallicon' (max-width: 19.99em);
>>  @media-var 'flexwidth' (min-width: 20em);
>>  @imgset 'set-1' (64 64 1x, 128 128 1x, 256 256 1x 128 2x 64 3x),
>>regexp();
>>  @imgset 'set-2' (160 160, 320 320, 640 640, 1280 1280), regexp();
>> </style>
>> </head>
>>
>> <img src="fallback.jpg"
>>      imgset="set-1 at media('smallicon') 128px;
>>              set-2 at media('flexwidth') 100% (30em) 50% (50em) 33%">
>
>Where are the source urls?  Are they supposed to be those numbers in
>@imgset?  What does regexp() mean?  I don't understand your use of
>commas in @imgset.

There is no need for other src urls other than the base src template.
All you have to do is replace the suffix, folder, or other pattern from
that path (as defined by the framework which resizes your images), using
either the regex pattern or a template model, to load the right image.

I am not aware of the css specs grammar restrictions enough to define
perfectly applicable syntax, so please indulge my syntax errors.
It's more of your specialty.

I just figured I'd use something similar to @media or @document to
have a syntax close to @media that doesn¹t require a full css parser for
the other syntax, and separate the @imgset language from that of the css
presentational syntax. (as you expressed against including in the head,
which I think I agree would be possibly conflicting)

>
>> It does not require the preloader to have full css parser. It only has
>>to
>> parse @media and the new @imgset CSS subset language, using a similar
>> syntax to @media. And I believe if offer an easy way to polyfill this.
>
>This isn't as terrible for polyfilling, since it's easier to spot
>things and extract them with a regex.  I find it less understandable,
>though this might be because you haven't explained most of your syntax
>and possibly have some syntax errors.

Fair enough, my initial email was badly cut with automatic line-breaks...

I'll expand:

<style>

@media-var 'smallicon' (max-width: 19.99em);
@media-var 'flexwidth' (min-width: 20em);

Here, as we discussed on w3style you tokenize MQs with custom-vars using
string keywords to centralize them and avoid the MQ repeats.

@imgset 'set-1' (64 64 1x, 128 128 1x, 256 256 1x 128 2x 64 3x), regexp();
@imgset 'set-2' (160 160, 320 320, 640 640, 1280 1280), regexp();

Above, the new @imgset 'css subset' grammar define reusable imgset classes
'set-1' and 'set-2'.

They list the set of images with their respective width and resolutions
just like you list the images in src-N, expect that we only specify a
token (instead of the full src). The full path is determined by the
browser with a replace() using the regexp() pattern.

Generally this is the suffix of the images like the flickr example. I just
didn't put a regex because in John's example he had named the img with the
actual width, (hence the 'width with' repeats where the first word is the
actual token) and like I said, I suck at regex.

For more clarity, take this updated initial example (from the beginning of
the thread):

@imgset 'set-1' (small 150 1x, medium 200 1x, large 300 1x 150 2x),
		regexp("/(?<=\-)(.*)(?=\.)/s");


And finally here, we define the two imget "classes" applicable to that
Image using the tokens we defined in the head, as well as possible mix and
match with other token or standard MQs.

<img src="fallback.jpg"
     imgset="set-1 at media('smallicon') 128px;
             set-2 at media('flexwidth') 100% (30em) 50% (50em) 33%">

The Imgset attributes allows for multiple classes, set in css style
fashion, with a slightly new shortcut syntax being:
imgsetclass at media('mycustomMQvarstring')

With a template or regex src replacement, we can make the fairly
Reasonable assumption that most images sizes can be replaced using a
single token
like '/my-image-{size-token}.jpg'

The exception to this, is the syntax used by other platforms like
Worpdress 
where the image template for different sizes is not a token, but the width
and height given as 'image-name-WidthxHeight.jpg'.

This case could be handled by not providing any regex rule for the @imgset
like: @imgset 'set-1' (1080, 1024, 960, 900, 854, 840, 800, 720, 640, 600);

In which case all the browser has to do is to automatically find the
height from the original ratio implied by the image element itself:
<img width="600" height="300"

Which would make 'image-name-WidthxHeight.ext' the default, and
an even less verbose @imgset, since there is no need for image
replacement tokens. The browser can do this math automatically for
resolution etc.. 

The @imgset grammar is fairly simple and it only adds one attribute to the
DOM.