Csswg-drafts: [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/w3c/csswg-drafts/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.

[frivoal]

And this is showing the main problem - you don't know [...]

You are under the impression that I am personally trying to kill this. I am not. There are many things that I don't know. But my personal lack of knowledge is not the cause of this.

Every single time this has been discussed in the CSS-WG, the only justification that was brought up was compatibility. Based on that, the working group (not me) decided that we should specify it only if browsers that currently do not implement it are forced to do so due to compatibility bugs. An incomplete definition was later added to the specification by mistake, against the decision of the group, and then removed when noticed.

This remains the status to this day. I was merely following up on an existing group decision, by saying that implementations and specs should match, so it needs either to be added to all implementations and to the spec OR removed from the implementations that have it.

You are arguing that word-break:break-word should exist for other reasons than just compatibility. I am not saying that you are wrong. I am saying that if you want to convince the group to add this property to the specification, the most useful thing to do is not to be angry at me, but to explain in detail all the cases where you think this is a desirable property.

[CShepartd]

I am saying that if you want to convince the group to add this property to the specification, the most useful thing to do is not to be angry at me

I just dont see real reason, to deffer it. Chrome devs sad will not remove "word-break: break-word" (because too high usage), IE devs will implement it "soon", I wanted to start wrote it for FF and pull request and then you are showing and deffering it. This is really strange and im trying not be angry at you but it's hard (what you can see)

explain in detail all the cases where you think this is a desirable property.

I'm describing problem, showing examples, what can i do more?

[dbaron]

The other key point that needs to be explained is why word-break: break-word is useful in addition to overflow-wrap: break-word. That requires not just linking to an example but explaining (say, in 3-5 sentences) why the example shows the need.

[CShepartd]

@dbaron
Examples should always better describe problem (and showing real problem in real usage) but if you want usefull addiction to overflow-wrap: break-word then it is computing min-content inline size as other values (what is showed in examples above)

[frivoal]

Examples should always better describe problem

Examples illustrate the problem, and are great together with a explanation to make sure there is no misunderstanding, but they are rarely enough.

I just don't see real reason to deffer it.

Defer means no work. Define now means work. Deferring is the normal answer until enough people are convinced it is needed, either for compatibility reasons or because it is useful.

You are trying to convince a large group of people to do work (write the spec, write the tests, write the code, forever maintain them and take them into account when designing new features). Spending time explaining why that matters is usually more effective than hoping everyone will independently come to the same conclusion.

[in addition] to overflow-wrap: break-word, it is computing min-content inline size as [if word-break was break-all].

I understand that this is what it does. I was wondering if you could explain why that is important. Not because I do not believe you, but because explaining why is this best way to help convince the group that this is important enough to warrant the effort, and to evaluate the solution. I can come up with an explanation, but I would prefer to hear from you why you think it is important, instead of guessing your motivations.

You may want to have a look at this description of the best way to propose features. It was written for a different working group, but is generally applicable here. It is not a formal process that we have to follow, but it is good advice in terms of convincing a web standards working group to solve a problem you have. "please add this feature" is step 8, not 1.

In order to keep CSS maintainable, even when convinced that a problem is worth solving, the group usually wants to consider whether a particular approach is the best way to solve the problem, or whether some other solution would be better.

For example, to solve this problem, I can think of several solutions (not saying they are equally good):

1. word-break: break-word as currently implemented in chrome
2. a new value to overflow-wrap that makes it affect intrinsic sizing. e.g. overflow-wrap: break-word vs overflow-wrap: break-word allow-shrink.
3. a new value to white-space that changes how intrinsic sizing is calculated. e.g. white-space: normal vs white-space: normal allow-shrink.
4. A new property to directly affect intrinsic sizing. e.g. min-content-width: 0
5. A new table-specific property. e.g. table-cell-wrap: auto | aggressive

Solution 1 has the advantage of already existing in some browsers and in some content. It has the disadvantage of making a confusingly named set of properties and values even more confusing, and of lacking the additional flexibility offered by solution 2, 3 or 4. Maybe it matters, maybe it does not.

Solution 2 have the advantage that it can be combined with other values of the word-break property, which may be better for internationalization purposes. Since the other values of the word-break property are primarily about supporting good typography in Chinese, Japanese and Korean, this may be a good thing. Korean authors may want to use it together with word-break: keep-all, Japanese or Chinese authors may want to use it together with word-break: break-all.

Solution 3 is similar to solution 2. An additional advantage is that you can use it without setting overflow-wrap: break-word if you are interested in the sizing effect but not the wrapping effect and prefer to overflow. A disadvantage is that you need to set more properties if you do want both effects, and that it would not work in table cells without setting both, since table cells cannot overflow.

Solution 4, like solution 3, has the advantage that you can get the sizing effect without the wrapping effect if you want to and to work with all the values of word-break, and the same disadvantage of not working in table cells unless you also set has overflow-wrap: break-word. It also has the advantage that it can be used in many other different contexts, even when not related to text-wrapping: for example, you could use it to change the intrinsic size of images. This however has the disadvantage that it sets the minimum size to 0, instead of to the widest letter, as word-break:break-word would do. Maybe this matters, maybe it doesn't. Maybe making this generic is great, maybe it is overkill.

Solution 5 may be better if the actual problem is limited to text within tables, and if we don't want to make a generic solution to a narrow problem.

But listing solutions is suggested as "step 5" in the above process, because getting a list of detailed requirements is very helpful to chose between the various possible solutions.

[CShepartd]

Defer means no work. Define now means work

When something working in more than 83% of web browsers in the world i think it shouldn't be deferred (Chrome, Opera, Safari, UC-Browser, Vivaldi have working word-break:break-word). And it will grow because in Edge issue tickets about missing word-break:break-word they responsing about adding this soon. Web browsers usage stats (http://gs.statcounter.com/) are without emotion and showing the best your misunderstood of situation with word-break:break-word

Your "solutions" are wrong too because not working in opposite to working word-break: break-word. If you dont see why it not working see screen and focus on width (body max is 400, live exaple there https://jsfiddle.net/ofgd83um/32/)

In summary - word-break: break-word working in more than 83% of web browsers (by usage) and shouldn't be deferred

[frivoal]

And it will grow because in Edge issue tickets about missing word-break:break-word they responsing about adding this soon

The existing resolution, which still stands, is to add it to the spec as soon as Edge or firefox does so. If they do so, we will add it to the spec. If they find that it is not necessary to do so, I will trust their analysis more than a blunt percentage, we will not add it to the spec, unless we find other good reasons.

If you think they will add it soon, you should not be worried, because we will add it to the spec as well.

If you think they will not add it, and you would like this feature anyway, I respectfully suggest that you spend your energy convincing people that it is an important feature by following the suggestions dbaron and I have given you, or by following the guide to proposing features.

If you are not interested in providing constructive feedback, and only want to complain and belittle the few people who are listening to you, I suggest you stop discussing this entirely.

[astearns]

That's not acceptable @CShepartd. I'm removing the comment above. If you continue to post abusively (here or in IRC) I'll ban you.

[fantasai]

Note that the behavior of this feature—allowing breaks anywhere if the word cannot fit its container (per word-wrap/overflow-wrap: break-word) and also having these break opportunities affect the min-content size—is now specified for word-wrap/overflow-wrap: break-word. See https://github.com/w3c/csswg-drafts/issues/2682

This means that once implementations catch up, there is no use case requiring word-break: break-word to be added (since overflow-wrap: break-word now has this behavior), and the only reason to add this second syntax would be if it's needed for Web-compat.

[CShepartd]

@fantasai
It will pass test? https://jsfiddle.net/ofgd83um/53/

[css-meeting-bot]

The Working Group just discussed Implement or unship word-break:break-word, and agreed to the following:

• RESOLVED: defer this issue for now

The full IRC log of that discussion

<dael> Topic: Implement or unship word-break:break-word

<dael> github: https://github.com/w3c/csswg-drafts/issues/2390

<dael> fantasai: I think it's that we have issue open about adding non-standard word-break:break-word to CSS. Not word-break:break-all. This allows you to wrap if you run out of room. Should have a property with same beahvior where word-wrap:break-word effects instrinsic size of element

<tantek> can we get intent to unship by whoever supports it if it's not a compat problem?

<bradk> word-break-wrap:wrap-break-word

<dael> fantasai: We were asked to add new value word-break:break-word for web compat and we pushed back b/c confusing. WE said we'd add value if FF and Edge found compelled for ewb compat to impl. They have not so far. To not go down that path we made word-wrap:break-word have the same behavior that they would have gotten from word-break:break-word

<tantek> myles does Safari/Webkit support word-break:break-word? And if so, can you unship?

<dael> fantasai: I recommend close no change for the moment. If our attempts to stem the webcompat problem is not successful we'll assume Edge or FF will file an issue saying we need this

<dael> astearns: tantek asked on IRC [reads]

<dael> fantasai: For the moment I don't think we should ask. WE should give time for impl to catch up with word-wrap:break-word behavior change so authors can use that in place of word-break:break-word

<tantek> q+ to say that no, compat != author requirements

<dael> fantasai: I think we need to give a year or 2 before we ask blink and webkit to unship so the web can adapt to standards complient way.

<emilio> Gecko just implemented, fwiw

<tantek> emilio: oh well, sounds like we're screwed then

<dael> florian: Also a chance this transition will be less painful since in browsers that don't have it, the least bad fallback is to use the property we recommend.

<tantek> q?

<fantasai> dbaron, https://bugzilla.mozilla.org/show_bug.cgi?id=1472386

<dael> florian: But we can't unship until we ship alternative.

<astearns> ack tantek

<Zakim> tantek, you wanted to say that no, compat != author requirements

<emilio> tantek: dbaron: The new behavior, I mean, sorry: https://bugzilla.mozilla.org/show_bug.cgi?id=1472386

<dael> tantek: I wanted to cmment that the process that we should wait on compat is orthogonal because compat has nothing to do with what authors want. Compat is are we screwed by what's in the past. If we're scewed waiting won't hcange. If we're not waiting cam make it worse. If you're serious about dropping you need to do it asap regardless of if the authors have an eq feature. You won't avoid compat in the future by introducing a future feature. THe reasoning is poor

<astearns> +1 to tantek

<dael> florian: We're inbetween. This is sufficiently used...

<dael> tantek: Is it on the record? I want blink and webkit to say here's why we can't unship. Let's not presume unshippability

<dael> florian: I thinkw e have it. Need to find it

<dael> frremy: It was discussed at a F2F and google said won't unship.

<dael> tantek: Do we have a % number to justify not unshipping?

<dael> frremy: I think they did.

<dael> tantek: If they did did they give us a % for if it drop below they'll unship? That's what we need for this to be numbers based

<Rossen_> +1 to tantek

<dael> fantasai: Blink contacted site owners asking them to change. Site owners didn't want to chang e because they needed specific property behavior. WE need time for that.

<astearns> q?

<tantek> emilio can you link the FF impl bug or FF intent to ship?

<emilio> tantek: https://bugzilla.mozilla.org/show_bug.cgi?id=1472386

<dael> fantasai: florian was saying that we're inbetween. usage is not high enough that edge and FF need to imple, but too high for chrome abd blink ot unship. Gecko has impl new property behavior and not unstandard thing

<dael> fantasai: We need to wait for that change to deploy across browser so site authors will change and then reduce web compat impact and then let them unship

<fantasai> https://github.com/w3c/csswg-drafts/issues/2390#issuecomment-380422690

<tantek> where is the commitment to implement the new property/value behavior from others?

<tantek> is FF the only implementation?

<dael> astearns: We're overtime. Weither or not we can get unship for non-standard...Well, this issue is impl or unship so I think we can resolve not to add non-standard prop but unship question is in the air.

<dael> fantasai: My recommendation is we close or defer this issue so it's not sitting

<dael> tantek: Let's defer

<dael> frremy: Defer to next level. I like this

<dael> florian: Defer good

<dael> astearns: Obj to defer this issue for now?

<dael> RESOLVED: defer this issue for now

[emilio]

Per https://bugzilla.mozilla.org/show_bug.cgi?id=1296042#c24 (and co.) Blink is not planning to unship this anytime soon, and sites not using overflow-wrap: anywhere are still giving Gecko compat headache... It'd be good to figure out what to do here, even if it's "putting it on the compat spec".

CC @miketaylr

[css-meeting-bot]

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

The full IRC log of that discussion

<fremy> Topic: word-break: break-word

<astearns> github: https://github.com/w3c/csswg-drafts/issues/2390

<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2390

<fremy> emilio: Blink cannot seem to be able to unship

<dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=1296042

<fremy> emilio: We considered the alternatives

<fremy> emilio: but the usage in Blink is very high so even if they also implemented the alternatives

<fremy> emilio: they would not unship

<fremy> emilio: I'm tired of getting new compat issues about this

<fremy> emilio: so, can we maybe as a group add this to a spec?

<fremy> emilio: maybe even mark it as deprecated

<fremy> emilio: it's sad but realistic

<fremy> florian: I am annoyed that this means we will have to care about this forever

<fremy> florian: but I guess if this is required, I guess we will have to live with it

<fremy> florian: because both the name is bad, but also it's not on the right property

<fremy> florian: but well...

<fremy> florian: ...

<fremy> florian: is anybody sad enough that they are willing to object?

<fremy> (so far no noise is heard)

<fremy> emilio: we could put it in a webcompat spec?

<fremy> florian: no, if we do it, let's do it properly

<fremy> florian: as in, the text spec

<fremy> astearns: so, all seem resigned to accept this at this point, is that right?

<fantasai> s/(so far no noise is heard)/<giggles>/

<fremy> astearns: proposed resolution is thus to add it (back) to the spec

<fremy> fantasai: we have to decide if we put it in the same table as the other values

<fremy> fantasai: or in a prose section further down below

<fremy> astearns: I like the latter

<fremy> astearns: level 3 or level 4?

<fremy> fantasai: level 3 because it is not CR yet

<fremy> dholbert: are we confident we can get this specced properly soon though?

<fremy> fantasai: yes, we already have this exact behavior, just on another property

<fremy> AmeliaBR: so we will have two values doing the same thing?

<fremy> fantasai: yes

<fremy> AmeliaBR: how will they interact

<fremy> emilio: either or both would trigger this behavior

<fremy> AmeliaBR: ok, seems reasonable

<fremy> emilio: either must work on their own for compat

<fremy> astearns: so, any object to add this to text level 3? with the explanation that people should use the other property?

<fremy> RESOLVED: add word-break:break-word to text level 3, with a note

[CShepartd]

Finally. Already implemented in Gecko (Firefox 68 Nightly)