"If the character reference is being consumed as..."

[zcorpan]

https://html.spec.whatwg.org/multipage/syntax.html#tokenizing-character-references

If the character reference is being consumed as part of an attribute, and the last character matched is not a U+003B SEMICOLON character (;), and the next character is either a U+003D EQUALS SIGN character (=) or an alphanumeric ASCII character, then, for historical reasons, all the characters that were matched after the U+0026 AMPERSAND character (&) must be unconsumed, and nothing is returned. However, if this next character is in fact a U+003D EQUALS SIGN character (=), then this is a parse error, because some legacy user agents will misinterpret the markup in those cases.

source says

However, if this next character is in fact a U+003D EQUALS SIGN character (=), then this is a
<span>parse error</span>, because some legacy user agents <!-- IE, version 9 and before --> will
misinterpret the markup in those cases.</p> <!-- v2: should make this no longer a conformance
error at some point in the future; revisit in 2015? -->

It's 2015; should we make this no longer a conformance error?

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3744

I kinda think that omitting ; in attributes is confusing and error-prone and should just be a conformance error always. I think the spec's current rules have still not been implemented in validator.nu; the validator is stricter than the spec.

cc @sideshowbarker @hsivonen @Hixie

[sideshowbarker]

I kinda think that omitting ; in attributes is confusing and error-prone and should just be a conformance error always.

I think so too.

I think the spec's current rules have still not been implemented in validator.nu; the validator is stricter than the spec.

Strictly, I think all of this is dealt with in the parser and not in the validator code itself. But that said, I don’t know which particular rules you mean that the validator is handling more strictly than the spec requires. The one case that I am certain of where we are doing that is just that the spec allows the & ampersand character but the parser (and validator) still reports an error for it if it’s not part of a character reference. (tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1153920 and last I talked to @hsivonen about it, it was blocked by some other more fundamental changes that he’s planning to make to the parser).

[zcorpan]

Yeah, I meant the "validator" as in the service as a whole, including the parser.

[domenic]

This appears to have been fixed in 6c629ac.