User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

This new feature of the CSS Text 3 specification has been resolved [1] long time ago by the CSS WG. Chrome has just started [2] to implement it and Safari probably will follow [3], so I think Firefox could do the same.

[1] https://github.com/w3c/csswg-drafts/issues/1171
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=720205
[3] https://bugs.webkit.org/show_bug.cgi?id=181169

For reference, this is the section of the CSS Text 3 specification describing the new feature:

https://drafts.csswg.org/css-text-3/#valdef-line-break-anywhere

Bug 1358019 has a patch with the behavior we should implement, basically.

Javi, do you know how word-break and line-break are supposed to interact?

Like, if I say word-break: keep-all, line-break: anywhere, which one wins? It's not clear to me reading the spec...

From the spec:

https://drafts.csswg.org/css-text-3/#valdef-line-break-anywhere

"disregarding any prohibition against line breaks, even those introduced by characters with the GL, WJ, or ZWJ character class (see [UAX14]) or mandated by the word-break property."

So I understand that line-break: anywhere will overwrite any restriction imposed by word-break: keep-all.

Currently, we don't implement the line-break property at all; see also bug 1011369. I think we'll need to support parsing all the values, even if we don't immediately implement multiple different levels of strictness, otherwise we'll have new webcompat complications to worry about.

I don't think it is great practice to parse value and do nothing with them. That makes life hard for authors who try to use the cascade or @supports to do fallbacks. Supporting "line-break: auto | anywhere" should be pretty straight forward, and I don't really see why that'd be a compat problem.

Of course, it's even better if you can support all values, but I'm not sure why that would be a blocker for this.

(In reply to Florian Rivoal from comment #7)

I don't think it is great practice to parse value and do nothing with them. That makes life hard for authors who try to use the cascade or @supports to do fallbacks.

Agreed, it's not generally a good situation...

Supporting "line-break: auto | anywhere" should be pretty straight forward, and I don't really see why that'd be a compat problem.

If we support only auto and anywhere, the results could be undesirable if a site uses line-break:anywhere on an element, and then tries to set another value such as line-break:normal on a descendant: the unrecognized value on the descendant will be ignored, and the inherited anywhere value may result in bad breaking within the descendant element.

Note that the "loose | normal | strict" values are not yet parsed/implemented.

So here's a patch that attempts to implement anywhere.

Before deciding to ship this, though, I think we should look into whether we can also handle loose | normal | strict without too much pain, to avoid the situation where authors might rely on those values cancelling an inherited anywhere, and get surprising results in Firefox if they're not parsed.

I plan to land this together with the rest of line-break (bug 1011369) after the soft-freeze ends.

https://hg.mozilla.org/mozilla-central/rev/7c7e340a7886