[css-text] What does the `white-space-collapse` apply to when white-space trimming/positioning #9724

andreubotella · 2023-12-19T10:01:32Z

CSS-TEXT section 4.1.2 talks about the rendering and hanging of spaces in each line, and step 4 talks about whether a sequence of trailing spaces at the end of the line hangs, which depends on the values of white-space-collapse (and text-wrap-mode).

However, when you look at it in detail, it's not clear what value should be used here. This whole section applies to the line as a whole, and a sequence of trailing spaces can span inlines. Should then each preserved space in the sequence of the line's trailing spaces hang or not depending on its white-space-collapse value? This doesn't seem to make sense, since this would allow for some spaces to hang when not at the end of the line, which doesn't seem to make sense, and is not allowed by the definition of hanging.

<div style="white-space-collapse: continue">
foo&x#3000;&x#3000;&x#3000;<span style="white-space-collapse: break-spaces">        </span>
</div>

In this example, if the entirety of the text fits within the line, the ideographic spaces would hang (since they're not collapsed in phase I, so they count as preserved, but they're still white-space-collapse: continue), but the spaces inside the span wouldn't.

Because of this, when fixing hanging in Blink to align with the spec, I understood the white-space-collapse (and text-wrap-mode) values as applying to the line, rather than the spaces. Blink has a concept of a line box's style, which apparently is not in the spec (although I was not aware of that at the time of implementing this), which seems to be the same as the containing block box's computed style (except maybe including ::first-line styles) – and that is what I used in my implementation. This led to differences with other browsers in cases like this:

<div style="white-space-collapse: collapse; text-align: center">
Something.<span style="white-space-collapse: preserve; text-wrap-mode: wrap;">          </span>
</div>

If the relevant white-space-collapse (and text-wrap-mode) values should be those corresponding to each preserved space character, then the trailing spaces inside the span conditionally hang (since this is the last line), and therefore the "Something." text will be off-center (assuming that the text fully fits within the line, whether the spaces do or not). However, if the relevant values should be the containing block box's, then the spaces should hang (unconditionally) and the "Something." text will appear centered.

cc @kojiishi @jfkthame @fantasai @frivoal

The text was updated successfully, but these errors were encountered:

frivoal · 2023-12-20T06:56:46Z

It does apply to the spaces, not the the line or the whole block. white-space-collapse and text-wrap-mode are explicitly defined as applied to text, not to blocks, and that's deliberate.

If towards the end of a line you've got some spaces that cannot hang followed by some spaces that can, then only the ones that can hang get to hang, and the others do not. Similarly, if you've got some non collapsible spaces followed by some collapsible spaces at the end of the line, then step 3 gets rids of the collapsible spaces, and those other non collapsible spaces remain.

If it is the other way around, and you've got a sequence of collapsible spaces followed by a sequence of non collapsible spaces, then the sequence of collapsible spaces aren't at the end of the line (the non-collapsible ones are), and so step 3 doesn't discard them.

Similarly, if you've got some spaces that can hang, followed by some that cannot, then none of them hang, because the spaces at the end of the line aren't hangable, and those that are hangable aren't at the end of the line.

I feel like the case with collapsible and non collapsible isn't even that hard to construct:

<style>
code {
  white-space: pre;
  font-family: monospace; /* not important, just to make it realistic */
  background: lightgray; /* not important, just to make it realistic */
}
</style>
<p>
  In Makefiles, do no confuse sequences of spaces like <code>        </code>
  with tabs like <code>&#9;</code> as they have a different behavior
  even if they look the same.

If the line ends so that there's room for the code element and a little more, but not enough for the next word, then you've got a collapsible space followed by the non collapsible sequence of spaces of the code element, followed by the collapsible space after the code element, at the end of the line. In this case, you remove the collapsible space after the code element, and keep both the non collapsible spaces in the code element (they're not collapsible) and the collapsible space before it (it's not at the end of the line).

I feel like realistic examples with hangable / non hangable spaces are a tad more difficult to construct (at least in English), but the logic is the same.

andreubotella · 2023-12-20T09:55:11Z

If that is the intended reading, the spec should probably clarify that, I think. I'll work on a PR to do that.

andreubotella · 2023-12-20T18:56:31Z

What would happen if a sequence of whitespace that hangs unconditionally is followed by a sequence that hangs conditionally?

frivoal · 2023-12-21T08:21:32Z

What would happen if a sequence of whitespace that hangs unconditionally is followed by a sequence that hangs conditionally?

Same logic? In cases where the condition is met and (all) the conditionally hangable spaces do hang because they didn't fit the line prior to justification, then condition part is fullfilled. The (conditionally) hanging spaces are just hanging spaces, as are the unconditionally hanging spaces at the end of the line, so it's just one big sequence of hanging spaces at the end of the line, and it can hang.

However, if there remains at least one conditionally hangable space at the end of the line which is not hanging because it did fit the line prior to justification, then the sequence of unconditionally hangable spaces aren't actually at the end of the line since there's something in between (a non-hanging space), and thus they don't hang.

andreubotella · 2023-12-22T15:23:45Z

<style>
  div {
    border: 1px solid black;
    text-align: center;
    animation: 5s linear infinite alternate width-animation;
  }
  .unconditional {
    white-space: normal;
    background-color: purple;
    opacity: 0.6;
  }
  .conditional {
    white-space: pre-wrap;
    background-color: orange;
    opacity: 0.6;
  }
</style>

<div><!--
  -->qwertyuiop<!--
  --><span class="unconditional">&#x3000;&#x3000;&#x3000;&#x3000;&#x3000;</span><!--
  --><span class="conditional">             </span><!--
--></div>

I understand that a correct implementation should render this animation, then.

