[css-text-4] move "balance | stable | pretty" out of text-wrap

[frivoal]

While discussing #3473 @fantasai pointed out that the decision of whether to wrap, and of which line breaking algo to use when wrapping ought to be separate, to cascade independently, and therefore to be separate properties.

I agree, and therefore think we should move balance | stable | pretty out of text-wrap. And likely, that new property is where we should add the new value that solves #3473 (which could be called something like avoid-oprhans).

It should be an inherited property.

As for its name, here's a first suggestion to entice people to propose something better: wrap-style

[litherum]

isn't, like, at least one value of them already shipping?

[bramus]

Correct. text-wrap: balance shipped in Chrome 114.

https://chromestatus.com/feature/5196960707903488

[litherum]

so, like ....

isn't this impossible?

[frivoal]

It was specifically pointed out (by @fantasai ) during the intent to ship that:

my concerns are mainly with:
[…]
c) whether the CSSWG considers this stable enough to ship, or if there are
unresolved concerns about the design of the feature

@kojiishi 's answer was:

I understand that the spec is still in early draft, it’s WD, not CR, PR, nor REC. If the spec changes, we can change our implementation accordingly. Even if names were changed or the feature was dropped, not applying text-wrap: balance doesn’t cause disasters; it just lays out the same as other browsers

So, while we should not change just for the sake of changing, if there are good reasons to change, my understanding is that Chrome has indicated that this is a risk they were willing to take when shipping early.

[chrishtr]

So, while we should not change just for the sake of changing, if there are good reasons to change, my understanding is that Chrome has indicated that this is a risk they were willing to take when shipping early.

Yes, but there is already quite a bit of usage in Chromium-based browsers. Making these sites migrate to a new syntax is possible but would need a good enough reason.

I can see why it would make sense to change around text-wrap along the lines of what was proposed in this issue, but I don't think it's important enough to cause churn and pain for those developers. To me it seems like a good thing we could have done, but not that big of a deal to leave it as-is and move on.

For this reason I'm opposed to changing the feature's syntax for the already-shipped values.

[frivoal]

For this reason I'm opposed to changing the feature's syntax for the already-shipped values.

I understand the reluctance to make compat affecting changes to features that have shipped. But that's in tension with using "we can always change it after we ship" as an argument to justify shipping prior to spec stability.

[bramus]

This seems relevant here: WebKit/WebKit#16723

[fantasai]

I agree with @chrishtr that with Chrome having shipped text-wrap: balance already, it's better not to change the name. But we might be able to split these apart anyway, by picking a different name for the white-space longhand portion.

[romainmenke]

Yes, but there is already quite a bit of usage in Chromium-based browsers. Making these sites migrate to a new syntax is possible but would need a good enough reason.

With my css author hat on.

We quickly adopted text-wrap: balance; because it is an obvious improvement almost everywhere and it causes no issues in older browsers. You just add it and things look better in latest Chrome but they were never broken elsewhere.

We even added it in a bunch of places before Chrome shipped it in stable because it was so harmless.

I wouldn't mind having to do a find/replace if this was taken out of text-wrap.

churn and pain for those developers

In this specific case I don't think it will cause that.
Nothing will break.

---

As a maintainer of postcss-preset-env and stylelint I wouldn't mind making the tools to help others migrate.

[jfkthame]

It seems to me that the balance value should not be an alternative to stable | pretty at all; it's a different type of control.

There are several aspects of wrapping that authors should be able to control independently, something like:

• text-wrap: wrap | nowrap -- controls whether wrapping is enabled or not

• wrap-style: stable | pretty -- what algorithm to use (should there be an auto initial value that lets the UA choose between stable/pretty, potentially based on its own heuristics?)

• wrap-balance: balance [<number>] -- asks the UA to try and balance line lengths if the block has no more than <number> lines

[css-meeting-bot]

The CSS Working Group just discussed [css-text-4] move "balance | stable | pretty" out of text-wrap, and agreed to the following:

• RESOLVED: text-wrap becomes a shorthand for text-wrap-style and text-wrap-onoff, and only text-wrap-onoff is a longhand of white-space

The full IRC log of that discussion

