Hi Zack,

We have already implemented a fix for this case. To test it, please try validating your doc here:

  http://www.w3.org/html/check

You should get this message:

Error: Element script is missing required attribute src.
From line 3, column 4; to line 3, column 17
title>↩   <script defer>↩   1;

Let me know if you think that's an improvement or not.

Because of the way the backend does it core validation step -- which, using Relax NG (grammar-based) schema validation -- that error message is about the best we can do, if we stick with having that part of the backend generate it. That is preferable for some reasons that are more involved than you probably want to know about here. Suffice it to say that grammar-based validation tools are general-purpose tools that don't provide any means for fine-tuning of particular error messages.

That said, there is another part of the backend that does non-schema/non-grammar validation --  essentially using a type of assertions checking -- and that does permit complete control over the text of error messages it emit. So, we could set up that part of the reporting backend such that it emits an additional message for this case, saying "the defer [ and async ] attributes are only allowed if the src is present".

But I would prefer not to do that unless you really think the "Element script is missing required attribute src" does not provide enough information for you to identify what needs to be changed in order to get the document to validate.

Knowing that the 'src' element is the one it thinks is missing, is indeed very helpful -- that would have led me more directly to the relevant parts of the spec, and then to realizing what was really wrong.

However, I think that high-quality diagnostic messages are *vital* for a service like this, and that in this case, "missing required attribute 'src'" is not  good enough; it takes a leap of logic to get from "why does it think 'src' is required when I, the human, know damn well it isn't?" to "maybe there's a problem with using 'defer' on an inline script".  If your "grammar-based validation technology" makes it hard to tune error messages, maybe it's the wrong technology.

(In reply to comment #2)
> However, I think that high-quality diagnostic messages are *vital* for a
> service like this, and that in this case, "missing required attribute 'src'" is
> not  good enough; it takes a leap of logic to get from "why does it think 'src'
> is required when I, the human, know damn well it isn't?" to "maybe there's a
> problem with using 'defer' on an inline script".  If your "grammar-based
> validation technology" makes it hard to tune error messages, maybe it's the
> wrong technology.

I fully agree that it may be the wrong technology and someday we might end up swapping it out for something better. The problem is that currently there really is nothing any better (those there is a lot of stuff far worse) -- and our only alternative would be to completely roll our own core validation engine, for only doing HTML checking, rather than making use of a general-purpose schema validation tool at all.

But the fact of the matter is, the grammar-based validation mechanism we are currently using works extremely well for the vast majority of constraint checks that need to be done for the HTML language.

(By the way, what validator.nu is actually using currently is a grammar/schema written in the the RelaxNG schema language, with the Jing validation library used both as the core validation engine for performing checks against that grammar, as well as a means for driving other parts of the backend.)

The script element is absolutely unique within the entire language (and perhaps even unique within the entire set of commonly used markup languages) in that it is the *only* element in the language for which there is a constraint relationship between what kind of text contents the element has -- specifically in this case, whether it's supposed to be an "inline script" or not -- and the attribute model for the element.

So while grammar-based validation clearly does seem to be suboptimal as the frontline means for checking constraints on the script element, it is not clear at all that it's a wrong technology for doing checks on the vast majority of other features of the language. Quite the opposite, really.

And for better or worse, that grammar-based validation mechanism is currently the core technology on which the entire validator.nu backend is based. And it does not seem like we would get a very good return on investment by making major changes to it that are going to be useful on for this one case (which is what we'd probably need to do). 

Over at bug 452, I just now wrote a long response with a lot more details:

http://bugzilla.validator.nu/show_bug.cgi?id=452#c5

So please see that if you want to know the nitty gritty.

To repeat just the first part of what I said over there -

The current error reporting for this case is a compromise between the need to
report something as useful as possible to authors for this case, and the need
to keep "special case" handling in the validation backend to a minimum -- and
to not add significant additional complexity to the backend unless
what it's buying us is clearly worth it in terms of the implementation and
maintenance costs. 

I also want to say that validation is not meant as a complete substitute for
people actually reading the spec or for actually reading some other document that
explains the complexities of the language, and in particular of the script element. 

This case is a perhaps a case where people are arguably going to be better off
ultimately if they do read and understand the constraints in this part of the
spec -- or read some guide that explains them well.

And arguably, despite any more effort that we put into finessing the reporting
around this is, it is still going to be confusing to anybody who has not yet read
and understood those constraints.

Zack,


I've checked in a fix for this bug that causes the validator to emit the
following message instead:

"Error: Element script must not have attribute defer unless attribute src is
also specified."

You can test it yourself here:

http://www.w3.org/html/check

...and it will get deployed at http://validator.nu/ and http://html5.validator.nu/ soonish