[css-text] Having overflow-wrap: break-word affect min-content size is not webcompatible

[upsuper]

We resolved in #2682 that overflow-wrap: break-word should affect min-content size, however, it doesn't seem to be web-compatible.

After we landed the change to Gecko, we immediately got two bugs reported, and the latter is an issue on GitHub, see https://github.com/vscode-icons/vscode-icons/wiki/ListOfFiles.

GitHub has word-wrap: break-word set on the whole page, likely because its content are from users, and it's better to allow breaking word as a fallback when there is an otherwise unbreakable string. However, in that case, people may not really want it to affect min-content in e.g. tables accidentally.

[CShepartd]

First is for me wrong usage CSS. Second is more accurate, but like was discovered in comment almost the same thing showing on Chromium when you put word-break: break-word on the table.

[upsuper]

the same thing showing on Chromium when you put word-break: break-word on the table.

That basically indicates there are use cases for either way, word breaking with intrinsic size affected, and without. And for GitHub's case, I think it is a reasonable example of the latter case.

[fantasai]

I don't think it indicates use cases either way, it indicates that people are unintentionally relying on it not having any effect in certain shrinkwrap cases (and being upset that it doesn't in others). Which is a case for being more specific about where it's applied. And I agree with idontlikespying’s comment in 1476180, the CSS there is nonsensical.

If tables are a particular problem, adding table { overflow-wrap: normal; } to the UA stylesheet could be considered. Then the author can adjust their approach if necessary. (Given that data frequently gets stacked side-by-side and is especially likely to get unexpectedly squashed, this is a pretty reasonable style rule to add.)

[CShepartd]

@fantasai
I agree. This solution sounds good or just not inherit that rule for tables by default from higher levels.

[upsuper]

There is another bug filed for PHP manual, where putting table { overflow-wrap: normal; } wouldn't help, because what they do is code { word-wrap: break-word; } and then using <code> in every table cell of one column.

[CShepartd]

@upsuper I dont see any bug. They should set min-width for td or code. Look at this table on lower resolution in stable FF. Table is breaking layout. In Nightly it calculating proper and not break layout. This is fix, not a bug. Attachment with example

[morrisonlevi]

php.net will definitely need to revisit its layout.

However, none of the columns have predefined widths; that's purely auto-layout. And yet, it's breaking letters of the word in that first column before trimming down the last? Seems wrong.

Edit: Any specific advice on php.net is appreciated. Setting a predetermined width seems problematic, because we have many tables all throughout the site with various content per-column, with various numbers of columns, and these are rendered automatically from DocBook sources. Maybe table-layout: fixed? That has its own problems, notably further down on the same page where we have a two-column table where the first column is very skinny.

[fantasai]

@morrisonlevi The suggestion would be table code { word-break: normal; }, which resets word-break to normal so that breaks within words are disallowed (if that was the intent, which it seems it was).

[FremyCompany]

Based on the amount of reported issues, maybe we should revisit not accepting the word-break: break-word property value. Sure, that value doesn't make a lot of sense, but also it is now used a lot on the web, and we might just as well cave in.

We have seen a couple of websites doing word-break: break-all; word-break: break-word which are somewhat broken in Edge with the new text layout engine because we now properly support break-all on inlines, so I guess those sites were already broken in Firefox in the past. The only way to fix them would be to support break-word so we might end up doing just that.

[morrisonlevi]

@fantasai PHP.net is okay with breaking words, which is sometimes necessary in other places. It's just in this case it is odd (at least to me) that it was chosen to break the words instead of shrink the last column. I believe _ is not considered to be a character that would break a word, correct? Maybe we need to be adding <wbr/> tags around the underscores when rendering them.

The new behavior seems better generally, just not in this case.

[css-meeting-bot]

The Working Group just discussed Having overflow-wrap: break-word affect min-content size is not webcompatible, and agreed to the following:

• RESOLVED: Try a new rule in UA stylesheet and see how it impacts rate of bugs for FF then come back to this

The full IRC log of that discussion

<dael> Topic: Having overflow-wrap: break-word affect min-content size is not webcompatible
<dael> github: https://github.com//issues/2951
<dael> xidorn: I put in change to make overflow-wrap:break-word to effect min content. We immediately got 4 bugs. fantasai suggested we can make table reset the overflow-wrap to normal which fixes 2 of them.
<dael> xidorn: I want to bring it to WG and see what we do next
<dael> florian: What are remaining 2? PHP manual thing was one?
<dael> florian: It looks like a strangely coded web page.
<dael> florian: What's last?
<dael> xidorn: I think fantasai and the [missed] said it was wrong use and we can ignore
<dael> dbaron: We're talking about 4 bugs and it's on the nightly channel
<dael> fantasai: I'm not sure what to do. I think alternatives are terrible and web compat is a problem
<fantasai> s/and/but/
<dael> myles: We don't have a choice. 4 bugs on a nightly. Webcompat is more important
<dael> florian: I suggest we try the UA stylesheet change and see. If the change on tables solves the general problem maybe we're back. If not we have to do something else
<dael> frremy: My PoV I don't believe a quick change will fix. At MS we have other issues we're seeing where we'd like to reconsider word-break:break-word where we had websites change to break-all and Edge breaks in the middle. I know we supported not supporting it, but I'm becoming less convinced we can't. So supporting break-word is an option on the table. We should consider that as a part of this
<dael> fantasai: WE have someone from PHP engaging on issue. Example where table is not breaking, behavior they want ideally is that you have 2 types of min-content? They want table to wrap at normal word breaks but not in overflow wrap cases unless it's necessary. If you look at example there is text that could wrap more without breaking code words and they expect those breaks take priority.
<dael> fantasai: Not sure where to go with that, but it occurred to me that we're not handling that type of prioritization correctly in general
<dael> florian: So I felt we did find 4 bugs and if we fix UA we fix 2 and the other bugs were different
<dael> dbaron: Does the fix break what the sites were intending?
<dael> fantasai: Sites broken intended to not apply inside the table.
<dael> dbaron: I think you need to be careful on intent. A lot of sites might have waned current behavior where it allows long content to break
<dael> florian: Tables doesn't do that
<dael> dbaron: Okay
<dael> dbaron: b/c changes min-content
<dael> florian: Right, so table won't shrink to where it could break
<dael> fantasai: [sigh]
<dael> florian: I'd like Moz to try the UA stylesheet fix and see where that gets us. Maybe not enough, but good to check.
<dael> florian: If that doesn't break the web more it proides a clean path for new authors and maybe on top of that we still need word-break:break-word for frremy's reasons
<dael> fantasai: Idea case maybe is that...One case was someone put content in a 0 width continer and said I'd like you to word-break:break-word but shrink wrap took effect so it didn't. Other cases it seems there's multi levels of prioritization where we have 2 and authors would like 3. That's a big thing to think about.
<dael> fantasai: Overflow-wrap breaks are deprioritized in terms of when we accept the break. We're not able to deprioritize in terms of min-content width.
<dael> fantasai: For word-break:break-word it's awful ergonomics for CSS to add it. Authors are already confused on breaking prop and what called
<dael> florian: That's why I think we should keep trying and maybe spec as a corner
<dael> fantasai: If we have toe revert this I'd prefer a keyword to overflow-wrap that's the same as break-word but also effects min-content like 'overflow-wrap-anywhere' that's the same as word-break:break-word but lets author consider like multiple properties. word-break:break-word and word-wrap:break-word can't be combined
<dael> myles: Have we veered from original topic?
<dael> fantasai: Going back to this one
<dael> fantasai: I think it would be interesting to see if adding UA stylesheet rule would make it tolerably compat, but I'm not an impl so I'm not qualified to have an opinion for how that would be as an experiment.
<dael> astearns: Given we don't have clear solution I think trying this in browser stylesheet and getting more data is reasonable next step
<dael> florian: Might not be enough but good start
<dael> astearns: xidorn and dbaron sound good to try?
<dael> xidorn: I think we can try that. Easy enough to add it
<dael> astearns: Objections to Try a new rule in UA stylesheet and see how it impacts rate of bugs for FF?
<dael> RESOLVED: Try a new rule in UA stylesheet and see how it impacts rate of bugs for FF then come back to this