Csswg-drafts: [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?

[frivoal]

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?

[upsuper]

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

Yeah, that seems to match my understanding.

[css-meeting-bot]

The CSS Working Group just discussed When to/not to include preserved trailing spaces, and agreed to the following:

• RESOLVED: trailing spaces should be counted for max-content but not min-content
• RESOLVED: when preserved trailing spaces hang they do it using allow-end rather than force-end

The full IRC log of that discussion

<dael> Topic: When to/not to include preserved trailing spaces

<dael> github: https://github.com/w3c/csswg-drafts/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/w3c/csswg-drafts/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

[kojiishi]

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

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

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.

[frivoal]

I'm not sure if I have a good understanding of what "allow-end" behavior is.

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.
So

   |A_B____  |

gets right aligned as

   |  A_B____|

not

   |      A_B|____

and

   |A_B______|___

gets right aligned as

   |A_B______|___

not

   |      A_B|_________

or

A_B|_________|

For justification specifically, I believe the same logic would apply, so

So

|A_B____  |

would get justified as something like

|A_ B ____|

not

|A   _   B|____

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.

[kojiishi]

However, currently, it seems to me that browsers just don't justify at all...

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?

[frivoal]

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.

[frivoal]

probably to make double-spacing at the end of sentence easier

Is that the only use case we know of, or are there others?

[kojiishi]

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 pre-wrap for the all paragraphs. The contenteditable might also want to use pre-wrap too.

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.

[frivoal]

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.

[css-meeting-bot]

The CSS Working Group just discussed When to/not to include preserved trailing spaces, and agreed to the following:

• RESOLVED: preserved spaces from pre-wrap hang when they occur before a soft wrap, but would not hang when at the end of block or forced break

The full IRC log of that discussion

<heycam> Topic: When to/not to include preserved trailing spaces

<heycam> github: https://github.com/w3c/csswg-drafts/issues/3440

<heycam> fantasai: some discussion back and forth about how to handle preserved whitespace at the end of a line

<heycam> ... most recent resolution is that it hangs if it doesn't fit in the line box

<heycam> ... koji came back to say that doesn't make sense if you have a paragraph that is white-spcae:pre-wrap

<heycam> ... since then you will end up not justifying fully with the last visible letter to the edge of the container

<heycam> ... because if that white space happened to fit, it would be within the container, otherwise you wouldn't get a flush edge

<heycam> ... the discussion is now: should we say it's force hang instead?

<heycam> ... or do something else?

<heycam> florian: koji raised this only in the case of justification?

<heycam> ... on other alignments browsers were aligned, and you're not trying to change that?

<heycam> koji: for justification including trailing spaces it's clearly wrong

<heycam> ... for right and center, I'm neutral

<heycam> ... in those cases I can see both sides of the argumnet

<heycam> florian: I'm trying to understand the use cases better

<heycam> ... because I'm a little bit confused about whether it's in general OK, or already broken, to try to use pre-wrap on body text, paragraphs

<heycam> ... if you have source code that is pre, and you want to switch to pre-wrap to avoid overflow, that's fine

<heycam> ... if you apply pre-wrap to body text, there are some odd things that happne

<fantasai> I think this is why actually I made the comment in https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-458783789

<heycam> ... links in the text are underlined, if your linked phrase have spaces, you'll have a hanging underlined space at the end

<heycam> ... so it's a bit strange, but I'm not sure

<heycam> ... don't know if we should try to support that more, in which case what you say about justificaiton is right

<heycam> ... or decide we don't really care about this, and not optimize for it

<heycam> ... maybe people want to use double space after a period? that also feels into the category of not needing to try to support it

<heycam> ... so these are kind of at the edge

<heycam> ... of reasonable use of the properties

<heycam> fantasai: format=flowed plain text email is essentially pre-wrap text

<heycam> florian: but you don't rejustify it

<Rossen> q?

<heycam> ... if you try to preserve the format of the email, you don't go to justify it, since your alignments made with spaces will be broken by the justification

<heycam> fantasai: as far as trailing spaces underlined go, you can use text-decoration-skip

<heycam> ... I think it's a bit weird for something to hang for some operations but not others

<heycam> ... it might make more sense to say that if there is a soft break after a space, then that space force hangs

<heycam> ... for alignment, justification, everything

<heycam> ... but if there's a hard break, then that space does not hang

<heycam> ... for the use case of pre-wrap on an entire para, you're not going ot be ended it with a period, a space, a line break

<heycam> ... but for a line of text that happens to end with a space, then that would work

<heycam> florian: if we do force hang in that situation, what does it do for the max content size? include the size of not?

<heycam> fantasai: max size is always unwrapped, so you include the spaces

<heycam> florian: what about space at the end of the paragraph?

<heycam> fantasai: then there's a force break right after it

<heycam> florian: ok

<heycam> fantasai: let's say you have a word a space a word another space, end of the block

<heycam> ... then you wrap in the middle of that

<heycam> ... so you have word space soft-break word space end of block

<heycam> ... if you were to right align that text, the space that is at the end of the block would not hang

<heycam> ... it's at the end of the bloc

<heycam> ... the space that is wrapped does hang

<heycam> ... when you left align you won't notice

<heycam> ... when you right align or justify you will see the first line's space hang

<heycam> ... generally you want spaces to disappear the end of line -- we can distinguish between these cases by whether there's a soft wrap there or not

<heycam> koji: I think that makes sense

<heycam> ... if other browsers are willing to match, I think we can try to match

<heycam> ... is Gecko happy with it? I think xidorn wanted to include trailing spaces

<heycam> ... for right and center

<heycam> heycam: we can resolve and ping xidorn to get his opinion

<heycam> RESOLVED: preserved spaces from pre-wrap hang when they occur before a soft wrap, but would not hang when at the end of block or forced break

<heycam> florian: currently we say that spaces hang when they go beyond the edge of the block, browsers are allowed to discard them

<heycam> ... we key that off the fact they hang

<heycam> ... are we still allowed to drop the last spaces before the forced break, or also not allowed to do that

<heycam> fantasai: let's discuss that another day

[upsuper]

koji: I think that makes sense
... if other browsers are willing to match, I think we can try to match
... is Gecko happy with it? I think xidorn wanted to include trailing spaces
... for right and center
heycam: we can resolve and ping xidorn to get his opinion

As I mentioned before that I don't have strong opinion either way. I was just trying to figure out the general rule from the discussion before which seems to make sense, and matches majority of implementations. If there are usecases suggest otherwise, I'm fine with that as well.

So it seems the resolution was to have spaces force-end for alignment when it's a soft wrap, but allow-end otherwise? That sounds reasonable to me.

[frivoal]

So it seems the resolution was to have spaces force-end for alignment when it's a soft wrap,

Yes

but allow-end otherwise?

I think we were saying not to hang at all in that case.

[upsuper]

I think we were saying not to hang at all in that case.

How would you handle cases like

|a____________|_____

then?

[kojiishi]

How would you handle cases like...

I think it's an overflow, not hanging. Maybe a minor terminology problem though.

[frivoal]

If you try the same example with something other than spaces, we still overflow to the right even if text-align:right. So either way, it would still render as:

     |a____________|_____

and not

a____|_____________|

[upsuper]

Being an overflow means it is supposed to have line wrap but just has no wrap opportunity? Then what about something like

|a__b______|_____

Is this overflow or hanging? If it's overflow, why is wrapping not triggered?

[kojiishi]

Such line should wrap before "b", right? And if the 2nd line is longer than available width, it will overflow.

Maybe we have different mental model and that terminologies are confusing?

[frivoal]

I've made a pull request to apply this change: https://github.com/w3c/csswg-drafts/pull/3868

However, while I think force-hanging the end-of-line pre-wrap preserved spaces is a good idea, I am unsure about not doing the same for end-of-line pre-wrap preserved spaces that come before a forced break:

• I don't understand what the use case is for that distinction
• it would change where lines wrap compared to today, including causing some previously non wrapping elements to start wrapping. (example: https://jsbin.com/leqanut/edit?html,css,output)
• Safari, Chrome (and Edge), but not Gecko also ignore all end-of-line pre-wrap preserved spaces (regardless of forced break vs soft wrap) for min-content sizing purposes, while Gecko includes them (also regardless of forced break vs soft wrap). (example: https://jsbin.com/wonefeq/edit?html,css,output)

Are we sure that we don't want simply force-hang for all end-of-line pre-wrap preserved spaces, regardless of being followed by a soft wrap vs forced break?

[fantasai]

Well, we definitely don't want to force-hang the preserved spaces before a forced break when calculating the max-content size; otherwise max-content won't leave room for the spaces, and I think we do expect that.

[frivoal]

I agree with including these spaces in max-content calculations, but they shouldn't be included in min-content, or to cause additional wrapping, so I don't think that means they need not to hang. Force-hanging punctuation should also be included in max-content calculations, so the way I'd deal with that is to say that end-of-line spaces (with pre-wrap) always hang, regardless of forced break vs soft wrap, but also clarify the definition of hanging to make sure it does the right thing for max-content.

[fantasai]

I don't think force-hanging punctuation should be included in max-content calculations. Hanging punctuation generally means you expect the padding to provide space for it and don't want extra space to be generated for it.

[css-meeting-bot]

The CSS Working Group just discussed When to/not to include preserved trailing spaces.

The full IRC log of that discussion

<dael> Topic: When to/not to include preserved trailing spaces

<dael> github: https://github.com/w3c/csswg-drafts/issues/3440

<dael> florian: Before concluded whitespaces at the end of a line for whitespace pre-wrap force hang.But spaces before forced break wouldn't hang.

<dael> florian: Based on issue fantasai prop in order to make them count to max content, but definition of hanging doesn't say if they count or not.

<dael> florian: THen again spaces before a forced break also shoudln't count to min content

<dael> florian: If you look at interop browsers don't treat spaces before a forced break differently

<dael> florian: I think we shoudls ay they hang regardless of forced or soft wrap, but say they count toward max-content size.

<dael> florian: Also clarify if hanging punct. counts or not. Implied maybe, but hanging on intrinsic size isn't explicit

<dael> fantasai: [reads spec]

<fantasai> https://www.w3.org/TR/css-text-3/#hang

<dael> florian: Doesn't say for intrinsic. For min talked explicitly, but for max it's fuzzy. In punct case...it's saying a bunch of things and you can figure out what they prob mean but it doesn't say it explicitly. Esp. given tests aren't clear there's interop so clarifying is good

<dael> florian: I rpoposed we clarify toward don't count regardless of it's min or max. Space we don't count for min and do for max. I think that matches rough interop

<dael> fantasai: If we include it in max content size but then subsiquently align to the right the max content no longer fits the content. This is why we want to be consistent if it's counter for alignment max content and justification. Need same answer or otherwise weird

<dael> florian: Also quite weird with non-intrinisic size. You've got whitespace at the end of lots of lines. All except last align to the right. That's also weird.

<dael> fantasai: Yeeah. But in other cases you're wrapping. Whitespace at wrap you expect to disappear. Whitespace before a break you didn't have to put it there.

<dael> fantasai: If behavior makes more or less sense dependson if content is wrapping or not. Nice if right/left/center align is consistent and encased in max-content

<dael> fantasai: No great answer here. Having max-content and align have different answers doesn't make sense

<fantasai> s/answers/answers on a single line/

<dael> florian: If koji's test is still accurate everyone includes spaces for max and most but not all include for right align. Webkit and blink don't include for justification so they do that differently then alignment

<dael> florian: Last time around we resolved to align with WK and Blink for justificaiton and apply that to right align so never include the spaces.

<dael> florian: It's weird anyway. I have tests to match previous, I just think it's weird.

<dael> Rossen_: We're overtime

<dael> Rossen_: I don't feel we're ready to resolve.

<dael> florian: I think we forced last time and that's part of problem

<dael> Rossen_: Table discussion back to github. For those interested, continue there and we'llr esume next week

<dael> florian: Please look, what we have is well defined, but I'm not sure it's good.

[frivoal]

Personally, I think that justifying pre-wrap text is weird, and that we should not optimize for that case. If we give up on that, we can go back to hanging only the spaces that overflow, which means:

• count the preserved spaces for max content
• don't count the preserved spaces for min content
• don't ignore the preserved spaces when center/right/justify aligning.
  That does make justification a bit odd, but again, I don't think the use case is strong, and having consistency on the rest seems more useful.

If we do want to solve it for justification as well, a more complete but also more complicated answer could be that we allow-hang (i.e. only hang the spaces that would overflow) the pre-wrap spaces in general, but force-hang (i.e. hang all of them) when justifying. Since justification already has the distinction between the last and non-last lines, text-align: justify would force-hang on all lines but the last, and allow-hang on the last line, while text-align: justify-all would force-hang on all lines.

[kojiishi]

The different opinions might come from whether to see pre-wrap as 1) a variation of pre that allows wrapping, or as 2) a variation of normal that does not collapse spaces. It looks like you are the former and want to handle preserved spaces in the same way for pre and pre-wrap. I agree the former cases exist, but I think the latter is more common.

[kojiishi]

One new data: we've got a report saying that LayoutNG shows horizontal scrollbar for the following CSS:

white-space: pre-wrap;
overflow-x: scroll;

I think we need to think about text-align: left (or start to be more accurate) too. I'm updating the existing behavior table in the top of this thread.

[kojiishi]

and crbug.com/453830 is when Blink matched to Gecko. @fantasai's proposal seems to work for this reported case.

[frivoal]

I've made two possible pull requests to close this bug:

• https://github.com/w3c/csswg-drafts/pull/3868 which strictly applies the resolution we took.
• https://github.com/w3c/csswg-drafts/pull/4095 which implements a variant: instead of requiring end-of-line preserved spaces to hang on lines with no forced breaks, and forbidding hanging on lines with forced breaks, it requires end-of-line preserved spaces to hang on lines with no forced breaks, but allows (not forces) handing them on lines with forced breaks.

In many cases, the result will be the same, but there are some subtle (and useful) differences:

• In https://github.com/w3c/csswg-drafts/pull/3868's example 8, the text is wrapped onto 3 lines. Current browsers don't do that. The equivalent situation shown in example 8 in https://github.com/w3c/csswg-drafts/pull/4095 keeps the text on two lines, matching what browsers have implemented.
• If https://github.com/w3c/csswg-drafts/pull/3868's example 8 was made editable, and the user placed the caret after the last space, and inserted an x, the rendering would change from
  |0 0| |0 | |0 |
  to
  |0 0| |0 0| |x |
  If instead we used the rules of https://github.com/w3c/csswg-drafts/pull/4095, we go from
  |0 0| |0 0|
  to
  |0 0| |0 0| |x |
  which seems much preferable, and matches current implementations.

I'd like @fantasai and @kojiishi feedback on this.

[frivoal]

Agenda+ to draw attention to it (or to resolve if people have sufficiently looked at it in advance).

[kojiishi]

4095 which implements a variant: instead of...

IIUC the difference is that you want to allow both hanging and not-hanging for end-of-spaces with forced breaks? I'm ok as long as the spec allows not-hanging behavior. I'm personally a fan of hanging behavior regardless of soft-/forced breaks, but when all impls do not hang them for pre, that is probably not easy to change.

[frivoal]

all impls do not hang them for pre

We're keeping that. This change only affects pre-wrap. For pre, nothing changes: we do not hang.

you want to allow both hanging and not-hanging for end-of-spaces with forced breaks?

Kind of, but the choice is not up to the UA, it depends on what fits the line or not.

The key point here is that:

1. Before unforced breaks, we require hanging in all cases (same as "force-end" for punctuation). (same in #3868 and #4095)

2. For #4095, before forced breaks, we require "conditional hanging", which is the type of hanging used by "allow-end" for punctuation: hang if it wouldn't fit, don't hang if it does. #3868 was different, and never hangs it before forced break, even if it doesn't fit.

It will give the behavior you wanted when using pre-wrap on a paragraph with two spaces after period: the end-of-line space for spaces in the middle of the paragraph will hang, and therefore justification will work properly.

It also means, that if you have a single line, with a forced break at the end, and preserved spaces at the start and end, both the start spaces and the end spaces are taken into account for alignment. See example 6.

This will give the correct result in https://bugs.chromium.org/p/chromium/issues/detail?id=453830

All that is the same in #3868 a #4095. But here is the difference:
If there are more spaces than can fit the line before a forced break, those than don't fit hang. For example, if we have <div>a_b__</div> with white-space:pre-wrap and a line length that will fit only 4 characters, #3868 will result in

|a_  |
|b__ |

but #4095 will result in

|a_b_|_

That seems better because:

• #4095 is more web compatible: #3868 would result in content that currently fits in one line to start taking two some times
• If you consider editing, and you add a "c" at the end of the example above, both #3868 and #4095 will result in:
  |a_b_|_ |c |
  For #4095, that's not surprising for the user, as the previous text doesn't change, but for #3868, it is surprising, as the wrapping of the previous text changes.

[kojiishi]

Are you proposing to change to hang only when overflow? And that rule will apply to when text-align: right too?

[frivoal]

Are you proposing to change to hang out overflow?

Before forced breaks, yes.

And that rule will apply to when text-align: right too?

Yes. See example 7 (especially the second figure in it) for details:

[kojiishi]

If you want to fix the case, I mildly prefer using text-align. I think explicit control is more intuitive for authors, and we can make sure that the new behavior is compatible for text-align: right, even when the line overflows.

So, do not hang if text-align is end, center, or physical value that is equivalent to end. Does this work for you?

[frivoal]

I don't see how that's relevant. How the updated proposal interacts with alignment is the same as the old one from fantasai, on which we had resolved with your approval, and reconfirmed in with you Toronto.

Again, the difference between the standing resolution (#3868) and my proposed tweak on it ( #4095) is limited to what happens to spaces before a forced break when they don't fit the line. Everything else is the same.

If we have <div>a_b__</div> with white-space:pre-wrap and a line length that will fit only 4 characters, the previous resolution results in:

|a_  |
|b__ |

My proposed change will result in:

|a_b_|_

That seems better because:

• it is more web compatible: the existing resolution would result in content that currently fits in one line to start taking two some times.
• If you consider editing, and you add a "c" at the end of the example above, both the existing resolution and my proposal will result in:
  |a_b_|_ |c |
  For my proposal, that's not surprising for the user, as the wrapping of the text before the inserted character doesn't change, but for the existing resolution, it is surprising, as the wrapping of the previous text would change.

[kojiishi]

Your proposal improves the case you presented, but has an undesired side-effect when text-align: right. Given this behavior was desired specifically for when text-align is center or end, the trade-off does not seem very attractive to me.

If there's a way to improve the case without the trade-off, I'm happy to discuss more.

[frivoal]

Please explain what you find undesirable. As far as I can tell, the behavior for text align is unchanged compared to the resolution we previously took.

[kojiishi]

Please explain what you find undesirable.

Oh, sorry, I thought I did, but apparently didn't.

Imagine you have "0" in width: 3ch block. Adding a space after the "0" moves it to left by one space. This is what authors expect AFAIU. Adding another space moves it to left by one more space. Still good.

Adding another space, however, moves "0" back to the right edge, and adding more doesn't move any longer. I think this isn't desired.

Does this explain?

[fantasai]

@kojiishi No, that's not how allow-end hanging works! That wouldn't work very nicely for hanging-punctuation either. :) Whatever part doesn't fit hangs, that's all.

[frivoal]

Adding another space, however, moves "0" back to the right edge, and adding more doesn't move any longer. I think this isn't desired.

As Elika said, that's not what happens. What would happen at the various steps of the insertion is:

|  0|

| 0_|



md5-737442b49235034e5edab5c68a352695



|0__|



md5-737442b49235034e5edab5c68a352695



|0__|_



md5-7857688fc85fb196c87629d87831c633



|  0_0|



md5-737442b49235034e5edab5c68a352695



| 0_0_|



md5-737442b49235034e5edab5c68a352695



|0_0__|



md5-737442b49235034e5edab5c68a352695



|0_0__|_



md5-9365fe8cb34819876a228471b2425599



|  0_0|



md5-737442b49235034e5edab5c68a352695



| 0_0_|



md5-737442b49235034e5edab5c68a352695



|0_0__|



md5-737442b49235034e5edab5c68a352695



|0_   |
|0___ |

[kojiishi]

For the last example, I think the previous resolution is preferrable for authors. Is that where you and I prefer different option?

Understood there were some misunderstanding, sorry about that, but my point is that adding spaces should change something, at least for center and end. I personally like WebKit behavior, but we once chose to not to hang on center and end. If we chose that, I think we should make sure it works all the time.

[kojiishi]

...now I feel less sure how much we want to try the new spec, because by doing so, we have to regress either the case @frivoal presented or the case I presented, for the behavior 3 browsers are interoperable today, correct? Any chance to reconsider the resolution?

[frivoal]

the behavior 3 browsers are interoperable today, correct?

No, it is not. Chrome and Firefox are similar, but Safari is different.

None of the existing implementations solve both the alignment/justification use case you brought up when opening this issue and cases like https://crbug.com/453830.

4095 and #3868 do solve both.

we once chose to not to hang on center and end

If "we" means the CSSWG, I don't believe we did. At least, the spec as it exists today is not like that, and the resolution in this issue is not like that either.

I personally like WebKit behavior

Both #4095 (my proposal) and #3868 (the standing resolution) are closer to the Webkit behavior than the current spec text. They both do the same thing as Safari[1] in for spaces at unforced breaks. The difference is only about the handling of spaces before forced break, which is necessary to handle cases like the one you reported with https://crbug.com/453830. Both #4095 and #3868 solve that case (but current Safari behavior does not).

I think a good way to describe the behavior of my proposal (#4095) would be:

• same as Safari[1] today for spaces before unforced breaks
• same as Chrome and Firefox today for spaces before forced breaks.

The original resolution (#3868) would be:

• same as Safari[1] today for spaces before unforced breaks
• new behavior (no hanging at all) for spaces before forced breaks. That's different from all implementations today (web compat concern) and is a worse behavior when editing.

my point is that adding spaces should change something

I agree. What it changes is a little bit different in different situations, but it changes something:

• If you are adding spaces before a forced break (which includes at the end of an element), and the spaces fit the line, this will affect alignment
• if you are adding spaces either at before an unforced break (whether they fit the line or not), or before a forced break if they don't fit the line, the spaces are inserted[1] (so the caret moves further each time you insert a space, they affect scrollbars, you can underline them or put a background on them...), but they hang, so they don't affect alignment.

---

[1] Note: When I say "like Safari", I mean with regards to hanging and to alignment. In addition to hanging the spaces, Safari also collapses the advance width of these spaces, so that they're not visible. This is allowed, but not required (and I would recommend not doing that) by the specification. Nobody is proposing to change that particular point.

[kojiishi]

I think I understood you correctly, but not sure if you understood me correctly, so allow me to rephase in simple text. Sorry if this looks rude or offensive, that's not my intention, just want to avoid misleading.

I understood you pointed out a regression in the previous resolution, and your new proposal can solve it. This is great, thank you.

In the proposal, when it says:

If you are adding spaces before a forced break (which includes at the end of an element), and the spaces fit the line, this will affect alignment

The "and the..." clause doesn't look great to me, it regresses when the space doesn't fit, and it's getting more complex. Given you found a regression, I prefer revisiting the previous resolution instead of adding new fixes on top of it.

...do I still look not understanding you correctly?

[fantasai]

@kojiishi In general, if there is overflow, text-alignment doesn't happen. So I think it's OK in this case, if there is extra spaces in the line that don't fit, that they're not considered for alignment.

Overall I think @frivoal's proposed adjustment to the CSSWG resolution is a good fix, it addresses some unforseen problems in the original resolution but otherwise preserves its spirit and, in nearly all cases, its behavior. And it does so by taking advantage of existing definitions we already have for hanging-punctuation, so I think it's a clean solution.

[kojiishi]

Not sure my previous point was understood, I'm not against @frivoal's proposal, I'm asking to revisit the previous resolution thanks to @frivoal's finding of the regression.

I don't think I want to accept the other regression in the new proposal, but I do agree that the regression @frivoal found is a very good one and we should try to fix it.

[css-meeting-bot]

The CSS Working Group just discussed When to/not to include preserved trailing spaces.

The full IRC log of that discussion

<dael> Topic: When to/not to include preserved trailing spaces

<dael> github: https://github.com/w3c/csswg-drafts/issues/3440

<dael> florian: Is koji on?

<dael> florian: Comment to rest of group. We resolved on this about half a year ago. I worked on a PR to apply resolution and found a weakness. I proposed a close alternative to the design. I asked fantasai to review.

<dael> florian: koji is other person close on that discusssion. I'm not clear why he disagrees. He sees both as a regression to what was there before. But I think the requirements are what he expressed in the past and now calls regression. I could be confused.

<dael> florian: It would be helpful to have more people looking. You have white-space: pre-wrap and there's whitespace at the end. THere's detailed PRs and examples. If you have any interest I would very much appreciate someone looking and seeing if I got it right or if there's a problem

<dael> florian: I would be helpfult o have people look. We can't resolve w/o koji

<dael> Rossen_: And there's always TPAC

[faceless2]

@frivoal I've put your "0's" test, above, at https://jsbin.com/fanatifawi. I hope I've understood your intention correctly.

This test is working properly in Chrome/Firefox, not in Safari. However it's contradicting the behaviour required by these tests:

http://w3c-test.org/css/css-text/white-space/pre-wrap-012.html
http://w3c-test.org/css/css-text/white-space/pre-wrap-013.html
http://w3c-test.org/css/css-text/white-space/pre-wrap-014.html
http://w3c-test.org/css/css-text/white-space/white-space-pre-wrap-trailing-spaces-001.html
http://w3c-test.org/css/css-text/white-space/white-space-pre-wrap-trailing-spaces-002.html

All of which work in Safari, but not in Chrome/Firefox.

Perhaps this is contributing to the confusion?

[frivoal]

@faceless2 Nice test, thank you.

Your tests correctly captures what #4095 proposes to do for lines ending in forced breaks, which does indeed match Chrome and Firefox. The behavior specified in #3868 is different: it'd be the same on your "0" lines, but it would be different on the "1 1" lines.

The test does not cover what happens to lines ending in a soft wrap. The two proposals are identical about that, and match the behavior of Safari in that case.

(and yes, the WPT tests need to be updated, but we need to decide how we are going to resolve this before I do that update).

[fantasai]

I updated the testcase to include the line-wrapping case here: https://jsbin.com/luxarox/1/edit?html,css,output I hope this makes things clear.

Thanks @faceless2 for such a nice test!

[frivoal]

Screenshot of @fantasai 's edited version of @faceless2 's test:

| Firefox / Chrome | Safari |
|-|-|
|||

[fantasai]

@fantasai and @kojiishi trying to clarify the definition of the terminologies together.

Given the definition:

• allow-hang means 1) line breaker allows spaces to hang, and 2) alignment treats spaces same as any other characters.
• forced-hang means 1) same as allow-hang for line breaker, and 2) alignment ignores trailing spaces.

Then "Include" in the original table is exactly the same as "allow-hang" and "Don't include" is "forced-hang".

Feature|Blink|Edge|Gecko|WebKit
---|---|---|---|---
text-align: start|hang|hang|hang|hang
text-align: end / center|allow-hang|allow-hang|allow-hang|forced-hang
text-align: justify|forced-hang|Do not justify|Do not justify|Do not justify

For text-align: start, allow-hang and forced-hang is indistiguishable.

Latest WG resolution (and @frivoal's proposal) is to match WebKit for lines that end in a soft wrap.
Lates WG resolution was to not hang at all for lines that end in a forced break; @frivoal's proposal is to allow-hang for such lines.

[css-meeting-bot]

The CSS Working Group just discussed [css-text][css-sizing] When to/not to include preserved trailing spaces, and agreed to the following:

• RESOLVED: Accept the proposal in https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-530702998

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/w3c/csswg-drafts/issues/3440#issuecomment-530702998

<emilio> fantasai: [summarizes situation]

<emilio> fantasai: proposal is to accept the proposal in https://github.com/w3c/csswg-drafts/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/w3c/csswg-drafts/issues/3440#issuecomment-530702998