Interoperability issues in editing/other/join-different-white-space-style-left-paragraph-and-right-line.html

[javifernandez]

The following subtests pass only in Firefox, while Chrome and Safari shows pretty consistent but different behavior:

• external/wpt/editing/other/join-different-white-space-style-left-paragraph-and-right-line.html?method=backspace&left-white-space=nowrap&right-white-space=normal
• external/wpt/editing/other/join-different-white-space-style-left-paragraph-and-right-line.html?method=backspace&left-white-space=pre&right-white-space=normal
• external/wpt/editing/other/join-different-white-space-style-left-paragraph-and-right-line.html?method=backspace&left-white-space=pre-line&right-white-space=normal
• external/wpt/editing/other/join-different-white-space-style-left-paragraph-and-right-line.html?method=backspace&left-white-space=pre-wrap&right-white-space=normal
• external/wpt/editing/other/join-different-white-space-style-left-paragraph-and-right-line.html?method=forwarddelete&left-white-space=nowrap&right-white-space=normal
• external/wpt/editing/other/join-different-white-space-style-left-paragraph-and-right-line.html?method=forwarddelete&left-white-space=pre&right-white-space=normal
• external/wpt/editing/other/join-different-white-space-style-left-paragraph-and-right-line.html?method=forwarddelete&left-white-space=pre-line&right-white-space=normal
• external/wpt/editing/other/join-different-white-space-style-left-paragraph-and-right-line.html?method=forwarddelete&left-white-space=pre-wrap&right-white-space=normal
• external/wpt/editing/other/join-different-white-space-style-left-paragraph-and-right-line.html?method=select-boundary&left-white-space=nowrap&right-white-space=normal
• external/wpt/editing/other/join-different-white-space-style-left-paragraph-and-right-line.html?method=select-boundary&left-white-space=pre&right-white-space=normal
• external/wpt/editing/other/join-different-white-space-style-left-paragraph-and-right-line.html?method=select-boundary&left-white-space=pre-line&right-white-space=normal
• external/wpt/editing/other/join-different-white-space-style-left-paragraph-and-right-line.html?method=select-boundary&left-white-space=pre-wrap&right-white-space=normal

The goal of these subtests is to evaluate how a text node with default white-space value is inserted, as a cosnequence of a "delete" command, into a parent block with a specific and different white-space behavior:

<div id="editor" contenteditable="true"><div style="white-space:nowrap">abc</div>[]def</div>

Expected result (Only Firefox passes)

<div style="white-space:nowrap">abc<span style="white-space: normal">def</span></div>

Chrome and Safari behavior

<div style="white-space:nowrap">abcdef</div>

[zcorpan]

@masayuki-nakano was the difference from Chrome and Safari here intentional?

[masayuki-nakano]

Yeah, losing white-space style does not make sense.

If it's allowed and the new white-space style becomes preserving some spaces, browsers need to drop invisible spaces in the right element. Otherwise, the invisible white-spaces will appear.

If it's allowed and the new white-space style becomes collapsing some spaces, browsers need to normalize the consecutive spaces with NBSPs. Otherwise, some white-spaces will disappear.

However, the cost of scanning white-spaces in the right element may be expensive (e.g., if it's too big). Therefore, preserving the white-space style must be the best.

Actually, Chrome does it if consecutive <span>s have different white-space styles like this:
https://d-toybox.com/studio/lib/input_event_viewer.html?editor=contenteditable&innerHTML=%3Cspan+style%3D%22white-space%3Anormal%22%3Eabc%3C%2Fspan%3E%3Cspan+style%3D%22white-space%3Apre%22%3E%5B%5Dd+++++e%3C%2Fspan%3E&whiteSpace=normal

So, I think the cases were just unexpected by the developers of the builtin editors.

[javifernandez]

cc @dandclark

I also considered a good idea to preserve the original white-space, however, the Chrome reviewer expressed doubts based on what all the browsers do with other CSS properties in similar cases:

Consider other properties like the following:

data:text/html,<div id="editor" contenteditable="true"><div style="font-weight:bold">abc</div>def</div>

In Chromium, Firefox, and Safari, when deleting the newline before the def, the def is merged into the earlier div such that >all have font-weight:bold. But here for white-space we're changing to the opposite behavior where the style on the def is > preserved. What's the reason only white-space should receive this special treatment?

Chrome, Safari and Firefox produce the following DOM when deleting so that "def" goes to the upper line:

<div id="editor" contenteditable="true"><div style="font-weight:bold">abc</div>def</div>

I think the white-space property has some consequences in terms of layout that justify to be treated differently, but I'm not sure we can find anything in either the CSS Text or Editing specs to justify this decision.