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.
--
Basically, your link throws a parse error only because of the equals sign that follows. I did some more testing ( http://jsfiddle.net/8b1h3bqw/ ) and noted that Firefox seems to ignore the rules about ampersands in attributes showing a warning even in the valid case. But then, that's also only in view source, which for some reason, I cannot access via the developer tools. Chrome doesn't report any parse errors anywhere as far as I can.
Anyways, it's important because of those legacy user agents only, and then, only if your parameter has the same name as an HTML entity character reference. In all other cases, there's no problem, probably.
Awesome. Just like others have mentioned in comments here; this means that as long as you follow with a = you're fine.
As your example points out; the really big risk is the example of `href="&"` where you might hope that the server is going to pick that up as a {'amp': ''} or something. It won't. Instead you'd get nothing from the query string. It would if it was `href="?ampsomething"` then you could get {'ampsomething': ''} (NB: different servers accept or simply reject CGI params without a =)
Comment
https://html.spec.whatwg.org/multipage/syntax.html#consume-a-character-reference
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.
--
Basically, your link throws a parse error only because of the equals sign that follows. I did some more testing ( http://jsfiddle.net/8b1h3bqw/ ) and noted that Firefox seems to ignore the rules about ampersands in attributes showing a warning even in the valid case. But then, that's also only in view source, which for some reason, I cannot access via the developer tools. Chrome doesn't report any parse errors anywhere as far as I can.
Anyways, it's important because of those legacy user agents only, and then, only if your parameter has the same name as an HTML entity character reference. In all other cases, there's no problem, probably.
Replies
Awesome. Just like others have mentioned in comments here; this means that as long as you follow with a = you're fine.
As your example points out; the really big risk is the example of `href="&"` where you might hope that the server is going to pick that up as a {'amp': ''} or something. It won't. Instead you'd get nothing from the query string.
It would if it was `href="?ampsomething"` then you could get {'ampsomething': ''}
(NB: different servers accept or simply reject CGI params without a =)