interop: Trailing whitespace in h1/h2/.. is removed in chrome, but not firefox

[untitaker]

This document:

<h1>hello world </h1>

is tokenized like so (using html5gum for reference):

StartTag(StartTag { self_closing: false, name: b"h1", attributes: {} })
String(b"hello world ")
EndTag(EndTag { name: b"h1" })
String(b"\n")

...yet chrome does not actually allow you to select a trailing whitespace in such a document.

firefox does. but in its devtools it does not show the trailing whitespace.

which behavior is more correct? The tokenization spec seems to be pretty clear about preserving this extra whitespace (so firefox would be correct), but I don't have the full overview over the spec to know whether the treebuilder might do something with extra whitespace. Also this seems like a pretty basic disagreement across browsers, so I thought it'd be worth discussing in WHATWG.

[domenic]

This is not an interop issue, but instead a user interface choice that Chrome and Firefox have made differently about whether to make text nodes containing trailing whitespace selectable. (Or maybe it is about the \n text node; hard to tell.) Both of them parse the text in the same way, and they are completely consistent in what they expose to script. (I.e., you cannot write a test that outputs different results based on this.)

The tokenization/parser spec, and indeed the HTML spec itself, say nothing about what should happen when the user selects text.

[annevk]

Can you not use getSelection() to get to a difference here? However, might be better filed against https://w3c.github.io/selection-api/.

[untitaker]

I can confirm that getSelection exposes the difference. I filed an issue in selection-api as annevk suggested: w3c/selection-api#149