Html: Typo in Named Character Reference State Parsing Docs

[DylanYoung]

See https://html.spec.whatwg.org/multipage/parsing.html#named-character-reference-state, "If there is a match..."

I believe it should say "If the character reference was consumed as part of an attribute, and the last character matched is not a U+003B SEMICOLON character (;), and the next input character is eitherneither a U+003D EQUALS SIGN character (=) ornor an ASCII alphanumeric, then, for historical reasons, flush code points consumed as a character reference and switch to the return state."

Unless I'm misreading something. This also seems to be the behaviour in the example as well as in Chrome.

[domenic]

Thanks @DylanYoung. I edited your post to make the edits you are suggesting a bit clearer; in particular currently it says "either/or" but you are proposing it say "neither/nor".

Does anyone from @whatwg/html-parser want to help confirm?

[inikulin]

It is correct as is, otherwise URLs in attributes will be incorrectly parsed as character references, e.g.:

< a href="http://foo.bar/baz&amp=quz"></a>

will be parsed as:

< a href="http://foo.bar/baz&=quz"></a>

[inikulin]

I guess misunderstanding comes from

flush code points consumed as a character reference

which means to flush input characters in the temporary buffer that were processed in the "Named character reference state", not "emit replacement characters" at this point. Temporary buffer is filled with replacement characters in the step 2 of the "Otherwise" branch:

Set the temporary buffer to the empty string. Append one or two characters corresponding to the character reference name (as given by the second column of the named character references table) to the temporary buffer.

[domenic]

Thank you @inikulin! Indeed, following the definition makes it pretty clear. I'll close this, but I'm happy to reopen if there's a proposal for some clarification we could add to the spec text.

[DylanYoung]

Ok, after rereading a few times, I get it. Sorry for the confusion.

I think to clear up the ambiguity, better distinction between the codepoints being parsed and the codepoints that the entity represents could be made.

[domenic]

@DylanYoung would you be interested in proposing a pull request?

[DylanYoung]

I'm still not sure the best way to phrase it (it's quite technical, lol), but I'll think on it for sure!