[webkit-dev] The SrcN responsive images proposal

[Michael[tm] Smith]

Benjamin Poulain <benjamin at webkit.org>, 2013-10-20 13:08 -0700:

> On 10/20/13, 9:07 AM, Antti Koivisto 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.
> 
> I was thinking the same thing last night. In addition to weirdness on
> the engine side, it looks like a nightmare for authoring/tooling.
> 
> Is there a precedent for this strange notation?

As far as having a open set of attribute names defined by a pattern rather
than a set of discrete names, I think the only precedent is the "custom
data attributes" mechanism, which I guess as you know provides for having
attribute names with a "data-" prefix followed by some arbitrary string.

But unlike the spec for the data-* attributes, whose values can be pretty
much anything, the proposed srcN spec also places requirements on the
expected microsyntax/datatype for srcN values.

So while tools can pretty much ignore "data-*" values -- or even ignore the
data-* attributes altogether, since they're not meant to have any meaning
or utility except in the context of the JavaScript code specific to whatever
Web application they're used in -- it's imaginable that tool vendors might
want to have their tools provide some assistance to authors with, say,
confirming that their srcN values conform to the expected microsyntax.
Especially since the proposed srcN microsyntax is relatively arcane and error-
prone (though less arcane and error-prone than the srcset microsyntax).

For some tools, providing that kind of support for srcN really might not be
so hard to do all. But for other tools, I know it can be.

To give a specific example: I work on the code for the W3C validator and I can
tell you that implementing validator support for the srcN proposal would require
adding a not-insignificant amount of new special-casing code that nothing else
has ever required, along with some greater-than-normal (though still relatively
small) runtime cost. And the way I'd have to implement it seems hacky and
ugly and I'd really rather not do it unless there's no other alternative we
can get agreement on for solving the responsive-images problem.

  --Mike

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