[css-text] Should word-break property be applied to wrapped line-boxes ? #19903

javifernandez · 2019-10-25T22:56:12Z

Let's consider the following test case (which is extracted from the word-break-break-all-inline-006.html test):

<div style="font-family: monospace; width: 6.1ch;">aaaa<span stylle=" word-break: break-all;">bbbbbbbbbbb</span>ccccc</div>

This DOM implies the generation of 3 inline-boxes, one for each word ('aaaa', 'bbbbbbbbbbb' and 'ccccc'). Before applying the line-breaking rules, all the inline-boxes are contained in a single line-box.

However, when the text is processed according to the word breaking rules the second inline-box (' bbbbbbbbbbb') is broken, honoring the break-all value, and wrapped to the next two lines.

Since the broken text is now contained into new line-boxes, and considering the original inline-box has its own style, I assume two new inline-boxes are created for these pieces of the broken word. The question is whether these new inline-boxes should have a copy of the style rules of the original inline-box.

The behavior of the different browsers differ when loading this test case:

WebKit	Firefox	Chrome	Chrome (legacy)

The expected result currently defined for the word-break-break-all-inline-006.html is the one rendered by WebKit and Chrome, but using the legacy layout engine.

Both Firefox and Chrome fail when running this test, as it's detected by the wpt.fyi bots:

https://wpt.fyi/results/css/css-text/word-break/word-break-break-all-inline-006.html?label=experimental&label=master&aligned

It's worth mentioning that in all the cases, it seems that 'word-break: break-all' is applied to the text in the first and second lines, since the 'bbbbbbbbbbb' is wrapped in 3 different lines. However, in the case of Firefox and Chrome, the last piece of the broken word is part of another clone of the original inline-box, hence, it has also word-break: break-all rule. This fact is what causes the different behavior, since WebKit and Chrome (legacy) seems to consider this last piece of text as not part of the same line than the following word ('ccccc').

I'm not sure what is the correct behavior in this case. I think WebKit and Chrome (legacy) considers that since word-break: break-all doesn't apply to the whole line ('ccccc' inline-box has not that rule in its own style), the text is not broken despite it overflows. However, Chrome and Firefox consider that, since the last 'bbb' text has a breaking opportunity at the end, honoring word-break: break-all, we can take it and avoid the overflow.

I appreciate any feedback on this issues.
Thanks in advance.

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

kojiishi · 2019-10-26T08:32:35Z

I think Gecko and Blink (ng) are correct. We resolved not to define before the last "b" or after, but "c" should not overflow.

jfkthame · 2019-10-26T09:56:53Z

The spec for break-all says that:

Breaking is allowed within “words”: specifically, in addition to soft wrap opportunities allowed for normal, any typographic character units resolving to the NU (“numeric”), AL (“alphabetic”), or SA (“Southeast Asian”) line breaking classes [UAX14] are instead treated as ID (“ideographic characters”) for the purpose of line-breaking.

My interpretation is that in this example, all the b's have the break-all value, so the boundary between the last b and the first c is treated as <ID, AL>, and a break is permitted. It's as if the b's were CJK ideographs.

However, there was debate about this, with the alternative view being that the behavior at the element boundary should be determined by the word-break value of the nearest common ancestor, and for the time being it has been left undefined in CSS. See discussion in w3c/csswg-drafts#3897.

javifernandez · 2019-10-28T08:24:47Z

I have a few additional questions:

1- What does "undefined" exactly means in this case ? is there or now a breaking opportunity after the last 'b' ? I guess the spec needs some edit to clarify this in any case, as the issue #3897 still has the NeedsEdits label.

2- What part of the spec I should take as reference to implement the "but 'c' should not overflow' part ?

3- Is the word-break-break-all-inline-006.html test correctly defined then ?

jfkthame · 2019-10-28T12:59:33Z

I have a few additional questions:

1- What does "undefined" exactly means in this case ? is there or now a breaking opportunity after the last 'b' ? I guess the spec needs some edit to clarify this in any case, as the issue #3897 still has the NeedsEdits label.

I believe the spec is currently unclear, as discussed in w3c/csswg-drafts#3897. By my interpretation of break-all, there is a break opportunity after the last "b", but by the alternative interpretation some people favored, there isn't; and the most recent CSS WG discussion resolved to leave it undefined for now, per w3c/csswg-drafts#3897 (comment).

2- What part of the spec I should take as reference to implement the "but 'c' should not overflow' part ?

https://drafts.csswg.org/css-text-3/#line-breaking says that "the UA must minimize the amount of content overflowing a line by wrapping the line at a soft wrap opportunity, if one exists".

