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

Maciej Stachowiak mjs at apple.com
Sun Nov 17 15:22:52 PST 2013

On Nov 15, 2013, at 3:00 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:

> On Fri, Nov 15, 2013 at 12:39 PM, Adam Barth <w3c at adambarth.com> wrote:
>> Do you have an alternative proposal aside from src-N?  Recall that
>> src-N has been rejected by WebKit and therefore is no longer viable.
> Hey, WebKit, what's your answer if we just take src-N and use a ||
> separator to cram them all into a single attribute?  Otherwise
> identical proposal; none of this "gradually expand srcset" thing.
> I think this is a terrible idea, and plenty of actual authors agree
> with me, but if multiple attributes is the one thing that's acting as
> a deal-killer for implementors, then screw it, we can mitigate the
> pain with an OM later.  May god have mercy on our souls, etc.

I can't speak for all WebKit developers or even all with an interest in this, but my thoughts are as follows:

The src-n proposal with the following changes seems likely reasonable:
- In a single attribute (ideally named "srcset" to avoid gratuitous renaming) with || or some other separator
- viewport-urls syntax removed or changed to be more human-understandable 

The latest style-based <img>/content proposal seems reasonable if the following issues could be addressed:
- Always loads src per current browser behavior (might be fixable by omitting 'src' attribute).
- Not obvious if preload scanning can reasonably be expected to resolve CSS selectors (hopefully parser/preloading experts can weigh in).

I personally somewhat prefer the style-based proposal if the issues are addressed, as it has less surface syntax.

It would probably also have to be combined with vanilla x-only srcset to do resolution scaling combined with art direction, without forcing sizes to be set explicitly.


More information about the whatwg mailing list