[css-text-3] Audit details of break-spaces value against use cases

[fantasai]

https://lists.w3.org/Archives/Public/www-archive/2018Mar/0002.html

[frivoal]

On the one hand, I agree that over all, the various properties that affect line breaking and space preservation are a complicated mess from a UI point of view, and are hardly intuitive. It can be explained why which does what, but that's not the same thing.

Within that, I think overflow-wrap: break-spaces is not that unusual. It is not terribly obvious why that's there, but it can work, and it can be explained: The property is to deal with wrapping when the line would overwise overflow. Spaces at the end of the line are defined to overflow as "hanging" (which is either just ink overflow, or scrollable overflow, see #2398). Therefore, dealing with it there is OK.

Arguably, the value could also be attached to the word-break (e.g. a series of preserved white spaces is some kind of special "word") or line-break (e.g. this affects how the line breaks) properties. I suppose that if we did so, the new grammar should be [ currently accepted values ] || break-spaces. I am not theoretically opposed to that, but I am not convinced it is a real improvement either. It is just as easy to justify the value not being on these properties: word-break is self described as being about "soft wrap opportunities between letters", and line-break says it's "particularly how wrapping interacts with punctuation and symbols". At one point we also argued that it should be a value on the white-space property. I see no end to this discussion if we keep on reopening it.

Anyway, I am not objecting to better property design if there is a better solution, but I think that most likely, the better thing to do is to give it a rest, keep the current design we landed on, let people implement this (at least igalia is about to, and comments from others suggest that it may be in other people's roadmap as well). We may have a better chance at a sane UX by trying for nicer shorthand syntax in level 4, to paper over the mess that these various properties are in general, not limited to this question.

[frivoal]

@litherum I believe you were looking into implementing this. Any opinion?

[rachelandrew]

I was asked to have a look at this as someone who teaches this stuff. I'm not completely familiar with the whole spec but have read the linked meeting minutes. From an initial read I think I have a reasonable preference for how it is currently specified (as the overflow-wrap property). I think it better describes the situation of overflowing whitespace, rather than treating the preserved white space as a special word and therefore part of word-break.

I think I'd describe this as "overflowing whitespace", and I think that would be something any author would understand. Making the property seem sensible.

[frivoal]

Right, that makes sense to me. So I think we should not change this syntax.

What we do need to tweak is that when overflow-wrap: break-spaces is on, the spaces are treated as more substantive things that otherwise, and therefore the one space at the end of the line that does not get wrapped should be counted towards in min-content inline size

[css-meeting-bot]

The Working Group just discussed Audit details of break-spaces value against use cases, and agreed to the following resolutions:

• RESOLVED: Spaces don't hang when break-spaces is specified

The full IRC log of that discussion

<dael_> Topic: Audit details of break-spaces value against use cases
<dael_> github: https://github.com//issues/2465
<dael_> astearns: These are things we're rounding back to.
<dael_> astearns: This issue needs to be address to unblock something
<dael_> flackr: Igalia is about to impl and needs this closed.
<dael_> fantasai: There's several slight details. This is about break-spaces. Goal on some property is thre's a mode where editing says when you're tyuping a space
<dael_> fantasai: We want carat to move forward, spaces to not overflow as long as it' smore then 1em wide box so spaces don't hang.
<dael_> fantasai: There's currently a break spaces value on overflow wrap, but right now spaces are defined as can hang at end of line.
<dael_> fantasai: There's side effects of this. When you have a word at the end of the line and it fits but the space doesn't, even though you're breaking spaces it doens't move to next line but it does overflow. If you want things to wrap it's a problem this space overflows.
<dael_> fantasai: Related issue is that when you're trying to define intrinisic size of this box if the space is hanging it's not counted but if you want it visible you want to count it.
<dael_> fantasai: Seems to me if we want the space to behave like normal visible character, it should also effect size and not be hanging.
<dael_> fantasai: This means if the word fits and you type a space if the word fits it will wrap and we measure the space when measuring intrinisic size
<dael_> frWe fixed an issue in edge when people expect content:editible and not to wrap at same places because they use it for underlines. They use it as a rendering of the text.
<dael_> florian: So rendering should be same either way even if the reason is because when it's editable you wouldn't want anything else.
<dael_> florian: We're not proposing a difference, we're proposing both modes are same but when you're in editing the new behavior is sane, not almost sane.
<dael_> fremy: WE did the reverse.
<dael_> fremy: We made it so that when layout not taking space
<dael_> fantasai: fremy fix where you made them match that's good and if they want spaces to show and say break-spaces the spaces take up space.
<dael_> florian: But why align editable and not to not take space.
<dael_> fremy: Most content web is spaces not so we changed to that case.
<dael_> florian: It's hanging but it's there.
<dael_> fantasai: Edge behavior is in the spec now as most recommended as I recell
<dael_> fantasai: Change is that spaces don't hang when break-spaces is specified.
<dael_> florian: Rest is consiquences of that.
<dael_> fremy: Sounds good.
<fantasai> s/consiq/conseq/
<dael_> astearns: Obj to Spaces don't hang when break-spaces is specified?
<dael_> RESOLVED: Spaces don't hang when break-spaces is specified

[frivoal]

@fantasai I've made a Pull request for the spec and one for the tests. Review appreciated.

[frivoal]

So, Igalia+Google are in the middle of implementing this, and have suggested we make a change to the syntax: instead of having break-spaces be a || alternative in overflow-wrap, it could be a | alternative in white-space.

Pros:

• || alternatives are easier to implement than | alternatives
• break-spaces is only useful when combined with white-space:pre-wrap, so you have to check that property anyway. It could instead be a variant of white-space:pre-wrap, on the same property.
• There is not a particularly strong correlation between the break-spaces and break-word values from the point of view of where authors want to set them. They don't particularly need to be cascading together
• It fits some people's mental model better

Cons:

• in a browser that does not support break-spaces, the fallback of white-space: pre-wrap; overflow-wrap:break-spaces would be white-space:pre-wrap; overflow-wrap: normal. This is closer to the original intent than falling back from white-space: break-spaces to white-space: normal. This is can be easily mitigated by authors explicitly providing a fallback value (white-space: pre-wrap; white-space: break-spaces;) though.
• It fits some other people's mental model better

The set of property and values that control line breaking and white space is messy and hard to understand anyway, and I don't think we can find a perfectly elegant answer. We've been renaming and shuffling this value between various properties for the last 3 years or so. Chasing perfect is the enemy of good.

Personally, I think either alternative is OK. Given that this request comes from the first implementation effort, I am inclined to support it, so that we can ship this asap, and finally put it in the hands of authors.

If the WG is firmly against that change, I'm OK with that too, and hope that Igalia+Google can live with that.

Either way, we should resolve and move on.

CCing people who have previously opined: @javifernandez @kojiishi @fantasai @litherum @tabatkins @rachelandrew

[frivoal]

@fantasai spec and tests PR done. Review appreciated.