[whatwg] Should ambiguous ampersand be a parse error?
Jukka K. Korpela
jkorpela at cs.tut.fi
Tue Dec 10 11:33:18 PST 2013
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*.
More information about the whatwg