<Rossen_> Zakim, open queue
<Zakim> ok, Rossen_, the speaker queue is open
<emeyer> fantasai: Originally, text-wrap had two values, wrap and no-wrap
<emeyer> …Since then, we’ve added various values for not just whather wrapping occurs, but what KIND of wrapping occurs
<emeyer> …The more we add, the worse it becomes that this is mixed with wrapping and how
<emeyer> …Some of the values should cascade, and some shouldn’t
<emeyer> …I would like to split `text-wrap` into two properties
<emeyer> …One takes wrap and no-wrap, and the other takes all the others
<florian> q+
<Rossen_> q?
<Rossen_> ack florian
<emeyer> …Since `text-wrap` is shipping, I’m happy to dedicate it to how things are wrapped, and move the wrap/no-wrap to another property
<lea> ;?
<emeyer> florian: Completely agree
<lea> q?
<emeyer> …We do have some tension in the naming
<emeyer> …How bad is it to ask Chrome to break here
<lea> q+
<emeyer> …When they asked about shipping, they said it would be okay to rename later
<fantasai> wrap-style vs text-wrap would indeed be more understandable if that's possible ...
<emeyer> …I would prefer that we kept `text-wrap` for yes/no on wrapping at use `wrap-style` for the others
<emeyer> iank_: I think the situation has changed from that time period
<emeyer> …I don’t know if renaming is viable
<emeyer> florian: This is going to make it more difficult to do this sort of thing int he future
<emeyer> …We asked explicitly if it would be okay, and now it’s been waklked back
<emeyer> lea: I agree these should be separated, and we shoudl have more granular control over wrapping
<emeyer> …I don’t tknow that we need to break backwards compatibility to do that
<emeyer> …most of these are useless without wrapping, so it seems like a win that some of these values cause wrapping
<emeyer> …If you say `text-wrap: balance`, we can be smart and also set `wrap`
<Rossen_> q?
<Rossen_> ack lea
<emeyer> fantasai: What you’re proposing is we keep `text-wrap` as a shorthand that incorporates text wrapping on/off?
<emeyer> lea: Yes
<emeyer> fantasai: That could work, we need a better name than `text-wrap-on-off`
<fantasai> s|text wrapping on/off|text-wrap-style and text-wrap-onoff/
<emeyer> Rossen_: Let’s bikeshed the name offline
<jfkthame> q+
<fantasai> s/text-wrap-onoff/, where text-wrap-onoff is also a longhand of white-space/
<Rossen_> ack jfkthame
<emeyer> jfkthame: I wanted to add something slightly orthogonal
<emeyer> …balance really needs to be separated from stable versus pretty
<emeyer> florian: I’m unconvinced, it’s not obvious to me you’d want a stable balance that becomes stateful
<fantasai> +1 florian
<lea> s/…most of these are useless without wrapping, so it seems like a win that some of these values cause wrapping/…values like balance or pretty are useless without wrapping, so it seems like a win if setting text-wrap to one of these values would also enable wrapping (if you have no provided a separate wrap/no-wrap keyword)/
<emeyer> …Balance is a style of wrapping, it’s not clear that I want greedy balancing or whatever other options we could have
<lea> q?
<emeyer> jfkthame: The spec text suggests balance is only attempted up to a limited number of lines, and it then falls back to wrap, but what kind of wrapping?
<emeyer> florian: We could fix this in the spec; do you mean that if you set balance, we ignore the style of wrapping unless we fall back?
<emeyer> jfkthame: You could specify stable or pretty or balance, but if you do balance and then there’s a fallback, what happens?
<emeyer> florian: So you’re saying you want balancing, but you want to be able to choose how you fall back.
<lea> There is a continuum between balance and greedy wrapping. Authors often want some degree of balancing but less "draconian" than full-blown balance. Not sure if the solution is to separate balance out, or to just provide more control over exactly how the balancing happens
<emeyer> jfkthame: I’m not entirely sure
<emeyer> florian: I suspect what you want is orthogonal so it’s probably find as a pullout
<Rossen_> ack fantasai
<Zakim> fantasai, you wanted to suggest that these don't need to be separate properties
<emeyer> fantasai: I don’t see that these need to be separate properties; we could allow multiple keywords
<emeyer> …I think balancing is interesting because an implementation could use different approaches
<emeyer> …We want flexibility for user agents
<emeyer> …I do really like Lea’s proposal and it seems to address cascading problems we have with the current setup
<emeyer> fantasai: Propose text-wrap becomes a shorthand for two properties, text-wrap-style and text-wrap-on-off
<fantasai> PROPOSED: text-wrap becomes a shorthand for text-wrap-style and text-wrap-onoff, and only text-wrap-onoff is a longhand of white-space
<emeyer> …ONLY text-wrap-on-off is a longhand for whitespace
<emeyer> …(names to be bikeshedded)
<emeyer> florian: Is the complete value space of text-wrap the same as currently?
<fantasai> text-wrap: <'text-wrap-style'> || <'text-wrap-onoff'>
<emeyer> fantasai: Yes
<fantasai> text-wrap-onoff: wrap | nowrap
<emeyer> Rossen_: Hearing no objections…
<fantasai> text-wrap-style: stable | pretty | balance | auto | etc.
<emeyer> RESOVLED: text-wrap becomes a shorthand for text-wrap-style and text-wrap-onoff, and only text-wrap-onoff is a longhand of white-space
<emeyer> RESOLVED: text-wrap becomes a shorthand for text-wrap-style and text-wrap-onoff, and only text-wrap-onoff is a longhand of white-space
<emeyer> github-bit, take up https://github.com//issues/8539

