Correct and split "How whitespace is handled by HTML, CSS, and in the DOM"

No response

Factual error:

In the "Explanation" subsection of How does CSS process whitespace?, Step 3 is incorrect:

Next, line breaks are converted to spaces[…]

In 4.1.3. Segment Break Transformation Rules of the CSS Text Module, in particular Step 2 and the note at the end of 4.1.3, it is explicitly stated that segment breaks can be removed contextually. This is verified by the following HTML code on Firefox:
```
<h1>你好
 世界！</h1>
<h1>你好 世界！</h1>
```
In the same subsection, Step 5 is incorrect:

And finally, sequences of spaces at the beginning and end of an element are removed[…]

In 4.1.2. Phase II: Trimming and Positioning, Step 1 and 3 shows that spaces are removed not because they're at the start or end of a (block-level) element, but because they appear at the start or end of a line during layout.

Structual issues:

The How does CSS process whitespace? subsection may use a more consistent heading with the subsections that follow, e.g. "Whitespaces in inline formatting contexts", since all the subsections in this section deal with whitespaces in CSS.
The phenomenon described in Spaces in between inline and inline-block elements is merely a special case of "How does CSS process whitespace?", but it is given the most lengthy presence in this section along with an ensuing "Solution" subsection.
This page doesn't mention whitespaces in selections. For the following HTML code:
```
<h1>你好
 世界！</h1>
```
the rendered text is 你好世界！. But when selecting all the visible texts, e.g. pressing Ctrl + A on the page on Windows, getSelection().toString() returns 你好世界！, which is also what gets copied by Ctrl + C on Firefox on Windows (note that the tab is transformed into a space), whereas getSelection().getRangeAt(0).toString() returns 你好\n\t世界！.

The factual errors be corrected.
Split the CSS-related content on this page into a new guide page under CSS.

Note: Most technical details are already covered by the new white-space-collapse page, so only the guide content needs porting to a new page. But it seems more coherent and centralized to also move those technicalities to the new CSS guide page.
Add a section about whitespace on the page of the Selection API.
Crossref these whitespace sections with each other.

I can offer to do the reorganization, but since it's quite a large modification, I'd like to hear some feedback first.

PS: I'd soon be away until mid-August, so the offer will only be effective since mid-August.

mdn / content