Regardless of the interpretation of word-break:break-all at the edge of the span (which determines whether or not there's a break opportunity after the last "b"), there must be an opportunity between the last two "b"s; by taking this break, the overflow would be avoided. So the test (and the Webkit / legacy Chrome rendering) appears to be incorrect, AFAICS.

So the two arguably-correct results, depending on the undefined issue at the boundary, would be either

aaaabb
bbbbbb
bbb
ccccc

or

aaaabb
bbbbbb
bb
bccccc

3- Is the word-break-break-all-inline-006.html test correctly defined then ?

No, according to my current understanding.

javifernandez · 2019-10-29T14:34:49Z

I agree with @jfkthame on 3 replies, and I think @kojiishi feedback is on the same line. So that implies that we should rewrite, or remove, the word-break-break-all-inline-006.html test.

I'd like to have the opinion of @frivoal as well, though.

The test word-break-break-all-inline-006.html is incorrectly defined, as it was agreed in the corresponding CSS WG issue [1]. This CL changes the expected result of the test and updates the TestExpectations accordingly, since it was failing for LayoutNG before. The new expected result matches current LayoutNG's and Gecko's behavior, but it implies that i fails in legacy and WebKit. [1] #19903 Change-Id: Ia31c89f1a4084607fbb29fd0422354b754a092d2

The test word-break-break-all-inline-006.html is incorrectly defined, as it was agreed in the corresponding CSS WG issue [1]. This CL changes the expected result of the test and updates the TestExpectations accordingly, since it was failing for LayoutNG before. The new expected result matches current LayoutNG's and Gecko's behavior, but it implies that it fails in legacy and WebKit. [1] #19903 Change-Id: Ia31c89f1a4084607fbb29fd0422354b754a092d2

The test word-break-break-all-inline-006.html is incorrectly defined, as it was agreed in the corresponding CSS WG issue [1]. This CL changes the expected result of the test and updates the TestExpectations accordingly, since it was failing for LayoutNG before. The new expected result matches current LayoutNG's and Gecko's behavior, but it implies that it fails in legacy and WebKit. [1] #19903 Change-Id: Ia31c89f1a4084607fbb29fd0422354b754a092d2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1905549 Commit-Queue: Javier Fernandez <jfernandez@igalia.com> Reviewed-by: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#714458}

…ations, a=testonly Automatic update from web-platform-tests [css-text] Fix test and update TestEpectations The test word-break-break-all-inline-006.html is incorrectly defined, as it was agreed in the corresponding CSS WG issue [1]. This CL changes the expected result of the test and updates the TestExpectations accordingly, since it was failing for LayoutNG before. The new expected result matches current LayoutNG's and Gecko's behavior, but it implies that it fails in legacy and WebKit. [1] web-platform-tests/wpt#19903 Change-Id: Ia31c89f1a4084607fbb29fd0422354b754a092d2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1905549 Commit-Queue: Javier Fernandez <jfernandez@igalia.com> Reviewed-by: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#714458} -- wpt-commits: 9db5ee07d16c152bd1b4087c376dd42eca9ac3fd wpt-pr: 20175

…ations, a=testonly Automatic update from web-platform-tests [css-text] Fix test and update TestEpectations The test word-break-break-all-inline-006.html is incorrectly defined, as it was agreed in the corresponding CSS WG issue [1]. This CL changes the expected result of the test and updates the TestExpectations accordingly, since it was failing for LayoutNG before. The new expected result matches current LayoutNG's and Gecko's behavior, but it implies that it fails in legacy and WebKit. [1] web-platform-tests/wpt#19903 Change-Id: Ia31c89f1a4084607fbb29fd0422354b754a092d2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1905549 Commit-Queue: Javier Fernandez <jfernandezigalia.com> Reviewed-by: Koji Ishii <kojiichromium.org> Cr-Commit-Position: refs/heads/master{#714458} -- wpt-commits: 9db5ee07d16c152bd1b4087c376dd42eca9ac3fd wpt-pr: 20175 UltraBlame original commit: eef2b7b1e4c409fcccb2f026286d86de3543d294

frivoal · 2019-12-03T06:19:03Z

Sorry for staying silent this long on this bug.

I agree with #19903 (comment), the two allowed renderings are:

aaaabb
bbbbbb
bbb
ccccc

and

aaaabb
bbbbbb
bb
bccccc

The reftest should be modified to allow both, I'll make a PR.

Closes web-platform-tests#19903

frivoal · 2019-12-03T06:22:23Z

#20576 should solve this.

javifernandez · 2019-12-03T11:55:50Z

I agree on closing this issue thanks to #20576

Closes #19903

javifernandez assigned frivoal, kojiishi and litherum Oct 25, 2019

javifernandez added the css-text label Oct 25, 2019

chromium-wpt-export-bot mentioned this issue Nov 11, 2019

[css-text] Fix test and update TestEpectations #20175

Merged

frivoal added a commit to frivoal/wpt that referenced this issue Dec 3, 2019

[css-text] Allow flexibility where spec is undefined

3364b01

Closes web-platform-tests#19903

frivoal mentioned this issue Dec 3, 2019

[css-text] Allow flexibility where spec is undefined #20576

Merged

frivoal added a commit to frivoal/wpt that referenced this issue Dec 3, 2019

[css-text] Allow flexibility where spec is undefined

fc22b89

Closes web-platform-tests#19903

frivoal closed this as completed in #20576 Dec 3, 2019

frivoal added a commit that referenced this issue Dec 3, 2019

[css-text] Allow flexibility where spec is undefined

fabb1c9

Closes #19903

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-text] Should word-break property be applied to wrapped line-boxes ? #19903

[css-text] Should word-break property be applied to wrapped line-boxes ? #19903

javifernandez commented Oct 25, 2019

kojiishi commented Oct 26, 2019

jfkthame commented Oct 26, 2019

javifernandez commented Oct 28, 2019 •

edited

jfkthame commented Oct 28, 2019

javifernandez commented Oct 29, 2019

frivoal commented Dec 3, 2019

frivoal commented Dec 3, 2019

javifernandez commented Dec 3, 2019

[css-text] Should word-break property be applied to wrapped line-boxes ? #19903

[css-text] Should word-break property be applied to wrapped line-boxes ? #19903

Comments

javifernandez commented Oct 25, 2019

kojiishi commented Oct 26, 2019

jfkthame commented Oct 26, 2019

javifernandez commented Oct 28, 2019 • edited

jfkthame commented Oct 28, 2019

javifernandez commented Oct 29, 2019

frivoal commented Dec 3, 2019

frivoal commented Dec 3, 2019

javifernandez commented Dec 3, 2019

javifernandez commented Oct 28, 2019 •

edited