Packages: [HTML] Allow ampersand (&) inside URLs

Created on 23 May 2016 · 6Comments · Source: sublimehq/Packages

This issue is still in Build 3114, verified on OS X and Linux, and I assume it exists on Windows as well.

The ampersand & character is scoped as invalid.illegal.bad-ampersand.html if it is not followed by at least character and a semi-colon ;. The following are all legal:

&amp;
&1;
&q;

However, it is also legal for an ampersand to be included in a URL:

<a href="http://example.com/api?opt=value&opt2=value2">&amp;</a>

(_interesting that Github highlights the above as illegal..._)

and it is highlighted in Sublime as illegal as well:
illegal ampersand

I haven't looked at the syntax def yet, but is there a way to fix this, perhaps when in meta.attribute-with-value.html string.quoted.single|double.html?

bug

Source

MattDMo

Most helpful comment

That is illegal usage. While browsers may "fix" it, according to the spec a & must be the beginning of an entity.

wbond on 23 May 2016

👍2

All 6 comments

That is illegal usage. While browsers may "fix" it, according to the spec a & must be the beginning of an entity.

wbond on 23 May 2016

👍2

Hmm, didn't know that. So how do you write a URL that includes an ampersand in it? Use %26?

MattDMo on 23 May 2016

https://stackoverflow.com/questions/3705591/do-i-encode-ampersands-in-a-href

aziz on 23 May 2016

@aziz Unfortunately, most of the answers there are several years old. I just checked this HTML:

<!DOCTYPE html>
<html>
<head>
    <title>Test Page</title>
</head>
<body>
    <a href="http://example.com/api?opt=value&opt2=value2">&amp;</a>
</body>
</html>

using the W3C Validator with the HTML5 setting, and no errors were raised. Switching to XHTML _did_ raise errors, however. So, it appears the URL is now legal. Maybe?

MattDMo on 23 May 2016

I found a reference to the html5 spec in an issue of the html5 validator that w3c uses: https://github.com/validator/validator/issues/293

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.

Precisely: Because &opt2; is not a valid character reference, the string &opt2= can be considered valid and is supposed to be left unchanged (inside attributes at least).

For comparison, &amp= would be an error. &ampme= would not.

Gotta love webdev.

FichteFoll on 24 May 2016

😄1

As of cd6feeee992e45d985b58f8394f2f18b05cfed62, we no longer mark bare & as invalid in attributes. I chose a simple implementation since the rules aren't trivial and we aren't a validator.

wbond on 18 Aug 2016

👍1

Was this page helpful?

0 / 5 - 0 ratings