[css-text-3] Implement or unship word-break:break-word

[frivoal]

We resolved to add word-break:break-word if Firefox and Edge found it necessary to implement for web compat reasons.

It's been two years, and it is still not implemented.

If it is needed for compat, it should be implemented and specified. If it is not, it should be removed from the webkit family of browsers.

Since it looks like we're not rushing towards implementation, could we instead have safari and chrome try to remove it? The fact that Edge and Firefox can live without is decently strong evidence of removability.

[css-meeting-bot]

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

• RESOLVED: Defer this to next level

The full IRC log of that discussion

<fantasai> Topic: word-break: break-word
<fantasai> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-94
<dael> github: https://github.com//issues/2390
<dael> fantasai: Last time we talked we'd say add only if nec for compat reasons. Do we have enough information? Or are we deferring?
<dael> florian: I talked about this with Rossen and they felt comfortable postponing for now. They're not sure they're doing it yet.
<dael> fantasai: So continue to defer. Useful to know.
<dael> florian: There is a FF bug about impl because it was in the spec at some point. We were clear that seeing it in a spec is not enough justification for impl.
<dael> fantasai: And we removed it from the spec.
<dael> fantasai: So closed as deferred?
<dael> astearns: Objections?
<dael> myles: In L4 isn't there another property that does same thing?
<dael> fantasai: There's an existing property that's word-wrap:break-word and that's different behavior.
<dael> astearns: And even with identical behavior there may be a web compat reason to put it in L4.
<dael> astearns: Objections?
<dael> RESOLVED: Defer this to next level
<dael> florian: Follow up question to Blink. usage is quite high so your default answer is no.
<dael> koji: We contacted some site owners and they said the think the different behavior is important so they won't change.
<dael> koji: About computing [missed] widths. It beaks line only if it overflows so if an author sets it in the table cell it expands. The scenario to not extends makes it more difficult to us.
<dael> myles: min-width is different.
<dael> florian: But if we impl line-break:anywhere would that work?
<dael> fantasai: No because word breaking is normal.
<dael> astearns: This is now a text L4 issue.
<dbaron> The breakout is being scribed in #fx.

[CShepartd]

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

[CShepartd]

This is BIG mistake and should be reverted

[astearns]

We have deferred this, not removed it

[CShepartd]

@astearns
But it is still mistake, @frivoal making private vendetta without any sense reason (maybe he dont understand how important that rule is). I posted example and can make more showing how important it is

[CShepartd]

Now devs using "hacks" for marginal browsers who don't support "word-break: break-word":
word-break: break-all;
word-break: break-word;

This is how it should looks? No. Deferring is another step back for real front-end devs who working with these problems everyday knowing issues but decided to make that case untill all web browsers will support it with W3C blessing or without

This shouldn't be deferred

[CShepartd]

I've seen a many of sites that are broken in Firefox/IE because they unsupporting this. They have a pattern where they use:

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

So when ignoring the second (unsupported) value and use the first, resulting in undesirable breaks, while Chrome uses the second value and it all looks good.

[frivoal]

@frivoal making private vendetta without any sense reason

I am not making a vendetta, very sorry that you are taking it this way.

The last time the working group discussed this, the conclusion of the whole working group (not me particularly) was that this was a bad feature, and that we should only support it if compatibility requires it. This means either all browsers and the spec should support it (because they need to) OR all browsers should remove it because it is not needed. I was just following up on that previous resolution.

So far, there had not been an argument in the working group for this feature being desired even if web compatibility did not require it. I believe this is your point: we should have it regardless of compatibility requirements because it is a useful feature.

We can and should totally have that discussion.

If I understand correctly, you are saying this is useful because since it wraps like word-break: normal; overflow-wrap: break-word and it also has an min-content size calculated as if it was word-break: break-all, that means you can use it inside table cells without making the cell unnecessarily large. Is that correct? Are there other cases where this is useful?

[CShepartd]

Are there other cases where this is useful?

And this is showing the main problem - you don't know what is "word-break: break-word". Another example? Of course, i have many of this - https://jsfiddle.net/ofgd83um/18/ (and first "updated" https://jsfiddle.net/ofgd83um/23/)

From specs:

word-break: break-word
An otherwise unbreakable sequence of characters may be broken at an arbitrary point if there are no otherwise-acceptable break points in the line. Shaping characters are still shaped as if the word were not broken, and grapheme clusters must stay together as one unit. No hyphenation character is inserted at the break point.
The behavior is the same as word-wrap/overflow-wrap: break-word, except that this value is taken into account when computing min-content inline size as other values of this property are.