[Loirooriol]

Was text-wrap-onoff a placeholder name? It sounds rather weird to me.
Sorry, missed "names to be bikeshedded" in the expanded minutes.

[frivoal]

Yes, it's a placeholder.

[frivoal]

I made the corresponding edits (using a text-wrap-mode as the place-holder name: 3a1eb85. Feedback welcome.

Will do the corresponding test work shortly.

[fantasai]

Agenda+ to bikeshed text-wrap-mode: wrap | nowrap longhand (vs text-wrap-style: stable | balance | pretty | etc.).

As a reminder the updated shorthand structure is:

text-wrap -> text-wrap-style + text-wrap-mode
white-space -> white-space-collapse + text-wrap-mode

This is urgent because implementations are already shipping text-wrap as a longhand of white-space, and we need the names for the longhands settled so the rearrangement above can be implemented and shipped ASAP.

[vmpstr]

To justify my vote above: text-wrap-allow: nowrap to me sounds like "we allow no wrapping" which is a different statement from "we disallow wrapping". Allow in general doesn't sound like an exclusive set unless the keywords sound more boolean like on and off.

[LeaVerou]

To justify my vote above: text-wrap-allow: nowrap to me sounds like "we allow no wrapping" which is a different statement from "we disallow wrapping". Allow in general doesn't sound like an exclusive set unless the keywords sound more boolean like on and off.

Ouch, that's a pretty good point :/
I’ve changed my vote…

[bradkemper]

I don't see a way to edit the comment, but of the two, I'd prefer text-wrap-mode: wrap | nowrap. However, I have a much stronger preference for white-space-wrap: wrap | nowrap. People are already used to writing white-space: nowrap, in any writing system, and this feels like a simpler mental transition for breaking wrap|nowrap into its own property. Instead of being a shorthand of a shorthand.

[bradkemper]

However, I have a much stronger preference for white-space-wrap: wrap | nowrap.

Also, the wrapping still usually only happens where there is white space, so it isn't totally wrong to think of this as a white-space-based property.

[bradkemper]

By the way, whatever we call the property, have we considered if avoid could be one of the values (i.e. wrap | no-wrap | avoid-wrap), instead of having wrap-inside as a separate property? It seems to me that wrap-inside: avoid is just a slightly relaxed version of white-space-wrap: nowrap (or text-wrap-mode: nowrap).

[LeaVerou]

@bradkemper I edited your vote in, @astearns can we fix the permissions so that Brad can vote in the future?
I also completely agree wrt white-space-wrap and I added a note about that for both of us.

+1 for folding wrap-inside inside this too.

[bradkemper]

@LeaVerou thank you. Should I open a separate issue for folding wrap-inside inside this?

It would mean it would be inheritable, but i think that's better anyway.

[LeaVerou]

@LeaVerou thank you. Should I open a separate issue for folding wrap-inside inside this?

Yes please.

[bradkemper]

Done: #9448

Also, I have edit power now. Thank you.

[johannesodland]

However, I have a much stronger preference for white-space-wrap: wrap | nowrap.

Also, the wrapping still usually only happens where there is white space, so it isn't totally wrong to think of this as a white-space-based property.

While the assumption that lines predominantly wrap at white spaces might hold true for English, the proportion of lines wrapping at white spaces can vary significantly from language to language, and even within different types of content.

Take my own language, Norwegian, as an example: we often use long compound words. To ensure proper line endings, it's essential to wrap lines at soft break opportunities within these words. Otherwise, we risk having less than optimal line endings, or “bad rags”. In a casual analysis of a random Norwegian book, I observed that around 20% of the line wraps occurred within words, not at white spaces.

On the web, inputting soft-break characters is quite challenging. This leads to web content in Norwegian (and likely in other languages) often suffering from bad rags. I feel that naming the property white-space-wrap could inadvertently perpetuate this bias towards English and neglect the typographical nuances of other languages.

My vote, if I had one, would be for text-wrap-mode.

[bradkemper]

On the web, inputting soft-break characters is quite challenging. This leads to web content in Norwegian (and likely in other languages) often suffering from bad rags. I feel that naming the property white-space-wrap could inadvertently perpetuate this bias towards English and neglect the typographical nuances of other languages.

Your point is well taken, but there is little to no chance that we wouldn't consider the needs of non-English languages. We actively work against English bias when designing how the features work. This, to me, is primarily about the name, and whether we make white-space (which people are familiar with) the shorthand that includes a wrap-or-not property, or if the new text-wrap should be the shorthand that includes nowrap.

Since we can't go back in time to rename white-space, it is more about writing ergonomics to me. I believe the primary use of the white-space has been to write white-space: nowrap. It is easier for authors to just add -wrap to the property name when using its most common value, when they want the space-collapsing behavior to be set separately and inherit separately.

[css-meeting-bot]

The CSS Working Group just discussed [css-text-4] move "balance | stable | pretty" out of text-wrap, and agreed to the following:

• RESOLVED: text-wrap-mode

The full IRC log of that discussion

<lea> https://github.com//issues/9102#issuecomment-1747785298
<fantasai> lea: This async poll had a difference, that did not allow input from WG members (because we did it first, before deciding to add emojis)
<fantasai> lea: I think the version with emojis worked really well
<fantasai> lea: the reactions also bumped the comment up which made the comment more visible
<fantasai> lea: and also we were able to get both opinions at a glance, whereas here we only get WG perspecive
<fantasai> lea: here we got 10 votes, `text-wrap-mode` seems to be a clear winner, but not as definitive
<florian> q+
<Rossen_> q?
<fantasai> lea: both me and Brad said they would prefer `white-space-wrap` if it were an option
<Rossen_> ack florian
<fantasai> florian: between two choices, I did abstain. i would be against white-space-wrap
<fantasai> Rossen_: poll is leaning text-wrap-mode
<fantasai> Rossen_: any objections?
<fantasai> RESOLVED: text-wrap-mode

[yisibl]

Unfortunately, with Chrome 114 shipping white-space shorthand, once someone uses white-space: pretty/balance in Chrome it will be incompatible with the current specification. This is because the implementation in Chrome does not distinguish between text-wrap-mode and text-wrap-style.

Do we need Chrome to be updated as soon as possible to match the latest specifications?

cc @kojiishi

[jfkthame]

Chrome shipping white-space shorthand ... white-space: pretty/balance

I've just filed https://bugs.chromium.org/p/chromium/issues/detail?id=1501748, as I didn't find an existing bug report about this. It's clearly wrong behavior, and will lead to webcompat pain. 😞

[yisibl]

Thanks @jfkthame

[frivoal]

Adjusted WPT to make sure that white-space: balance and white-space: pretty are rejected, as per spec.