Benjamin Poulain <[email protected]>, 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 _______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
