1296042 - Implement "word-break: break-word"

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect, P3)

Description

[Daniel Holbert [:dholbert]]

It's looking like the nonstandard "word-break: break-word" feature might be specced soon.  This has caused webcompat issues in the past[1][2][3], though I'm not aware of any sites that are currently broken in Firefox because of it.  But we should perhaps consider implementing it, since it seems like it's not going away.

(It's currently Blink/WebKit-only, originally added there for compat with older IE versions, I think.)

For context, see these CSSWG meeting notes:
  https://lists.w3.org/Archives/Public/www-style/2016Mar/0352.html
...and this bug where Blink considered deprecating it but decided to keep it because its usage wasn't low enough & it was potentially getting specced:
  https://bugs.chromium.org/p/chromium/issues/detail?id=492202
...and this thoughtpiece from Mike Taylor a few years ago:
  https://miketaylr.com/posts/2014/01/word-break-break-word.html

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=959735
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=968994
[3] https://github.com/webcompat/web-bugs/issues/1671

Comment 1

[Daniel Holbert [:dholbert]]

One more piece of context: fantasai emailed www-style this week, to ask for further information/thoughts:
 https://lists.w3.org/Archives/Public/www-style/2016Aug/0045.html
and Koji replied with a link to the (wontfix'ed) Blink bug that I noted in comment 0:
 https://lists.w3.org/Archives/Public/www-style/2016Aug/0050.html

Comment 2

[Jonathan Kew [:jfkthame]]

(In reply to Daniel Holbert [:dholbert] from comment #0)
> It's looking like the nonstandard "word-break: break-word" feature might be
> specced soon.  This has caused webcompat issues in the past[1][2][3], though
> I'm not aware of any sites that are currently broken in Firefox because of
> it.

I've seen a couple of sites that *are* broken in Firefox because of this; they have a pattern where they use

    word-break: break-all;
    word-break: break-word;

so we ignore the second (unsupported) value and use the first, resulting in undesirable breaks, while Chrome uses the second value and it all looks good.

Obviously, this is dumb authoring (for English content where break-all is really not appropriate), but it's probably coming from some example on a blog or whatever, and people are blindly copying it and not testing in Firefox.

Comment 3

[WolneWilno]

Still missing CSS value "break-word" in "word-break"

https://www.w3.org/TR/css-text-3/#word-break-property
https://drafts.csswg.org/css-text-3/#word-break-property
https://developer.mozilla.org/en-US/docs/Web/CSS/word-break

Comment 4

[WolneWilno]

And "word-break: break-word" is now in official specs and need reaction

Comment 5

[Jonathan Kew [:jfkthame]]

Yes, we know. Resources are limited; we can't do everything at once. (Proposed patches welcome!)

Comment 6

[Florian Rivoal]

"word-break: break-word" was added to the official spec by mistake (and is being removed). The resolution was not to add it, but to add it **if** Mozilla / Microsoft felt the need to add it for web compat reasons (see [1], reconfirmed in [2]).

So please to not use the spec as a justification to add this.

If it is needed for web compat, then sure, you should add it and let the CSSWG know we should spec it, but otherwise this seems like a confusing feature (and name) to add in an already complicated set of property/values.

[1] https://lists.w3.org/Archives/Public/www-style/2016Mar/0352.html
[2] https://lists.w3.org/Archives/Public/www-style/2017May/0047.html

Comment 7

[Jonathan Kew [:jfkthame]]

(In reply to Florian Rivoal from comment #6)
> "word-break: break-word" was added to the official spec by mistake (and is
> being removed). The resolution was not to add it, but to add it **if**
> Mozilla / Microsoft felt the need to add it for web compat reasons (see [1],
> reconfirmed in [2]).
> 
> So please to not use the spec as a justification to add this.
> 
> If it is needed for web compat, then sure, you should add it and let the
> CSSWG know we should spec it, but otherwise this seems like a confusing
> feature (and name) to add in an already complicated set of property/values.
> 
> [1] https://lists.w3.org/Archives/Public/www-style/2016Mar/0352.html
> [2] https://lists.w3.org/Archives/Public/www-style/2017May/0047.html

Well, that's really unfortunate. [2] says "The usage data is too high on word-break: break-word for Chrome to remove it...", which sounds to me like it's not going anywhere. And as long as it's in the spec, it's hard for us to push back against sites where it is causing webcompat issues (see comment 2): we can't really tell them "your site is broken" when the spec supports them.

Comment 8

[6ea3c7a3]

MS Edge team will implement in stable version "very soon" (that was described by MS employee in private issue thread). Firefox need to support this to not stay behind everyone.

Comment 9

[Florian Rivoal]

I would encourage the MS Edge team, or the Mozilla team when you pick it up, to let the CSS WG know about it then. We're waiting for feedback form MS/Mozilla to know if you've found it necessary to implement. If so, we'll spec it. Until then, we won't.

Comment 10

[6ea3c7a3]

@Florian Rivoal
You are fighting with web developers who needs "word-break: break-word". For simple example https://jsfiddle.net/ofgd83um/1/
We are not bad deamons, we need to have rule to break word in only neccesary with not breaking size container or all words. Do you think in Chrome supporting it without any reason? (most popular browser, over 57% market share and growing because they providing what developers needs - http://gs.statcounter.com/) We as front-end web-devs need that. You are doing bad thing with fighting against "word-break: break-word" because finally you fighting against us - web developers

So when it will be implemented in FF?

Comment 11

[Jonathan Kew [:jfkthame]]

The most recent CSS WG discussion on this topic resolved to accept https://github.com/w3c/csswg-drafts/issues/2682, so that's probably what we should plan to implement.

Comment 12

[idontlikespying]

Still not passing tests https://jsfiddle.net/ofgd83um/53/

Comment 13

[fantasai]

@jfkthame Not exactly. The WG resolution was to alter the behavior of 'overflow-wrap: break-word' to match the current behavior of the non-standard 'word-break: break-word' in Webkit/Blink. We did not resolve to add 'word-break: break-word', and won't unless Web-compat forces Edge and Firefox to implement it. So I think the preference would be to close this bug WONTFIX if at all possible, and open a new one on altering intrinsic sizing to take 'overflow-wrap' into consideration.

Comment 14

[fantasai]

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1472386
Hopefully this prevents us from having to contend with both `word-wrap: break-word` and `word-break: break-word` existing in CSS...

Comment 15

[Xidorn Quan [:xidorn] UTC+10]

That bug is related to the change to overflow-wrap: break-word, not word-break: break-word.

Comment 16

[Karl Dubost💡 :karlcow]

According to the title we have
Implement "word-break: break-word"

This is another issue with

.activity-log-item__description {
	font-size: 14px;
	word-break: break-word;
}

no other value will satisfy the initial requirement.

See https://webcompat.com/issues/24990

Comment 17

[fantasai]

Karl, overflow-wrap: anywhere, which is in Firefox 65 release, is (afaik) equivalent to word-break: break-word and should satsify the requirement.

Comment 18

[Thomas Wisniewski [:twisniewski]]

This is also hitting Gigabyte's support pages, making their tables bleed off-screen without being able to scroll to see all of the detail (https://webcompat.com/issues/25500)

Comment 19

[Thomas Wisniewski [:twisniewski]]

fantasai, do you know if Google and Webkit will now drop word-break:break-word, or should we now go ahead and treat it as an alias for overflow-wrap:anywhere, for webcompat's sake?

Comment 20

[fantasai]

I think Google will implement once NG layout is finished, they're pushing off most fixes due to that... if you can make a good case to them that their lack of implementation is causing compat problems for Firefox, they might bump the priority, I don't know. I expect WebKit intends to fix as well, no idea about priority though.

Comment 21

[Mike Taylor [:miketaylr]]

The problem is existing sites which currently rely on word-break: break-word. Getting sites to update CSS is mostly a losing battle. Perhaps we should rename this bug to "alias word-break: break-word to overflow-wrap: anywhere?

Comment 22

[Jonathan Kew [:jfkthame]]

Given the reluctance to add word-break:break-word to the spec, I don't think we should be adding such an alias without discussing it with the CSS WG first.

I suppose the real question, though, is whether Blink will be prepared to drop it given that the WG has resolved (presumably with input from the Blink team) to specify a different property (overflow-wrap:anywhere) for this use case. If it's nevertheless going to remain in Chrome, I suspect we'll have no real choice but to implement (or alias) it anyway.

Comment 23

[Mike Taylor [:miketaylr]]

We could add it to the Compatibility Standard, if the CSSWG doesn't want it in their specs (if we alias it or not).

AFAIK, Chrome only has usecounters on properties, not values, so I'm not sure https://www.chromestatus.com/metrics/css/timeline/popularity/162 is helpful.

Philip, is there some other way to assess usage of a prop: val pair in Chrome?

Comment 24

[Koji Ishii]

We can estimate rough usage by combining with Edge data:
https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/word-break/
The estimate is currently around 11% usage (31% * (4.9% / 13.7%)).

When the estimate gets closer to 0.03%, we can add a counter to measure more accurately. I talked about this with fantasai a couple of months ago at TPAC, it'll be at least a few decades until we can start thinking about it. 7 years or so has past since we wanted to rename 'word-wrap' to 'overflow-wrap', current usage is 55% vs 11%, so maybe "a few" decades is too optimistic.

Comment 25

[Xidorn Quan [:xidorn] UTC+10]

I had a look at the compat bugs listed in See Also, and I think it's reasonable enough that we should implement word-break: break-word as an alias of overflow-wrap: anywhere. Hoping websites to update their CSS while Chrome is removing it is not going to work.

Comment 26

[Xidorn Quan [:xidorn] UTC+10]

I mean, having a look at the compat bugs, I'm convinced that it's enough a compat problem we need to handle one way or the other.

I think CSSWG is trying not to complicate the stuff, which is reasonable desire. But given the compat issues, we don't really have choices. We can mark it legacy / deprecated, though, I guess.

Comment 27

[Daniel Holbert [:dholbert]]

The CSS Working Group just discussed word-break: break-word, and agreed to the following:

* `RESOLVED: add word-break:break-word to text level 3, with a note`

https://github.com/w3c/csswg-drafts/issues/2390#issuecomment-467685010

Comment 28

[Philip Jägenstedt [:foolip]]

Mike, we don't have use counters for all property values, but one can add them manually. Is this still relevant given that it's being added to the spec?

Comment 29

[Mike Taylor [:miketaylr]]

Probably not, Philip. At this point, I think the best thing for compat would be to just implement it. Thanks!

Comment 30

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1296042 - Make word-break: break-word behave like word-break: normal; overflow-wrap: anywhere. r=dholbert,jfkthame

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c1075c1f1605
Make word-break: break-word behave like word-break: normal; overflow-wrap: anywhere. r=jfkthame

Comment 32

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/mozilla-central/rev/c1075c1f1605

Comment 33

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/15661 for changes under testing/web-platform/tests

Comment 34

[Mike Taylor [:miketaylr]]

I just verified that the sites where this still reproduces are fixed (from the see also list).

Comment 35

[Daniel Holbert [:dholbert]]

Adding one more "see-also" for a report on Google Photos (which I verified is fixed in Nightly as well, due to the break-word support that was added here).

Comment 36

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Can't merge web-platform-tests PR due to failing upstream checks:
Github PR https://github.com/web-platform-tests/wpt/pull/15661
* Taskcluster (pull_request) (https://tools.taskcluster.net/task-group-inspector/#/QrbqGcXZT1imRHKCq0Vxlw)

Comment 37

[Daniel Holbert [:dholbert]]

I left some comments on the WPT pull request (linked in comment 36), BTW.

The issue there is a wpt-firefox-nightly-stability test failure, with Firefox getting a blank screenshot of the reference case. I've seen that happen at least one other time (with the test itself not being at fault), so I think we were just unlucky.

Comment 38

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged

Comment 39

[Chris Mills [:cmills]]

Note to MDN writers:

Release note added to MDN about this: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/67#CSS

When we come to document this, we really only need to update the BCD.

Comment 40

[Chris Mills [:cmills]]

I've filed a PR to update the compat data for this: https://github.com/mdn/browser-compat-data/pull/4055

I also tweaked https://developer.mozilla.org/en-US/docs/Web/CSS/word-break to improve it a bit.

With that, I think the docs here are done.