[css-text] Clarification on the trimming and positioning of whitespace

[yarusome]

In 4.1.2. Phase II: Trimming and Positioning:

Then, the entire block is rendered. Inlines are laid out,[…] and wrapping as specified by the white-space property. As each line is laid out,
[…]
3. A sequence of collapsible spaces at the end of a line is removed,[…]

Given the above procedure, the markup:

<style>div {
  border: solid;
  font-family: monospace;
  width: 1ch;
}</style>
<div>a b</div>

would first have <div> broken into two lines: a (a followed by a space) and b, then the space would be removed.

However, removing the space:

1. is clearly different from what UAs currently do;

2. is contradictory to UAX #14;

3. renders the first case in Step 4 in 4.1.2. Phase II: Trimming and Positioning unreachable:

   If white-space is set to normal, nowrap, or pre-line, the UA must hang this sequence (unconditionally).

So what's the correct interpretation of Step 3?

[frivoal]

is clearly different from what UAs currently do;

How so? It seems to me that it is excatly what UAs are doing. What difference are you seeing?

is contradictory to UAX #14;

• How so? UAX 14 calls for "any number of space characters are kept together invisibly on the previous line and the first non-space character starts the next line." UAX14 in general does not speak of dropping characters, but wow is the call to keeping them invisibly observably different from what we are saying in css-text?
• css-text uses UAX 14 as a starting point, but deliberately diverges in a few occasions when needed. The spec calls for "adherence to normative requirements of the Unicode Core Standard, except where explicitly overridden by CSS".

renders the first case in Step 4 in 4.1.2. Phase II: Trimming and Positioning unreachable:

If white-space is set to normal, nowrap, or pre-line, the UA must hang this sequence (unconditionally).

It is not unreachable: if you look in context, "this sequence" refers to “any sequence of white space, other space separators, and/or preserved tabs”.

"Other spaces separators" are defined to be “all characters in the Unicode general category Zs except space (U+0020) and no-break space (U+00A0)”. So, for instance U+3000 IDEOGRAPHIC SPACE.

So if you have a line under white-space: normal that ends with U+0020 (a collapsible space) followed by U+3000 (an "other spaces separator"), then:

• the U+0020 is not removed, as we do not have "A sequence of collapsible spaces at the end of a line": there's something after it (an U+3000)
• there remains a sequence of "white space, other space separators[…]" (the U+0020 U+3000 sequence) at the end of the line, which must then hang.

[yarusome]

What I was trying to say is that UAs hang the space instead of removing it, and removing it in Step 3 leaves no space to hang in my example (assuming the line breaking there is correct).

About the unreachability: It was indeed by my ignorance of other space characters. 🙏

---

Update: It seems that my understanding of at least one of the words "line", "wrap" and "remove" is different from what the spec text tries to convey.

[frivoal]

This is a very nuanced part of the specification, so it is somewhat hard to understand. If you continue to think that something is wrong somewhere, I'd appreciate if you could provide a test case highlighting the specific thing you're after.

[yarusome]

Background: I've been working on mdn/content#28268, and found this part of the spec appears to say something different than I thought.

After (finally) finding and reading 2. Inline Layout Model from CSS Inline Layout, I think Step 3 should instead be something like:

A sequence of collapsible spaces at the end of an inline formatting context is removed.

[frivoal]

I think Step 3 should instead be something like:

A sequence of collapsible spaces at the end of an inline formatting context is removed.

I don't think so? That would be different from removing at the end of every line, which is what is intended.

Before proposing fixes the spec text, can you show be an example of code where you expect a different behavior? I am not sure what you are trying to fix.