[webkit-dev] The SrcN responsive images proposal

[Michael[tm] Smith]

Ryosuke Niwa <rniwa at webkit.org>, 2013-10-23 13:22 -0700:

> On Tue, Oct 22, 2013 at 1:50 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
> > On Sun, Oct 20, 2013 at 10:07 AM, Antti Koivisto <koivisto at iki.fi> wrote:
> > > Ignoring other aspects of this, the idea of making attribute name an
> > > enumeration is somewhat distasteful. It will require ugly special
> > > parsing.
> > > The platform has plenty of attribute values that are lists already.
> >
> > The parsing aspect isn't particularly new - parsing data-* attributes
> > presents the same problem.  You just need to filter the list of
> > attributes on the element to look for things with a src- prefix.  I've
> > heard direct feedback from Yoav, implementing in Blink, that it's not
> > a big problem.
> 
> Just because it was not a big problem in one engine, it doesn't mean it
> won't be in other engines.
> If we're supporting src-N attributes in WebKit, I'd like to see N to have a
> small upper bound; e.g. 10.
> so that we can enumerate all parsed attributes statically at the
> compilation time.

If you're going to do that, and especially if seems like other engines
might end up doing that for similar reasons, it seems like we'd be better
off dispensing with the N part of the proposal and instead have the spec
just define a discrete set of attribute names, e.g., just src1 to src9.

A recent discussion thread on the public-respimg at w3.org list suggests that
in practice even 10 would be higher than the high end of what sites would
currently actually use:

  http://lists.w3.org/Archives/Public/public-respimg/2013Oct/0019.html

Most sites that were looked at just use 2 image source alternatives, and
the two sites found with the highest number of alternatives just used 6.

Doing discrete src1 to src9 would still be ugly but it seems less ugly for
everybody overall than src-N.

  --Mike

-- 
Michael[tm] Smith http://people.w3.org/mike