[webkit-dev] The SrcN responsive images proposal

Tab Atkins Jr. jackalmage at gmail.com
Thu Nov 7 14:22:26 PST 2013

On Thu, Nov 7, 2013 at 9:24 AM, Timothy Hatcher <timothy at apple.com> wrote:
> On Nov 6, 2013, at 4:26 PM, John Mellor <johnme at chromium.org> wrote:
>> I've suggested before that the attributes could be combined if that's
>> considered simpler. My only concern is that most developers aren't used to
>> putting line breaks in html attributes, so might feel obliged to put all the
>> alternatives on one line, harming readability. But as long as the developer
>> documentation encourages line breaks, that could be fine...
> As I replied before, there should only be one attribute — srcset. Given that
> your micro format extends around parts of the existing micro format of
> srcset, it just makes sense to reuse the same attribute. Wishing srcset
> didn't exist doesn't make it go away.

srcset doesn't significantly "exist" yet. It's in one browser's
nightly.  I'd like to resolve this soon, but it doesn't help anything
to pretend that it's already a done deal that must be engineered

> Tweaking it is more approachable and

srcset's parsing algorithm *cannot* be extended in the future.  I gave
an example of how it would fail over on blink-dev; I can reproduce it
here if necessary.

> should get better support from the WebKit community and likely other venders
> who are now stalled because of this proposal.

The other vendors have implementors ready to write src-N support when
it's felt that it's the right thing.

> Especially since the current
> viewport syntax in srcset has little-to-no support or implementations. Also
> if srcset is the attribute, the CSS function srcset() should support the
> same micro format.

The CSS function is image-set(), and it only exists in WebKit/Blink,
prefixed.  The connection between the CSS and the HTML solutions isn't
that strong.

> Designing this proposal around code formatting is a non-issue in my opinion
> and it surely didn't stop SVG from providing just one "d" attribute for
> <path>. Following the your logic, it should be d-N. Sure, <path d="…"> is
> primarily meant to be written by software.

Please don't try to use reducto ad absurdum; it usually gives absurd
results.  The reasoning for multiple attributes is not "because it's a
list", it's because it's a list of lists, and would require three
different delimiters.


More information about the webkit-dev mailing list