[css-text][css-sizing] When to/not to include preserved trailing spaces

[kojiishi]

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.

[upsuper]

What do you mean by "Not include" vs. "Ignore justify" in the row of text-align: justify?

Conceptually, min-content should 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]

Thank you for asking.

What do you mean by "Not include" vs. "Ignore justify" in the row of text-align: justify?

"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 computing min-content.

[upsuper]

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]

The spec currently specifies that trailing spaces are hung (like hanging-punctuation) if pre-wrap is 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 for pre; 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]

@kojiishi @upsuper Did you want something different here or should I close the issue with no change?

[kojiishi]

So IIUC it means:

• For all cases, include if pre but do not include if pre-wrap.
• For @upsuper question, justification should work if 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]

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) and max-content, the spaces should be included, and the only case where it should never be included when wrap is min-content.

If that understanding is correct, then WebKit would be wrong on both text-align items, and Blink would be wrong on text-align: justify, and Gecko would be wrong on min-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]

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]

@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]

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?