The CL https://crrev.com/c/4881393 changed the hanging space behavior to not depend on `text-align`, and it updated the implementation to match the spec text. However, that patch had a misunderstanding of the spec that made each line's hanging space behavior depend on its block container's styles, rather than on each space's inline item styles. That caused incompatibilities with other browsers. This patch makes this behavior dependent on the inline item styles, thus fixing the main source of incompatibilities. The spec text is not yet fully clear on the behavior of some edge cases, which is why the WPT tests this CL adds are marked as tentative. See w3c/csswg-drafts#9724 for the CSSWG issue discussing this. Bug: 40944859 Change-Id: Ib93d0ffe41a8c538c8a4c9a13838bc304c26b30e

The CL https://crrev.com/c/4881393 changed the hanging space behavior to not depend on `text-align`, and it updated the implementation to match the spec text. However, that patch had a misunderstanding of the spec that made each line's hanging space behavior depend on its block container's styles, rather than on each space's inline item styles. That caused incompatibilities with other browsers. This patch makes this behavior dependent on the inline item styles, thus fixing the main source of incompatibilities. The spec text is not yet fully clear on the behavior of some edge cases, which is why the WPT tests this CL adds are marked as tentative. See w3c/csswg-drafts#9724 for the CSSWG issue discussing this. Bug: 40944859 Change-Id: Ib93d0ffe41a8c538c8a4c9a13838bc304c26b30e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5147580 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Andreu Botella <abotella@igalia.com> Cr-Commit-Position: refs/heads/main@{#1273823}

…end on the item's style, a=testonly Automatic update from web-platform-tests Make trailing space hanging behavior depend on the item's style The CL https://crrev.com/c/4881393 changed the hanging space behavior to not depend on `text-align`, and it updated the implementation to match the spec text. However, that patch had a misunderstanding of the spec that made each line's hanging space behavior depend on its block container's styles, rather than on each space's inline item styles. That caused incompatibilities with other browsers. This patch makes this behavior dependent on the inline item styles, thus fixing the main source of incompatibilities. The spec text is not yet fully clear on the behavior of some edge cases, which is why the WPT tests this CL adds are marked as tentative. See w3c/csswg-drafts#9724 for the CSSWG issue discussing this. Bug: 40944859 Change-Id: Ib93d0ffe41a8c538c8a4c9a13838bc304c26b30e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5147580 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Andreu Botella <abotella@igalia.com> Cr-Commit-Position: refs/heads/main@{#1273823} -- wpt-commits: 5f46e7c41541e9f2589ddf79177f113e98944427 wpt-pr: 45105

frivoal · 2024-09-02T07:40:20Z

I agree with the above logic, as well as with the tests introduced in web-platform-tests/wpt#44384.

@fantasai, can you have a look too and see if you agree?

As for the spec

I believe that hanging things followed by non hanging things doesn't need clarification. If they're not at the end of the line, they don't hang, that seems covered.
We might want to clarify the cases where we have both conditionally and unconditionally hanging things at the end of the line. The way I described it and that @andreubotella wrote tests for seems sound to me, but whether it is fully supported by the spec, I'm less sure. We could clarify by adding the following to the last paragraph of 9.2:

When (unconditionally) hanging glyphs at the end of the line are immediately preceded by conditionally hangable glyphs, the condition for whether to hang those glyphs is evaluated as usual, as if the unconditionally hanging glyphs were not there. Conversely When conditionally hangable glyphs at the end of the line are immediately preceded by (unconditionally) hangable glyphs, the unconditionally hangable glyphs hang if and only if all subsequent conditionally hangable glyphs do indeed hang; otherwise, the (unconditionally) hangable glyphs are effectively not at the end of the line and do not get to hang.

An alternative interpretation for the last case could be that any sequence of unconditionally hangable glyphs followed conditionally hangable glyphs becomes conditionally hangable as well. Honestly, while I can construct cases where this happens, I'm having a hard time thinking realistic cases where this would matter.

andreubotella added css-text-3 Current Work css-text-4 labels Dec 19, 2023

andreubotella mentioned this issue Feb 2, 2024

Mark tests for hanging whitespace across inlines with different styles as normative web-platform-tests/wpt#44384

Open

chromium-wpt-export-bot mentioned this issue Mar 14, 2024

Make trailing space hanging behavior depend on the item's style web-platform-tests/wpt#45105

Merged

frivoal added the Agenda+ label Sep 2, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-text] What does the `white-space-collapse` apply to when white-space trimming/positioning #9724

[css-text] What does the `white-space-collapse` apply to when white-space trimming/positioning #9724

andreubotella commented Dec 19, 2023 •

edited

Loading

frivoal commented Dec 20, 2023

andreubotella commented Dec 20, 2023

andreubotella commented Dec 20, 2023

frivoal commented Dec 21, 2023 •

edited

Loading

andreubotella commented Dec 22, 2023 •

edited

Loading

frivoal commented Sep 2, 2024

[css-text] What does the white-space-collapse apply to when white-space trimming/positioning #9724

[css-text] What does the white-space-collapse apply to when white-space trimming/positioning #9724

Comments

andreubotella commented Dec 19, 2023 • edited Loading

frivoal commented Dec 20, 2023

andreubotella commented Dec 20, 2023

andreubotella commented Dec 20, 2023

frivoal commented Dec 21, 2023 • edited Loading

andreubotella commented Dec 22, 2023 • edited Loading

frivoal commented Sep 2, 2024

[css-text] What does the `white-space-collapse` apply to when white-space trimming/positioning #9724

[css-text] What does the `white-space-collapse` apply to when white-space trimming/positioning #9724

andreubotella commented Dec 19, 2023 •

edited

Loading

frivoal commented Dec 21, 2023 •

edited

Loading

andreubotella commented Dec 22, 2023 •

edited

Loading