the title is referring to inside html attributes, where they will be removed hence not affect where the link points.
So no, this does boil down to the behaviour quoted from the URL Standard.
To the point where chrome stopped allowing newlines in some circumstances https://chromestatus.com/feature/5735596811091968
Still, not a bright idea.
[0]: https://sheeptester.github.io/hello-world/test/%20%0A%20%0A/...
“You got URLs in my new lines!”
- Everyone of them gives me a 404, can you kindly add some page on your blog form where I can just see the titles of all the articles quickly?
- Most blogs posted on HN are not user friendly in this regard, sometimes the reader wants a quick glimpse of everything on 1 page so that they can quickly pick interesting stuff
But then I suppose it goes back to the main thrust of the blogpost because it says that in the context of HTML 4 and 5, that linefeeds within an attribute value are ignored. So possibly there are some other contexts where whitespace might not be ignored.
That is not the right mindset to create good things. If it's an error, it's not fine.
He had a blog post that seemed just weird and out of left field. Like it was clearly a response to something but what? What was the motivation for it?
When asked he said y'know. He just thinks about stuff and writes and that's what he does.
Turns out the blog post was a post he also made on social media. And said post was a response to something. And I guess he thought it was pretty good writing and should go on his blog, too.
Nothing wrong with that on it's own but I feel like most people would preface a post like that with "I saw this thing." And when directly asked like... He just straight up lied?
That whole thing just rubbed me the wrong way.
For full context https://lemire.me/blog/2025/10/17/research-results-are-cultu...
In the comments I turned into kind of a dick. I was pretty upset about being lied to.
Anyways between that and articles like this that are honestly useless and kinda misleading - I'm not really the biggest fan.
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.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".
One of the requirement of URLs is that it needs to be transmissible over paper or aural media, so arbitrary octets and the unused portion of ASCII are not legal either.
This seems less like you were being lied to and more like you are kind of being delusional.
I mean listen I understand - I'm not owed anything. If he wants to take posts from elsewhere and share them to his blog with all context and background removed that's his business. And he doesn't have to respond to any comments he doesn't want to.
But if he gets a question he doesn't want to answer... He could just not answer it. Just leave my comment hanging. Hell - he could delete it even. I'd be perplexed but would probably shrug it off.
The whole lying thing is what bothers me. I'd rather somebody just not respond than try to feed me bullshit.
-a person before getting poisoned by pickle juice cereal
Also, this is not limited to HREF, it's defined in URL[0] so you can also put newlines in new URL("...") etc.
And looking at those comments, it's possible he misunderstood the question, but the way he doubled down when OP found and linked the twitter version comes across pretty badly. Even if OP was being rude.
The most generous interpretation I can make is that he missed the "Is this in response to something?" sentence when he first replied, and then when OP came back later with the twitter link he spent zero seconds double checking the context before fighting rude with more rude.
I don't think it's worth holding a grudge over, and OP should drop it, but it does look like he was overall in the wrong there.
FLOCCINAUCINIHILIPILIFICATE /index.html HTTP/1.1
RFC 3986 has the same wording (appendex C), <https://datatracker.ietf.org/doc/html/rfc3986#appendix-C>.
Somwhere after DNS IP and SMTP, but still before HTTP(1.0).
https://www.fileformat.info/info/unicode/char/202b/index.htm

We locate web content using special addresses called URLs. We are all familiar with addresses like https://google.com. Sometimes, URLs can get long and they can become difficult to read. Thus, we might be tempted to format them
like so in HTML using newline and tab characters, like so:
<a href="https://lemire.me/blog/2026/02/21/
how-fast-do-browsers-correct-utf-16-strings/">my blog post</a>
It will work.
Let us refer to the WHATWG URL specification that browsers follow. It makes two statements in sequence.
Notice how it reports an error if there is a tab or newline character, but continues anyway? The specification says that A validation error does not mean that the parser terminates and it encourages systems to report errors somewhere. Effectively, the error is ignored although it might be logged. Thus our HTML is fine in practice.
The following is also fine:
<a href="https://go
ogle.c
om" class="button">Visit Google</a>
You can also use tabs. But you cannot arbitrarily insert any other whitespace.
Yet there are cases when you can use any ASCII whitespace character: data URLs. Data URLs (also called data URIs) embed small files—like images, text, or other content—directly inside a URL string, instead of linking to an external resource. Data URLs are a special kind of URL and they follow different rules.
A typical data URL might look like data:image/png;base64,iVBORw0KGgoAAAANSUhEUg... where the string iVBORw0KGgoAAAANSUhEUg... is the binary data of the image that has been encoded with base64. Base64 is a text format that can represent any binary content: we use 64 ASCII characters so that each character encodes 6 bits. Your binary email attachments are base64 encoded.
On the web, when decoding a base64 string, you ignore all ASCII whitespaces (including the space character itself). Thus you can embed a PNG image in HTML as follows.
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA
QAAAAECAIAAAAmkwkpAAAAEUl
EQVR4nGP8z4AATEhsPBwAM9EB
BzDn4UwAAAAASUVORK5CYII=" />
This HTML code is valid and will insert a tiny image in your page.
But there is more. A data URL can also be used to insert an SVG image. SVG (Scalable Vector Graphics) is an XML-based vector image format that describes 2D graphics using mathematical paths, shapes, and text instead of pixels.
The following should draw a very simple sunset:
<img src='data:image/svg+xml,
<svg width="200" height="200"
xmlns="http://www.w3.org/2000/svg">
<rect width="100%" height="100%" fill="blue" />
<!-- the sky -->
<circle cx="100" cy="110" r="50" fill="yellow" />
<!-- the sun -->
<rect x="0" y="120" width="200" height="80" fill="brown" />
<!-- the ground -->
</svg>' />
Observe how I was able to format the SVG code so that it is readable.
Further reading: Nizipli, Y., & Lemire, D. (2024). Parsing millions of URLs per second. Software: Practice and Experience, 54(5), 744-758.