"Tab Atkins Jr." <jackalm...@gmail.com>, 2013-10-22 14:50 -0600:
> As I've argued before, I think "making validators easy to write" > is a concern that's very, very low on the priority of constituencies. So don't keep framing it that way, then. It's misleading. I'm not arguing for making validators easier to write a priority. (I've never said that, so you don't need to add the quotes.) I'm arguing for not making it harder for authors to catch errors in their HTML markup. > Only a few people ever write validators in the entire web, so it's okay > to saddle them with extra engineering effort if it helps the other > constituencies. I agree about users as a constituency being a higher priority. But I think you're being overly dismissive about the scale of the extra engineering effort you might be saddling tool vendors with when src-N gets implemented. Validators are just one type of tool in a class of related tools that try to provide authoring assistance to people making Web content. In the same class are tools like the HTML-aware features in many text editors, which provide context-sensitive interactive editing help -- with things autocompletion of element and attribute names, etc. There are a lot more of those types of in-editor tools out there than there are validators. And there are libraries and standalone HTML tools that aren't strictly validators but that, like validators, provide a type of static analysis of HTML markup to alert authors to problems they otherwise might not discover until they load their content in a browser and manually test it there. The src-N proposal would potentially making it more difficult for all those kinds of tools to help authors catch errors in the HTML markup they'd use for responsive-images use cases -- specifically, more difficult than markup they'd use if the <picture> proposal were implemented. (I'm not advocating for <picture> here, I'm just saying it doesn't have this same shortcoming.) > Further, the problem you've described with validating these has nothing > to do with src-n itself, but rather is a consequence of the particular > technology the W3C's validator currently uses. The particular technology the W3C's validator currently uses is essentially just a formal grammar. And in my experience at least, many other tools that provide static-analysis types of features for working with HTML elements and attributes also use a grammar formalism of some kind. And pretty much none of those formalisms have a way to express that a certain pattern should be allowed as an attribute or element name. They all assume explicit names. > Many possible validator architectures would have no problem at all with > handling attributes like this. Yeah, it's imaginable that hypothetically a lot of HTML-analysis tools might not have any problem handling a set of attribute names defined by a pattern. The problem is, though, that in practice, I think many existing tools would have a problem with it. In my experience, even existing HTML-analysis tools that don't rely on a grammar like the validator does tend to either pretty much have what amounts to an ad-hoc equivalent of a formal grammar, or are hard-coded with data structures that assume new attribute names that might get added to them are going to be discrete names, not patterns. That assumption in a lot of existing tools that any attribute names they'll ever need to deal with are going to be names, not patterns, pretty much amounts to being an invariant. And with src-N you'd be changing that invariant. --Mike -- Michael[tm] Smith http://people.w3.org/mike _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev