[webkit-dev] The SrcN responsive images proposal

[Michael[tm] Smith]

"Tab Atkins Jr." <jackalmage at 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