5 ms·

>Remove all ASCII tab or newline from input. the title is referring to inside html attributes, where they will be removed hence not affect where the link point

>Remove all ASCII tab or newline from input. the title is referring to inside html attributes, where they will be removed hence not affect where the link points.

joshuahaglund 7mo ago
Yeah "You can use newline or tab characters in the HREF attribute and the browser will throw a validation error, remove the offending character, try again, then succeed" would be a more accurate title.
- shiomiru 7mo ago
  Validation errors aren't really "exceptions" to be thrown, they are indicators for authors that something is probably wrong but they make no visible difference in the output. I'm not sure if any browser even tracks them (and if one did, the best it could do is complain in the dev tools). Also, this is not limited to HREF, it's defined in URL[0] so you can also put newlines in new URL("...") etc. [0]: https://url.spec.whatwg.org/#concept-basic-url-parser https://url.spec.whatwg.org/#concept-basic-url-parser
  - squeefers 7mo ago
    [dead]
- ossisjxish 7mo ago
  [dead]
locknitpicker 7mo ago
> the title is referring to inside html attributes, where they will be removed hence not affect where the link points. I thought so too, until I read the URL definition in RFC 1738 In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may need to be added to break long URLs across lines. The whitespace should be ignored when extracting the URL. No whitespace should be introduced after a hyphen ("-") character. Because some typesetters and printers may (erroneously) introduce a hyphen at the end of line when breaking a line, the interpreter of a URL containing a line break immediately after a hyphen should ignore all unencoded whitespace around the line break, and should be aware that the hyphen may or may not actually be part of the URL.
- johneth 7mo ago
  RFC 1738 was superseded by RFC 3986 (URIs) 19 years ago, and the URL Living Standard.
  - wpollock 6mo ago
    > RFC 1738 was superseded by RFC 3986 (URIs) ... RFC 3986 has the same wording (appendex C), <https://datatracker.ietf.org/doc/html/rfc3986#appendix-C https://datatracker.ietf.org/doc/html/rfc3986#appendix-C>.
chrismorgan 7mo ago
HTML doesn’t remove whitespace from quoted attribute values. XML replaces such things with a single space, but HTML leaves it intact. (If you want actual tabs and newlines in XML or an HTML/XML polyglot—which can be reasonable, seen for example in the HTML title attribute—you have to encode them as and or similar.) So no, this does boil down to the behaviour quoted from the URL Standard.
netsharc 7mo ago
The "professor of Computer Science" seems to be confusing URLs and the textual representation of a URL inside HTML. Considering he wrote on his blog that he "ranks among the top 2% of scientists globally", I'm guessing he's more of a Trumpesque personality, another "very stable genius".
- sgarland 7mo ago
  He is a bit full of himself, but if you read some of his other work, he’s done some incredible work making fast code. Lots of SIMD, some novel algorithms, etc.

>Remove all ASCII tab or newline from input. the title is referring to inside html attributes, where they will be removed hence not affect where the link points.

joshuahaglund 7mo ago

Yeah "You can use newline or tab characters in the HREF attribute and the browser will throw a validation error, remove the offending character, try again, then succeed" would be a more accurate title.

shiomiru 7mo ago
Validation errors aren't really "exceptions" to be thrown, they are indicators for authors that something is probably wrong but they make no visible difference in the output. I'm not sure if any browser even tracks them (and if one did, the best it could do is complain in the dev tools). Also, this is not limited to HREF, it's defined in URL[0] so you can also put newlines in new URL("...") etc. [0]: https://url.spec.whatwg.org/#concept-basic-url-parser https://url.spec.whatwg.org/#concept-basic-url-parser
- squeefers 7mo ago
  [dead]
ossisjxish 7mo ago
[dead]

locknitpicker 7mo ago

> the title is referring to inside html attributes, where they will be removed hence not affect where the link points. I thought so too, until I read the URL definition in RFC 1738 In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may need to be added to break long URLs across lines. The whitespace should be ignored when extracting the URL. No whitespace should be introduced after a hyphen ("-") character. Because some typesetters and printers may (erroneously) introduce a hyphen at the end of line when breaking a line, the interpreter of a URL containing a line break immediately after a hyphen should ignore all unencoded whitespace around the line break, and should be aware that the hyphen may or may not actually be part of the URL.

johneth 7mo ago
RFC 1738 was superseded by RFC 3986 (URIs) 19 years ago, and the URL Living Standard.
- wpollock 6mo ago
  > RFC 1738 was superseded by RFC 3986 (URIs) ... RFC 3986 has the same wording (appendex C), <https://datatracker.ietf.org/doc/html/rfc3986#appendix-C https://datatracker.ietf.org/doc/html/rfc3986#appendix-C>.

chrismorgan 7mo ago

HTML doesn’t remove whitespace from quoted attribute values. XML replaces such things with a single space, but HTML leaves it intact. (If you want actual tabs and newlines in XML or an HTML/XML polyglot—which can be reasonable, seen for example in the HTML title attribute—you have to encode them as and or similar.) So no, this does boil down to the behaviour quoted from the URL Standard.

netsharc 7mo ago

The "professor of Computer Science" seems to be confusing URLs and the textual representation of a URL inside HTML. Considering he wrote on his blog that he "ranks among the top 2% of scientists globally", I'm guessing he's more of a Trumpesque personality, another "very stable genius".

sgarland 7mo ago
He is a bit full of himself, but if you read some of his other work, he’s done some incredible work making fast code. Lots of SIMD, some novel algorithms, etc.