- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 May 2018 16:57:50 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `word-wrap/overflow-wrap: break-word should affect min-content`, and agreed to the following: * `RESOLVED: Accept the proposal in Issue #2682` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: word-wrap/overflow-wrap: break-word should affect min-content<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/2682<br> <dael> fantasai: Issue is that...there's a number of cases where authors are fustrated with elements being bigger then they ought to be. Some are because they put overflow:scroll. Other set are related to I thought I told the text to be able to wrap if it needs to, why is element so big<br> <dael> fantasai: That's the word-wrap/overflow-wrap:break-word which doesn't effect min-content.<br> <dael> fantasai: There was discussion about word-break:break-word from webkit that does effect intrinisic size. We decided we wouldn't add that unless FF or Edge said they needed<br> <florian> q+<br> <dael> fantasai: proposal is to solve several things. Give the authors the behavior that they're expecting so content can shrink down in the way they expect since right now if you're auto sizing the width is too big to break. It also means we can address reasons for the other syntax existing without adding the other syntax.<br> <florian> q-<br> <dael> fantasai: Having the syntactic mess is an awful situation to get in.<br> <dael> florian: Cannonical example is when there is a piece of text in a table cell with a long word and the put the overflow-wrap:break-word and the word stays long.<br> <dael> fantasai: It's prob getting more frustrating because effects min-content in grid or flexbox. You put a URL in and say you can break, but it pushes out 1fr column for no good reason. It's not just in table cells. Flexbox and grid are relying on the min-content size.<br> <dael> florian: Overall if we can do this it's a good idea. Can we or do we break compat with negative effects? I'm not too pessimistic but want to make sure<br> <dael> fantasai: It's a concern in general, but I think there's enough cases where changing behavior gets authors to where they want more then it breaks. Cases that will break is when you set overflow-wrap to a place where it allows breaking but then you're not expecting a break.<br> <dael> fantasai: Most layouts aren't dependent on longest word. They asked for wrapping. I think more likely to fix then to break.<br> <dael> ??: Seems fair<br> <dael> Rossen: To be clear blink and webkit have this?<br> <dael> fantasai: Under a different syntax. We've pushed back on adding that syntax. Only difference between is how the effect intrinisic sizing. It's small but super confusing for authors. Even if they weren't syntactically similar it's still confusing to think in terms of intrinsic size<br> <dael> Rossen: word-wrap:break-word you take all breaking content?<br> <dael> fantasai: Just in min size<br> <dael> florian: word-break controls other things as well, so with word-break:break-word you can't do that. With this appoarch you could.<br> <dael> Rossen: Just wanted to clarify expectations<br> <dael> Rossen: Other opinions? Sounds reasonable way forward. Have to see what interop looks like<br> <dael> Rossen: Or compat risk rather<br> <dael> florian: Yeah<br> <dael> fantasai: Yeah<br> <dael> fantasai: Authors will be happy if we fix this. This is a major source of frustration with grid and flexbox. Sometimes allowing breaks...things get too big<br> <dael> Rossen: I'm with you.<br> <tantek> +1 [CSS is awe]some<br> <dael> Rossen: I'm mostly worried about older content in tables and whatnot out in the wild. All the sudden we introduce an adverse effect. But I'll let blink and webkit engineers spearhead since they have this behavior.<br> <dael> Rossen: Objections?<br> <dael> RESOLVED: Accept the proposal in Issue #2682<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2682#issuecomment-391422844 using your GitHub account
Received on Wednesday, 23 May 2018 16:57:54 UTC