[css-text][css-sizing] When to/not to include preserved trailing spaces #3440
Comments
|
What do you mean by "Not include" vs. "Ignore justify" in the row of Conceptually, |
|
Thank you for asking.
"Not include" mean to ignore trailing spaces and flush the end of non-space character. "Ignore justify" means justification is not applied. For |
This patch matches the behavior of 'text-align' applied to 'white-space: pre-wrap' and when the line wraps to the current engine; do not include for 'justify' but do include for other values. Spec is not clear on this regard. An issue filed at: w3c/csswg-drafts#3440 It turned out that our tests cover the combination of the properties only when lines do not wrap. Because NGLineBreaker computes |has_only_trailing_spaces| as part of the line breaking, the last lines and single lines don't have such item. The difference caused the bug, but the lack of tests prevented finding the problem. This patch adds tests for this case. Also, computing trailing space is moved to NGLineInfo as we discovered it is needed in other cases too, with more cases covered and with unit tests. Bug: 913995 Change-Id: I49428f2dcf193e2b7a745431f82724308a17d90f Reviewed-on: https://chromium-review.googlesource.com/c/1374331 Commit-Queue: Koji Ishii <kojii@chromium.org> Reviewed-by: Emil A Eklund <eae@chromium.org> Cr-Commit-Position: refs/heads/master@{#616617}
|
If the trailing spaces are meant to be preserved, flushing the end of non-space character doesn't sound like the right thing to do? I'm not sure... |
|
The spec currently specifies that trailing spaces are hung (like hanging-punctuation) if Per spec, "hanging" the spaces means they are excluded from the line box--they can overflow it, and therefore are ignored when justifying or end-aligning the text, and are not considered in intrinsic sizing. If a different behavior is wanted, then we'd have to spec something explicitly different. |
|
So IIUC it means:
? Looks logical to me, but it means it requires behavior changes to all impls, and we accept spec/impl diverge for a while until changes are done successfully. Sad for me but ok. |
|
I don't have strong opinion either way, since I don't really have any usecase in mind for this. The general idea explained by @fantasai makes sense to me. I have one question, though. If the trailing spaces are allowed to hang (i.e. not always hang), then I think for If that understanding is correct, then WebKit would be wrong on both |
|
The way I read look different from the way @upsuper read, I think it means there's a room to improve the spec? Also, IIRC at least some of Blink behaviors (e.g., text-align) are from bugs filed by authors. We will need to review those feedback carefully before making the changes. It'd be greater if spec can solve this issue in a way that developers can follow easier. |
|
@upsuper So, let me see if I get this right.... You're suggesting that trailing spaces should be counted for max-content, but not for min-content. You're also suggesting that spaces should hang according to allow-end rules rather than force-end rules. This makes sense to me. But did I get that right? :) |
|
Hm, actually, I think that's not right. Space should hang... when there's a force-break after, but not when there's a soft-wrap after. Is that right? |
where did you get that from? |
Yeah, that seems to match my understanding. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: When to/not to include preserved trailing spaces<dael> github: https://github.com//issues/3440 <dael> fantasai: This was discussion with koji and xidorn with how trailing spaces handled for intrinisic sizing and alignment. xidorn suggested we consider then when counting for max content. For min content b/c trailing spaces don't create overflow or cause wrapping we shouldn't count them. So longest word, not longest work+space controls content <dael> fantasai: Other suggestion was to define spaces hang according to allow-end rules. allow-end if it fits in the line it's not hanging. When you do right alignment it won't go outside. If it doesn't fit we allow it to fit on the line and in that case it's hanging <dael> myles: Changing things about expansion opp. is something the web depends on. Do we have compat? <dael> florian: We don'thave compat <dael> myles: Meaning browsers do different things? <dael> florian: Yes. safari does force-end and others do allow-end for alignment <dael> myles: I don't think we have any philosophical desire so as long as no web compat problem we're willing to change <dael> florian: fantasai your last comment in the issue can you clarify? I'm not sure where that's coming from <dael> fantasai: xidorn confirmed my first comment and not second. I think I was trying to figure out...That question is about handling spaces after a forced break diff then soft break or if they're the same <nigel> q+ to note https://github.com//issues/1997 <dael> fantasai: I think just treating the same is the plan unless someone thinks different <dael> florian: I would think treat the same <dael> fantasai: Obviously they're kind of different when doing [missed] content b/c there is no soft break <fantasai> s/[missed]/max-content/ <dael> florian: For rest of the question I think in terms of taking into account for max content and not min content I initially thought we would ignore in both. If you think in terms of punctuation this proposal makes more sense. Including in max-content is right idea. For alignment I could go either way <dael> fantasai: That's what I was thinking. spaces then text then spaces. If we say hang in general and you wrap halfway throught he text you'd see the beginning spaces but not the end. If you right align we end up hanging them <dael> fantasai: Gonna depend on how they happen to fit. I think proposed behavior is fine <dael> florian: Makes sense. Good argument <dael> astearns: nigel had a point but he's having difficulty being heard <dael> fantasai: If asking about issue #1997 that's about if inline elements interrupt whitespace trimming. whitespace is trimmed when collapsible, but this is when it's not collapsable so it's not really related <dael> astearns: nigel can you indicate on IRC if that makes sense? <nigel> okay, I was just referencing that other issue because it seemed relevant <dael> florian: I am in supprot of proposal. Tests need to be updated but I will do so <dael> astearns: trailing spaces should be counted for max-content but not min-content <nigel> and space allocation at the ends of lines is a big deal for e.g. captions. <dael> astearns: Objections? <dael> RESOLVED: trailing spaces should be counted for max-content but not min-content <dbaron> this is all just *preserved* trailing spaces, right? <dael> astearns: What is next thing to resolve? <florian> dbaron, yes <dael> fantasai: when spaces hang they hand using allow-end behavior rather than force-end <dael> astearns: dbaron has a question on previous and that is correct as far as I understand <dael> fantasai: Yes. <nigel> q- <dael> astearns: Next is when preserved trailing spaces hang they do it using allow-end rather than force-end <dael> RESOLVED: when preserved trailing spaces hang they do it using allow-end rather than force-end <dael> fantasai: Think that's all on this issue |
|
@fantasai thank you for discussing this. Can I ask one clarification on what allow-end means for justification? I'm not sure if I have a good understanding of what "allow-end" behavior is.
There are web pages that use pre-wrap+justify, so I wish to keep the current Blink behavior, but wondering what this means for justify. |
I means that the advance measure of any end-of-line preserved space that would fit the line if text-align was start need to be taken into account and continue to fit within the line with other alignments. those that don't fit the line don't count. gets right aligned as not and gets right aligned as not or For justification specifically, I believe the same logic would apply, so So would get justified as something like not However, currently, it seems to me that browsers just don't justify at all when white-space is pre-wrap, which I believe used to be required by CSS2.1 but no longer is. |
See the table at the original comment, Blink and WebKit does justify. There were bugs filed against us when we included trailing spaces in pre-wrap+justify, because the reporter used pre-wrap+justify for the whole content (probably to make double-spacing at the end of sentence easier.) Can we special case justify, because including trailing spaces does not look reasonable result if browsers chose to justify pre-wrap? |
|
I'm not opposed, but am a little confused at to what the use case is for using pre-wrap and using justify at the same time, so I don't really know what authors would expect. |
Is that the only use case we know of, or are there others? |
|
Hm, how is pre-wrap different from normal? When authors don't need whitespace collapsing, pre-wrap looks reasonable choice for normal documents. For example, this page uses BTW, forgot to say thank you for making pictures that are very easy to understand. That helped me a lot to understand what "allow-end" means in this context. |
|
Other than the effect on line-breaks and tabs in the source, pre-wrap will also preserve the (single) space between each word at the end of the line, which normal won't do. That can already be observed if you underline the text. With normal, the end of line space is gone, so it is not underlined, but with pre-wrap it is there, so it is underlined. This sort of things makes me think that using pre-wrap for long form text is probably not ideal. pre-wrap on editable areas does make sense, but these are rarely justified, I think? Anyway, I am not strongly opposed, but the argument that line start and line end should be symetrical, and that we should be consistent with other types of alignments also makes sense to me. Since this is more about an exception to the general rule than disagreement about the general rule, I think we should probably open a new issue. |
|
Screenshot of @fantasai 's edited version of @faceless2 's test:
|
|
@fantasai and @kojiishi trying to clarify the definition of the terminologies together. Given the definition:
Then "Include" in the original table is exactly the same as "allow-hang" and "Don't include" is "forced-hang".
For Latest WG resolution (and @frivoal's proposal) is to match WebKit for lines that end in a soft wrap. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<emilio> topic: [css-text][css-sizing] When to/not to include preserved trailing spaces<emilio> github: https://github.com//issues/3440#issuecomment-530702998 <emilio> fantasai: [summarizes situation] <emilio> fantasai: proposal is to accept the proposal in https://github.com//issues/3440#issuecomment-530702998 <emilio> ... I think we should agenda <emilio> s/agenda/resolve on that/ <emilio> florian: I think koji is ok with it now <emilio> Rossen_: objections? <emilio> RESOLVED: Accept the proposal in https://github.com//issues/3440#issuecomment-530702998 |
Automatic update from web-platform-tests [css-text] Fix tests to match w3c/csswg-drafts#3440 -- [css-text] Add test based on w3c/csswg-drafts#4359 -- [css-text] Add tests based on spec examples -- wpt-commits: 65da2c8a6c6c4f93cae73034a2cbca9bde7413e0, 63d4c5cecaa8a5ae1f5b206e009f1c8e63c06eca, a6d00e0865b86f9440f0e079a7324a8eefa752ad wpt-pr: 19286
Automatic update from web-platform-tests [css-text] Fix tests to match w3c/csswg-drafts#3440 -- [css-text] Add test based on w3c/csswg-drafts#4359 -- [css-text] Add tests based on spec examples -- wpt-commits: 65da2c8a6c6c4f93cae73034a2cbca9bde7413e0, 63d4c5cecaa8a5ae1f5b206e009f1c8e63c06eca, a6d00e0865b86f9440f0e079a7324a8eefa752ad wpt-pr: 19286
Automatic update from web-platform-tests [css-text] Fix tests to match w3c/csswg-drafts#3440 -- [css-text] Add test based on w3c/csswg-drafts#4359 -- [css-text] Add tests based on spec examples -- wpt-commits: 65da2c8a6c6c4f93cae73034a2cbca9bde7413e0, 63d4c5cecaa8a5ae1f5b206e009f1c8e63c06eca, a6d00e0865b86f9440f0e079a7324a8eefa752ad wpt-pr: 19286 UltraBlame original commit: 847735988761b61a9301709d6588fbfab52f2358
Automatic update from web-platform-tests [css-text] Fix tests to match w3c/csswg-drafts#3440 -- [css-text] Add test based on w3c/csswg-drafts#4359 -- [css-text] Add tests based on spec examples -- wpt-commits: 65da2c8a6c6c4f93cae73034a2cbca9bde7413e0, 63d4c5cecaa8a5ae1f5b206e009f1c8e63c06eca, a6d00e0865b86f9440f0e079a7324a8eefa752ad wpt-pr: 19286 UltraBlame original commit: 847735988761b61a9301709d6588fbfab52f2358
Automatic update from web-platform-tests [css-text] Fix tests to match w3c/csswg-drafts#3440 -- [css-text] Add test based on w3c/csswg-drafts#4359 -- [css-text] Add tests based on spec examples -- wpt-commits: 65da2c8a6c6c4f93cae73034a2cbca9bde7413e0, 63d4c5cecaa8a5ae1f5b206e009f1c8e63c06eca, a6d00e0865b86f9440f0e079a7324a8eefa752ad wpt-pr: 19286 UltraBlame original commit: 847735988761b61a9301709d6588fbfab52f2358
The NGLineInfo class has an attribute hang_width_ to store the width of the preserved trailing spaces. Theoretically, this value is intended to be used during text alignment, following the rules discussed and resolved in the CSS WG issue 3440 [1]. In this issue it's been discussed how to handle end-of-line pre-wrap spaces, which may hang and could affect the final result of the text alignment. However, we also use the NGLineInfo's attribute to compute the line box's inline size, as part of the NGInlineLayoutAlgorithm::CreateLine logic. Since we ignore the hanging spaces when using 'center' alignment, we don't compute it; this leads to an incorrect inline size of the fist line in the test case described in the bug 782638, which incorrectly overflows the box's fixed size, causing the scrollbar to be activated when it shouldn't. Since we always compute the hang_width now, we need to consider it also in the case of RTL scenarios, where we were assuming it was ignored depending on certain values of the text alignment. In order to avoid regressions, this CL also simplifies the line_box's inline_size computation performed in the CreateLine function, ignoring for now the text direction, we always subtract the hang_width Then, the inclusion or not of the hang_width will be decided where it should; the function NGInlineLayoutAlgorithm::ApplyTextAlign is the one responsible of implementing the rules agreed in the CSS WG issue mentioned before. w3c/csswg-drafts#3440 Bug: 782638, 1278559 Change-Id: Ib1950533169fb9cabc6b7bb9e6925451eff2a767
The NGLineInfo class has an attribute hang_width_ to store the width of the preserved trailing spaces. Theoretically, this value is intended to be used during text alignment, following the rules discussed and resolved in the CSS WG issue 3440 [1]. In this issue it's been discussed how to handle end-of-line pre-wrap spaces, which may hang and could affect the final result of the text alignment. However, we also use the NGLineInfo's attribute to compute the line box's inline size, as part of the NGInlineLayoutAlgorithm::CreateLine logic. Since we ignore the hanging spaces when using 'center' alignment, we don't compute it; this leads to an incorrect inline size of the fist line in the test case described in the bug 782638, which incorrectly overflows the box's fixed size, causing the scrollbar to be activated when it shouldn't. Since we always compute the hang_width now, we need to consider it also in the case of RTL scenarios, where we were assuming it was ignored depending on certain values of the text alignment. In order to avoid regressions, this CL also simplifies the line_box's inline_size computation performed in the CreateLine function, ignoring for now the text direction, we always subtract the hang_width Then, the inclusion or not of the hang_width will be decided where it should; the function NGInlineLayoutAlgorithm::ApplyTextAlign is the one responsible of implementing the rules agreed in the CSS WG issue mentioned before. w3c/csswg-drafts#3440 Bug: 782638, 1278559 Change-Id: Ib1950533169fb9cabc6b7bb9e6925451eff2a767
The NGLineInfo class has an attribute hang_width_ to store the width of the preserved trailing spaces. Theoretically, this value is intended to be used during text alignment, following the rules discussed and resolved in the CSS WG issue 3440 [1]. In this issue it's been discussed how to handle end-of-line pre-wrap spaces, which may hang and could affect the final result of the text alignment. However, we also use the NGLineInfo's attribute to compute the line box's inline size, as part of the NGInlineLayoutAlgorithm::CreateLine logic. Since we ignore the hanging spaces when using 'center' alignment, we don't compute it; this leads to an incorrect inline size of the fist line in the test case described in the bug 782638, which incorrectly overflows the box's fixed size, causing the scrollbar to be activated when it shouldn't. Since we always compute the hang_width now, we need to consider it also in the case of RTL scenarios, where we were assuming it was ignored depending on certain values of the text alignment. In order to avoid regressions, this CL also simplifies the line_box's inline_size computation performed in the CreateLine function, ignoring for now the text direction, we always subtract the hang_width Then, the inclusion or not of the hang_width will be decided where it should; the function NGInlineLayoutAlgorithm::ApplyTextAlign is the one responsible of implementing the rules agreed in the CSS WG issue mentioned before. w3c/csswg-drafts#3440 Bug: 782638, 1278559 Change-Id: Ib1950533169fb9cabc6b7bb9e6925451eff2a767
The NGLineInfo class has an attribute hang_width_ to store the width of the preserved trailing spaces. Theoretically, this value is intended to be used during text alignment, following the rules discussed and resolved in the CSS WG issue 3440 [1]. In this issue it's been discussed how to handle end-of-line pre-wrap spaces, which may hang and could affect the final result of the text alignment. However, we also use the NGLineInfo's attribute to compute the line box's inline size, as part of the NGInlineLayoutAlgorithm::CreateLine logic. Since we ignore the hanging spaces when using 'center' alignment, we don't compute it; this leads to an incorrect inline size of the fist line in the test case described in the bug 782638, which incorrectly overflows the box's fixed size, causing the scrollbar to be activated when it shouldn't. Since we always compute the hang_width now, we need to consider it also in the case of RTL scenarios, where we were assuming it was ignored depending on certain values of the text alignment. In order to avoid regressions, this CL also simplifies the line_box's inline_size computation performed in the CreateLine function, ignoring for now the text direction, we always subtract the hang_width Then, the inclusion or not of the hang_width will be decided where it should; the function NGInlineLayoutAlgorithm::ApplyTextAlign is the one responsible of implementing the rules agreed in the CSS WG issue mentioned before. w3c/csswg-drafts#3440 Bug: 782638, 1278559 Change-Id: Ib1950533169fb9cabc6b7bb9e6925451eff2a767 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3360876 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Javier Fernandez <jfernandez@igalia.com> Cr-Commit-Position: refs/heads/main@{#961084}
The NGLineInfo class has an attribute hang_width_ to store the width of the preserved trailing spaces. Theoretically, this value is intended to be used during text alignment, following the rules discussed and resolved in the CSS WG issue 3440 [1]. In this issue it's been discussed how to handle end-of-line pre-wrap spaces, which may hang and could affect the final result of the text alignment. However, we also use the NGLineInfo's attribute to compute the line box's inline size, as part of the NGInlineLayoutAlgorithm::CreateLine logic. Since we ignore the hanging spaces when using 'center' alignment, we don't compute it; this leads to an incorrect inline size of the fist line in the test case described in the bug 782638, which incorrectly overflows the box's fixed size, causing the scrollbar to be activated when it shouldn't. Since we always compute the hang_width now, we need to consider it also in the case of RTL scenarios, where we were assuming it was ignored depending on certain values of the text alignment. In order to avoid regressions, this CL also simplifies the line_box's inline_size computation performed in the CreateLine function, ignoring for now the text direction, we always subtract the hang_width Then, the inclusion or not of the hang_width will be decided where it should; the function NGInlineLayoutAlgorithm::ApplyTextAlign is the one responsible of implementing the rules agreed in the CSS WG issue mentioned before. w3c/csswg-drafts#3440 Bug: 782638, 1278559 Change-Id: Ib1950533169fb9cabc6b7bb9e6925451eff2a767 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3360876 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Javier Fernandez <jfernandez@igalia.com> Cr-Commit-Position: refs/heads/main@{#961084}
The NGLineInfo class has an attribute hang_width_ to store the width of the preserved trailing spaces. Theoretically, this value is intended to be used during text alignment, following the rules discussed and resolved in the CSS WG issue 3440 [1]. In this issue it's been discussed how to handle end-of-line pre-wrap spaces, which may hang and could affect the final result of the text alignment. However, we also use the NGLineInfo's attribute to compute the line box's inline size, as part of the NGInlineLayoutAlgorithm::CreateLine logic. Since we ignore the hanging spaces when using 'center' alignment, we don't compute it; this leads to an incorrect inline size of the fist line in the test case described in the bug 782638, which incorrectly overflows the box's fixed size, causing the scrollbar to be activated when it shouldn't. Since we always compute the hang_width now, we need to consider it also in the case of RTL scenarios, where we were assuming it was ignored depending on certain values of the text alignment. In order to avoid regressions, this CL also simplifies the line_box's inline_size computation performed in the CreateLine function, ignoring for now the text direction, we always subtract the hang_width Then, the inclusion or not of the hang_width will be decided where it should; the function NGInlineLayoutAlgorithm::ApplyTextAlign is the one responsible of implementing the rules agreed in the CSS WG issue mentioned before. w3c/csswg-drafts#3440 Bug: 782638, 1278559 Change-Id: Ib1950533169fb9cabc6b7bb9e6925451eff2a767 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3360876 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Javier Fernandez <jfernandez@igalia.com> Cr-Commit-Position: refs/heads/main@{#961084}
…f ignored in text alignment, a=testonly Automatic update from web-platform-tests Compute the NGLineInfo hang_width even if ignored in text alignment The NGLineInfo class has an attribute hang_width_ to store the width of the preserved trailing spaces. Theoretically, this value is intended to be used during text alignment, following the rules discussed and resolved in the CSS WG issue 3440 [1]. In this issue it's been discussed how to handle end-of-line pre-wrap spaces, which may hang and could affect the final result of the text alignment. However, we also use the NGLineInfo's attribute to compute the line box's inline size, as part of the NGInlineLayoutAlgorithm::CreateLine logic. Since we ignore the hanging spaces when using 'center' alignment, we don't compute it; this leads to an incorrect inline size of the fist line in the test case described in the bug 782638, which incorrectly overflows the box's fixed size, causing the scrollbar to be activated when it shouldn't. Since we always compute the hang_width now, we need to consider it also in the case of RTL scenarios, where we were assuming it was ignored depending on certain values of the text alignment. In order to avoid regressions, this CL also simplifies the line_box's inline_size computation performed in the CreateLine function, ignoring for now the text direction, we always subtract the hang_width Then, the inclusion or not of the hang_width will be decided where it should; the function NGInlineLayoutAlgorithm::ApplyTextAlign is the one responsible of implementing the rules agreed in the CSS WG issue mentioned before. w3c/csswg-drafts#3440 Bug: 782638, 1278559 Change-Id: Ib1950533169fb9cabc6b7bb9e6925451eff2a767 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3360876 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Javier Fernandez <jfernandez@igalia.com> Cr-Commit-Position: refs/heads/main@{#961084} -- wpt-commits: e5cfd27e4a082ec75151f98f2ffcc99376b656e8 wpt-pr: 32444
…f ignored in text alignment, a=testonly Automatic update from web-platform-tests Compute the NGLineInfo hang_width even if ignored in text alignment The NGLineInfo class has an attribute hang_width_ to store the width of the preserved trailing spaces. Theoretically, this value is intended to be used during text alignment, following the rules discussed and resolved in the CSS WG issue 3440 [1]. In this issue it's been discussed how to handle end-of-line pre-wrap spaces, which may hang and could affect the final result of the text alignment. However, we also use the NGLineInfo's attribute to compute the line box's inline size, as part of the NGInlineLayoutAlgorithm::CreateLine logic. Since we ignore the hanging spaces when using 'center' alignment, we don't compute it; this leads to an incorrect inline size of the fist line in the test case described in the bug 782638, which incorrectly overflows the box's fixed size, causing the scrollbar to be activated when it shouldn't. Since we always compute the hang_width now, we need to consider it also in the case of RTL scenarios, where we were assuming it was ignored depending on certain values of the text alignment. In order to avoid regressions, this CL also simplifies the line_box's inline_size computation performed in the CreateLine function, ignoring for now the text direction, we always subtract the hang_width Then, the inclusion or not of the hang_width will be decided where it should; the function NGInlineLayoutAlgorithm::ApplyTextAlign is the one responsible of implementing the rules agreed in the CSS WG issue mentioned before. w3c/csswg-drafts#3440 Bug: 782638, 1278559 Change-Id: Ib1950533169fb9cabc6b7bb9e6925451eff2a767 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3360876 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Javier Fernandez <jfernandez@igalia.com> Cr-Commit-Position: refs/heads/main@{#961084} -- wpt-commits: e5cfd27e4a082ec75151f98f2ffcc99376b656e8 wpt-pr: 32444
The NGLineInfo class has an attribute hang_width_ to store the width of the preserved trailing spaces. Theoretically, this value is intended to be used during text alignment, following the rules discussed and resolved in the CSS WG issue 3440 [1]. In this issue it's been discussed how to handle end-of-line pre-wrap spaces, which may hang and could affect the final result of the text alignment. However, we also use the NGLineInfo's attribute to compute the line box's inline size, as part of the NGInlineLayoutAlgorithm::CreateLine logic. Since we ignore the hanging spaces when using 'center' alignment, we don't compute it; this leads to an incorrect inline size of the fist line in the test case described in the bug 782638, which incorrectly overflows the box's fixed size, causing the scrollbar to be activated when it shouldn't. Since we always compute the hang_width now, we need to consider it also in the case of RTL scenarios, where we were assuming it was ignored depending on certain values of the text alignment. In order to avoid regressions, this CL also simplifies the line_box's inline_size computation performed in the CreateLine function, ignoring for now the text direction, we always subtract the hang_width Then, the inclusion or not of the hang_width will be decided where it should; the function NGInlineLayoutAlgorithm::ApplyTextAlign is the one responsible of implementing the rules agreed in the CSS WG issue mentioned before. w3c/csswg-drafts#3440 Bug: 782638, 1278559 Change-Id: Ib1950533169fb9cabc6b7bb9e6925451eff2a767 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3360876 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Javier Fernandez <jfernandez@igalia.com> Cr-Commit-Position: refs/heads/main@{#961084} NOKEYCHECK=True GitOrigin-RevId: d25278e042f70c5680264da944e1f296468687d2
In Chromium's current behavior, whether preserved trailing whitespace will hang, in white-space modes that allow wrapping, depends on the text alignment of that line. This, however, was discussed at length in the CSSWG [1], and the conclusion of that was that how trailing spaces hang depends on the `white-space` value, on whether the line ends with a forced break, and for conditional hang [2] on how much of that trailing space width overflows the line; not on `text-align`. Firefox and Webkit seem to follow the current spec on that. This CL updates Chromium to implement this behavior, with a stable feature flag to serve as a killswitch just in case. With it, `NGLineInfo::HangWidth()` returns the width that actually hangs (which for conditional hanging is the width of trailing spaces that overflow the line), and `NGLineInfo::WidthForAlignment()` always subtracts this hanging width. Assuming no regressions, when this killswitch flag is removed it will make the methods `NGLineInfo::ShouldHangTrailingSpaces()` and `NGLineInfo::HangWidthForAlignment()` useless and it will let us remove them. Furthermore, we could simplify line offset adjustment, replacing `NGInlineLayoutAlgorithm::AdjustLineOffsetForHanging` with an inline conditional in the `CreateLine` method. [1]. w3c/csswg-drafts#3440 [2]. https://drafts.csswg.org/css-text-4/#conditionally-hang Bug: 1363901 Change-Id: Ie544b2ff0ea81b8effeb1de6c7f7b496b05cc9e5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4881393 Commit-Queue: Andreu Botella <abotella@igalia.com> Reviewed-by: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/main@{#1203855}
We found browsers are inconsistent on the topic on
pre-wrap.prealways include trailing spaces.text-align: starttext-align: end / centertext-align: justifymin-contentmax-contentCan we define these? Are there more cases we should cover?
Note: table updated on June 2, 2019.
text-align: leftadded, and some values updated. Changes maybe from inaccurate old tests, or browsers updated, not sure.The text was updated successfully, but these errors were encountered: