Implement "word-break: break-word"
Categories
(Core :: Layout: Text and Fonts, defect, P3)
Tracking
()
People
(Reporter: dholbert, Assigned: emilio)
References
Details
(Keywords: dev-doc-complete, Whiteboard: [webcompat:p1] Use `overflow-wrap: anywhere`[wptsync upstream][wpt-new-tests])
Attachments
(1 file)
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
Reporter | ||
Comment 1•8 years ago
|
||
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
Updated•8 years ago
|
Updated•7 years ago
|
Comment 2•7 years ago
|
||
(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•7 years ago
|
||
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
Updated•7 years ago
|
Comment 4•7 years ago
|
||
And "word-break: break-word" is now in official specs and need reaction
Comment 5•7 years ago
|
||
Yes, we know. Resources are limited; we can't do everything at once. (Proposed patches welcome!)
Comment 6•7 years ago
|
||
"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•7 years ago
|
||
(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.
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•7 years ago
|
||
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•7 years ago
|
||
@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?
![]() |
||
Updated•6 years ago
|
![]() |
||
Updated•6 years ago
|
Comment 11•6 years ago
|
||
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.
![]() |
||
Updated•6 years ago
|
![]() |
||
Updated•6 years ago
|
Comment 13•6 years ago
|
||
@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•6 years ago
|
||
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...
Reporter | ||
Updated•6 years ago
|
![]() |
||
Updated•6 years ago
|
Comment 15•6 years ago
|
||
That bug is related to the change to overflow-wrap: break-word, not word-break: break-word.
![]() |
||
Updated•6 years ago
|
![]() |
||
Comment 16•6 years ago
|
||
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.
![]() |
||
Updated•6 years ago
|
Comment 17•6 years ago
|
||
Karl, overflow-wrap: anywhere
, which is in Firefox 65 release, is (afaik) equivalent to word-break: break-word
and should satsify the requirement.
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)
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•6 years ago
|
||
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•6 years ago
|
||
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•6 years ago
|
||
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•6 years ago
|
||
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•6 years ago
|
||
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•6 years ago
|
||
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•6 years ago
|
||
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.
Reporter | ||
Comment 27•6 years ago
|
||
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
Assignee | ||
Updated•6 years ago
|
Comment 28•6 years ago
|
||
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•6 years ago
|
||
Probably not, Philip. At this point, I think the best thing for compat would be to just implement it. Thanks!
Updated•6 years ago
|
Assignee | ||
Comment 30•6 years ago
|
||
Comment 31•6 years ago
|
||
Pushed by ealvarez@mozilla.com: 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•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/15661 for changes under testing/web-platform/tests
Comment 34•6 years ago
|
||
I just verified that the sites where this still reproduces are fixed (from the see also list).
Reporter | ||
Comment 35•6 years ago
|
||
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).
Reporter | ||
Updated•6 years ago
|
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)
Reporter | ||
Comment 37•6 years ago
|
||
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.
Upstream PR merged
Comment 39•5 years ago
|
||
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•5 years ago
|
||
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.
Updated•5 years ago
|
Updated•5 years ago
|
Description
•