Repository navigation
[css-text][css-sizing] When to/not to include preserved trailing spaces #3440
Description
We found browsers are inconsistent on the topic on pre-wrap. pre always include trailing spaces.
| Feature | Blink | Edge | Gecko | WebKit |
|---|---|---|---|---|
text-align: start |
Don't include | Don't include | Don't include | Don't include |
text-align: end / center |
Include | Include | Include | Don't include |
text-align: justify |
If !wrap | Do not justify | Do not justify | Do not justify |
min-content |
Don't include | Don't include | Include | Don't include |
max-content |
Include | Include | Include | Include |
Can we define these? Are there more cases we should cover?
Note: table updated on June 2, 2019. text-align: left added, and some values updated. Changes maybe from inaccurate old tests, or browsers updated, not sure.
Activity
upsuper commentedon Dec 13, 2018
What do you mean by "Not include" vs. "Ignore justify" in the row of
text-align: justify?Conceptually,
min-contentshould force trailing spaces to wrap if not !wrap, and in that case they should be counted as one space in size. Is that the behavior of "If !wrap" or "Include", or none of the browsers do this?kojiishi commentedon Dec 13, 2018
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
min-content, !wrap (i.e.,pre) is interoperable, all impls include trailing spaces. When wrap (pre-wrap), the desired behavior is not clear to me. We wrap at spaces, and such trailing spaces are not removed, but 3 impls do not include it when computingmin-content.[LayoutNG] Fix 'text-align' applied to 'white-space: pre-wrap'
upsuper commentedon Dec 16, 2018
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...
fantasai commentedon Dec 18, 2018
The spec currently specifies that trailing spaces are hung (like hanging-punctuation) if
pre-wrapis specified. This is because UAs don't want to wrap the last word down just because there are spaces following it that overflow the containing block. (Spaces are not allowed to hang forpre; they are measured just like any other characters.)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.
fantasai commentedon Jan 23, 2019
@kojiishi @upsuper Did you want something different here or should I close the issue with no change?
kojiishi commentedon Jan 24, 2019
So IIUC it means:
prebut do not include ifpre-wrap.pre-wrap, after eliminating trailing spaces.?
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.
upsuper commentedon Jan 28, 2019
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
text-align(when available width is enough) andmax-content, the spaces should be included, and the only case where it should never be included when wrap ismin-content.If that understanding is correct, then WebKit would be wrong on both
text-alignitems, and Blink would be wrong ontext-align: justify, and Gecko would be wrong onmin-content, but vast majority of impls still match the spec, and the spec has at least two correct impls for each behavior (Edge counts one for all items), which sounds like an encouraging situation.kojiishi commentedon Jan 28, 2019
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.
fantasai commentedon Jan 30, 2019
@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? :)
fantasai commentedon Jan 30, 2019
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?
99 remaining items
Bug 1583748 [wpt PR 19286] - Pre wrap end line spaces, a=testonly
Bug 1583748 [wpt PR 19286] - Pre wrap end line spaces, a=testonly
Bug 1583748 [wpt PR 19286] - Pre wrap end line spaces, a=testonly
Bug 1583748 [wpt PR 19286] - Pre wrap end line spaces, a=testonly
Bug 1583748 [wpt PR 19286] - Pre wrap end line spaces, a=testonly
Compute the NGLineInfo hang_width even if ignored in text alignment
Compute the NGLineInfo hang_width even if ignored in text alignment
Compute the NGLineInfo hang_width even if ignored in text alignment
Compute the NGLineInfo hang_width even if ignored in text alignment
Compute the NGLineInfo hang_width even if ignored in text alignment
Compute the NGLineInfo hang_width even if ignored in text alignment
Bug 1750885 [wpt PR 32444] - Compute the NGLineInfo hang_width even i…
Bug 1750885 [wpt PR 32444] - Compute the NGLineInfo hang_width even i…
Make the hanging behavior of trailing spaces not depend on text-align
Bug 1750885 [wpt PR 32444] - Compute the NGLineInfo hang_width even i…