[css-text-3] Why is anywhere a value of the line-break property, rather than the word-break property?

[r12a]

https://www.w3.org/TR/css-text-3/#word-break-property
https://www.w3.org/TR/css-text-3/#line-break-property

Seems like i'm hopelessly late with this question, since various browsers have been implementing the anywhere value of line-break, even if they are not implementing the loose, normal, and strict values. However, i find that having the anywhere value under line-break rather than word-break is very confusing when i want to figure out how to style content.

It seems to me that anywhere is a natural fit alongside the other word-break values, since it's presumably exclusive to them in usage.

Can someone explain for me (so that i can explain to others) why the anywhere value was attached to line-break?

[frivoal]

IIRC, we did discuss that when setting this up, but went for line-break because the effects of word-break are limited to allowing / suppressing breaks within words, while line-break:anywhere also affects the break opportunities around punctuation, as do the other values of line-break.

have been implementing the anywhere value of line-break, even if they are not implementing the loose, normal, and strict values

Which browser doesn't have loose/normal/strict? I thought they all did now (possibly with some amount of bugs, but still)

[r12a]

IIRC, we did discuss that when setting this up, but went for line-break because the effects of word-break are limited to allowing / suppressing breaks within words, while line-break:anywhere also affects the break opportunities around punctuation, as do the other values of line-break.

Yes, but that's precisely why i find it confusing. I think you're relying on the switch to a different property to make a distinction which is more logical by choosing a different value of word-break. In both cases it's about how words get broken, it's just a slight change in the rules from one to the other, so word-break is in my mind the intuitive place to look for the feature.

Having to instead use a completely different property not only seems odd, but also requires you as an author to learn the differences and remember them, and use different constructs for what are really two small variations on the same thing: word-breaking.

For example, imagine that you are Chinese and instead of your content using the default word-break:break-allsetting for line breaking you want to ignore the punctuation rules: i think you'd intuitively say to yourself, "Oh, i need a different value of word-break here.", but no you have to go off and use the line-break property. And then you begin to ask yourself, "so which value of word-break should i now be using?" All you wanted to do was stop applying those punctuation rules.

If you remember, i had to ask in another issue whether i was doing the right thing for Ethiopic. It wasn't immediately clear how line-break:anywhere was different from word-break:break-all, and i stlil have to make a mental effort to remember how to use them properly (although that's not helped either by the confusable naming of the word-break vs line-break properties, but that's now water under bridge). If they were both values of word-break, that would be much simpler to assimilate, partly because they are exclusive choices, and partly because what i'm trying to do is find the right basic line-breaking (read word-break) algorithm.

Which browser doesn't have loose/normal/strict? I thought they all did now (possibly with some amount of bugs, but still)

Ah yes, i see that Gecko does now have support that matches Blink & Webkit, and i guess we can discount EdgeHTML.

[kojiishi]

Here's the history: #1171 (comment) discusses which property to add the new value, resolved to line-break: break-all. Then I opened #1561, resolved here: #1561 (comment)

[frivoal]

In both cases it's about how words get broken,

No, line-break: anywhere is not about how words get broken. It does change that, but also influences breaks between words and punctuation, between two punctuation marks, between non-breaking-spaces, and various other situations that don't involve words at all… with line-break: anywhere, you allow line breaks anywhere, and words aren't relevant. Other values of line-break fit in that model as well: the line breaks they enable or disable aren't concerned with what's a word, and they affect punctuation marks and various characters or character combination.

word-break, on the other hand, is only concerned with what's going on inside words, by changing alphabetic letters (and a few related categories) to behave like ideographs, or vice-versa.

---

And then you begin to ask yourself, "so which value of word-break should i now be using?"

and

It seems to me that anywhere is a natural fit alongside the other word-break values, since it's presumably exclusive to them in usage.

By the nature of what this value does, no matter which of the two properties we attach it do, the other becomes irrelevant. So that on its own isn't a strong argument for which of the two it should be in.

---

All you wanted to do was stop applying those punctuation rules.

We don't have a value that allows unconditional line breaking around punctuation rules while keeping everything else the same. But if we had one, I suspect it would still be a value of the line-break property.

Note that the definition of word-break does say this:

It does not affect rules governing the soft wrap opportunities created by white space (as well as by other space separators) and around punctuation. (See line-break for controls affecting punctuation and small kana.)

And then the definition of break-all further reinforces the message:

Note: This value does not affect whether there are soft wrap opportunities around punctuation characters. To allow breaks anywhere, see line-break: anywhere.

---

[…] wasn't immediately clear how line-break:anywhere was different from word-break:break-all,

if you want breaks anywhere on the line, line-break: anywhere. If you want to allow break between all letters of a word, word-break: break-all.

I'm not saying this to pretend this is self evident. This is just a phrasing that I find convenient to remember what goes where. Line breaking is controlled by a confusing set of properties, and we've been through multiple attempts at redesigning the system, using more or fewer properties, changing which of them controls what, renaming the properties or the values or both… And within the constraints imposed by compatibility, this is the best we've found.

It would be great if everything these properties and values did was entirely obvious based on their name alone. It's probably too late to change that though, and even if it wasn't no better naming scheme has been found yet.

But naming aside, as far as the text of the spec is concerned, the values' description are very explicit about what they do.

[fantasai]

@r12a, I think @frivoal and @kojiishi have explained the history behind the decision. At this point I don't think it's reasonable to change, as there are good reasons for the current system and it's already implemented and deployed. Would you do be OK if we closed this issue?