[whatwg] Should ambiguous ampersand be a parse error?

[Jukka K. Korpela]

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