2013-12-10 19:45, Boris Zbarsky wrote:
On 12/10/13 11:11 AM, Peter Cashin wrote:
The HTML5 spec says that an ambiguous ampersand (e.g. &something;
undefined) is not allowed in element content
Right, that's an authoring requirement.
Authoring requirements as such are just policy statements, therefore
regularly ignored. They are supposed to communicate something, but as
the late prof. Wiio so wisely stated, communication usually fails,
except by accident (and he was an optimist).
There is no throwing of parse errors in the HTML spec.
Well, yes, throwing belongs to the DOM and to scripting. The question is
whether some construct is parsed in a particular way or not.
Is the specification intended to have compliant HTML agents stop
parsing ambiguous ampersands?
Compliant HTML agents are allowed to do so, I guess, per the technical
rules about parse errors, just like for any other parse error. But I
expect that this is at least partly for conformance classes other than
"browsers"; all browsers press on through parse errors in HTML. Maybe
the allowed behavior for parse errors should be made conditional on
conformance class...
Allowing user agents to stop parsing after a parse error (BTW, where
exactly does the WHATWG HTML Living Standard allow that?) is really just
avoidance. If browsers actually apply some specific error recovery,
what’s the excuse for not making that mandatory?
Different user agents can really do very different things. But I don’t
think it’s a good idea to make that a rule of *parsing HTML*.
Yucca
