> So, “ignoring the new line and just assuming it was the same width as a space” is correct behaviour.
That's not true?
If it's a newline following whitespace then it should be ignored; the width should be calculated as zero, not the width of a space.
On the other hand, if it's not following whitespace the width should be that of the newline character, again not the width of a space.
Or am I misunderstanding you?
The article explicitly says the new line width was larger than the space, so I don’t think it’s your second guess.
Your first guess makes perfect sense though, so perhaps that’s what happened. As I said, that was how I had put it together in my mind (regardless of actual fact).
“In HTML, any extra whitespace between words is ignored. This means you can add extra spaces, and even new lines, between words without affecting how they are displayed in the browser”
So, “ignoring the new line and just assuming it was the same width as a space” is correct behaviour.
I now think what happened is this:
- the width of the box to render the text in was computed correctly
- the code that then laid out the text inside that box incorrectly used the width of the newline in the HTML to compute the length of the text, concluded the text was too long to fit on a line, and line-wrapped it inside the box.
That’s not consistent with the claim from the article “and so the box that it made was too small”, though.
Alternatively, the font’s line feed glyph was _less_wide_ than a space, and the width of the box was computed as too small, but then the article is incorrect in that it claims the font’s line feed glyph was _wider_ than a space.
(and for those wondering why a browser needs to compute the width of that text twice: I wouldn’t know, but browser layout engines are complex beasts)