Closed Bug 1296042 Opened 8 years ago Closed 5 years ago

Implement "word-break: break-word"

Categories

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

Product:
Core
Component:
Layout: Text and Fonts
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla67
Tracking Flags:
Tracking Status
firefox51 --- wontfix
firefox60 --- wontfix
firefox67 --- fixed

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)

Bug 1296042 - Make word-break: break-word behave like word-break: normal; overflow-wrap: anywhere. r=dholbert,jfkthame
47 bytes, text/x-phabricator-request
Details | Review 
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
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
Priority: -- → P3
(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.
status-firefox60: --- → affected
And "word-break: break-word" is now in official specs and need reaction
Flags: needinfo?(jfkthame)
Yes, we know. Resources are limited; we can't do everything at once. (Proposed patches welcome!)
Flags: needinfo?(jfkthame)
"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
(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.
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.
@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?
Flags: needinfo?(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.
Flags: needinfo?(jfkthame)
Flags: webcompat?
Whiteboard: [webcompat]
Still not passing tests https://jsfiddle.net/ofgd83um/53/
@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.
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...
That bug is related to the change to overflow-wrap: break-word, not word-break: break-word.
See Also: https://webcompat.com/issues/18202 →

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

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)

See Also: → https://webcompat.com/issues/25500
Whiteboard: [webcompat] → [webcompat] Use `overflow-wrap: anywhere`

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?

Flags: needinfo?(fantasai.bugs)

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.

Flags: needinfo?(fantasai.bugs)

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?

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.

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?

Flags: needinfo?(philip)

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.

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.

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.

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: nobody → emilio

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?

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

Flags: needinfo?(philip)
Flags: webcompat? → webcompat+
Whiteboard: [webcompat] Use `overflow-wrap: anywhere` → [webcompat:p1] Use `overflow-wrap: anywhere`
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

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

Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox67: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Flags: needinfo?(miket)
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/15661 for changes under testing/web-platform/tests
Whiteboard: [webcompat:p1] Use `overflow-wrap: anywhere` → [webcompat:p1] Use `overflow-wrap: anywhere`[wptsync upstream]

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

Status: RESOLVED → VERIFIED
Flags: needinfo?(miket)

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).

See Also: → https://webcompat.com/issues/24886
Status: VERIFIED → RESOLVED
Closed: 5 years ago → 5 years ago
Whiteboard: [webcompat:p1] Use `overflow-wrap: anywhere`[wptsync upstream] → [webcompat:p1] Use `overflow-wrap: anywhere`[wptsync upstream error]

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.

Whiteboard: [webcompat:p1] Use `overflow-wrap: anywhere`[wptsync upstream error] → [webcompat:p1] Use `overflow-wrap: anywhere`[wptsync upstream]

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.

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.

Keywords: dev-doc-needed → dev-doc-complete
Blocks: 658883
No longer blocks: 658883
Whiteboard: [webcompat:p1] Use `overflow-wrap: anywhere`[wptsync upstream] → [webcompat:p1] Use `overflow-wrap: anywhere`[wptsync upstream][wpt-new-tests]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: