Re: New responsive images proposal

I see how the pattern idea is elegant, but it has some big problems which
have already been noted. (generating unwieldy combinations is the one that
sticks out to me.)

I'd like to suggest a variation on the idea.  We introduce something called
an imgset (or some other appropriate name.)    It gets a name, a selector
(which would be written in CSS media selector syntax, not to be defined or
discussed here), and a scaling factor, which would indicate the scaling to
convert from native image pixels to CSS pixels.   imgset's can be defined
at the beginning of any flow block, or in the head of the HTML document,
and they'd look something like this:

<imgset name="tablet" selector="{selector goes here}" />
<imgset name="retina" selector="{selector goes here}" scaling="50%" />

When an imgset tag is parsed, the selector is immediately analyzed and an
entry is stored into the list of imgset for this rendering context.  The
entry is a boolean -- true if the selector matched, and false if it did
not.  The selector is also kept so they can be re-evaluated in the event of
a window resize, etc.

The name is of the imgset is what makes this future-proof and applicable to
a wide variety of use cases.  You can give it any name you need.   mobile,
desk, retina, lowbandwidth, etc...  come up with whatever you need for your
particular use case.   Whenever an img tag is encountered, the original src
attribute is saved into src-default, and the first src-* attribute
encountered whose imgset is a positive match becomes the src attribute
which is actually stored in the DOM.

<img src="fallback.png" src-tablet="tablet.png" src-retina="retina.png"
alt="Acme Inc. Logo" />

The following would happen when this tag is parsed.

The src attribute's value is copied into src-default (this is important for
dynamic response later after the page has rendered)
The src-tablet attribute is examined.  If the imgset named tablet is active
(if its media selector was a match) then this value is saved into the src
attribute, and no further src attributes are considered for replacement.
 (Note, all the src-* attributes are saved, however, so dynamic response
can be dealt with in the event of a window resize or such.)

If the width or height is specified explicitly on the img tag, such as in
this example, it is simply obeyed.  If the width is omitted, the native
width of the image multiplied by the scaling factor is used. (So if the
retina.png was loaded, and it was natively 400px wide, it would be rendered
as 200 css pixels.)

I see these benefits:

* Can be implemented at parse time, avoiding the issue of javascript having
to execute before browsers prefetch occurs.
* Does not dictate filename patterns.  You can use any filenames you want,
and even the same filename for multiple matches if appropriate (maybe the
cellphone and tablet version of one image are the same, but different for
another, etc.)
* Fallback for backwards compatibility is already working.
* Polyfills could be used to implement this today, with the only drawback
being that the fallback src will begin to prefetch first.
* Hooking into CSS media selector means we don't have to spec it
separately. Sure, it's missing some features we might want (like speed and
bandwidth cost) but that's a job for another group.
* The pixel scaling factor isn't adequately addressed in a lot of the other
solutions I've seen proposed, and it's a critical thing to take into
account when deciding how to utilize an image.
* The verbosity has semantic meaning, or at least the potential for
semantic meaning, unlikes src1, src2, etc..

Am I missing anything here?