Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-text-3] word-wrap/overflow-wrap: break-word should affect min-content #2682

Closed
fantasai opened this issue May 19, 2018 · 21 comments

Comments

Projects
None yet
9 participants
@fantasai
Copy link
Collaborator

commented May 19, 2018

See #2270 (comment) and #2390 //cc @Dan503

Right now word-wrap/overflow-wrap: break-word allows long words to wrap if they are too long to fit in the container, but in an auto-sized container, they will still force the container to grow. This is frustrating to authors. Issue 2390 is about adding a break-word value to word-break to address this feature (because WebKit/Blink happen to have implemented such a thing), but then we end up with two extremely similar-looking property-value pairs that do almost exactly the same thing except for this side-effect of how they influence the min-content size.

The number of line-breaking controls in CSS is already crazy confusing; we really don't need to have the similarity between word-wrap: break-word and word-break: break-word compounding the situation. Also I suspect that making the already-existing word-wrap: break-word influence min-content sizes is a reasonable thing to do regardless: it can't do its job of allowing breaking if the container is forced to fit the thing that it's trying to break anyway.

So the proposal is to make the existing word-wrap/overflow-wrap property affect intrinsic sizing and, hopefully, also close #2390 as no change.

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented May 19, 2018

If we can do that, I am totally in support. But can we? Assessing web compat on this seems tricky.

I am reasonably convinced that anyone who intentionally combines overflow-wrap:break-word and shrinkwrapping (or some other sizing that depends on min-content) would be positively affected by this change, but it's the non intentional uses that I'm worried about.

@anjia

This comment has been minimized.

Copy link

commented May 22, 2018

So the proposal is to make the existing word-wrap/overflow-wrap property affect intrinsic sizing

Yeah, I agree with it because that's reasonable, and the behavior is logical in my opinion.

  1. word-wrap/overflow-wrap affects the display effect of the text,
  2. then the text affects the intrinsic sizing

As for the point ... but it's the non intentional uses that I'm worried about @frivoal mentioned, it's indeed a problem. But I think may be ... developers could forgive this change as they indeed wrote the word-wrap/overflow-wrap property which can affect the text ?

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented May 23, 2018

@anjia authors who think about it would probably be fine. Existing pages which are already deployed, aren't maintained, and apply overflow-wrap:break-spaces to intrinsically sized things for no good reason might suddenly look weird, and users would be unhappy. I don't think that particular type of breakage is likely to be that common, but what we need to worry about is its effects on users, rather than on the mood of developers.

I think that most likely we'll be fine, and if so this is a great way out of the current mess.

@anjia

This comment has been minimized.

Copy link

commented May 23, 2018

but what we need to worry about is its effects on users, rather than on the mood of developers.

@frivoal yeah, you're right. This thought refreshes my responsibility as a csswg member. Thanks very much

@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented May 23, 2018

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
The full IRC log of that discussion <dael> Topic: word-wrap/overflow-wrap: break-word should affect min-content
<dael> github: https://github.com//issues/2682
<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
<dael> fantasai: That's the word-wrap/overflow-wrap:break-word which doesn't effect min-content.
<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
<florian> q+
<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.
<florian> q-
<dael> fantasai: Having the syntactic mess is an awful situation to get in.
<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.
<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.
<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
<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.
<dael> fantasai: Most layouts aren't dependent on longest word. They asked for wrapping. I think more likely to fix then to break.
<dael> ??: Seems fair
<dael> Rossen: To be clear blink and webkit have this?
<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
<dael> Rossen: word-wrap:break-word you take all breaking content?
<dael> fantasai: Just in min size
<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.
<dael> Rossen: Just wanted to clarify expectations
<dael> Rossen: Other opinions? Sounds reasonable way forward. Have to see what interop looks like
<dael> Rossen: Or compat risk rather
<dael> florian: Yeah
<dael> fantasai: Yeah
<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
<dael> Rossen: I'm with you.
<tantek> +1 [CSS is awe]some
<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.
<dael> Rossen: Objections?
<dael> RESOLVED: Accept the proposal in Issue #2682
@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Jun 6, 2018

I've made PRs for the spec and wpt:

@CShepartd

This comment has been minimized.

Copy link

commented Jun 26, 2018

@fantasai

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 30, 2018

@CShepartd That test doesn't have a pass condition, but what should happen is that the Box 6 will have the same width as Box 2. (The word-break: break-word declaration for 4 would be invalid, so it will render the same as 1.)

@fantasai

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 30, 2018

(Note that overflow-wrap and word-wrap are the same property--they enable breaking when it's not “normal” if the text won't fit otherwise--so either one will work. But word-break won't because that's a different property.)

fantasai added a commit that referenced this issue Sep 16, 2018

[css-text-3] Revert change to make word/overflow-wrap: break-word aff…
…ect intrinsic sizing due to web-compat. #2951 #2682

This reverts commit 18e77c3.
@Dan503

This comment has been minimized.

Copy link

commented Sep 16, 2018

I don't think overflow-wrap: anywhere is the right term. It makes it sound more like the word-wrap: break-all logic.

I think overflow-wrap: break-min is a closer representation of what the point of the keyword is. break-min more explicitly tells the user that they are breaking the rules around min-content for that element.

Is the goal with this new syntax to only set min-content to zero regardless of what content is inside it? or are we trying to make a single keyword do 2 things, set min-content to zero and also apply word-break functionality?

I think it would be best to go with some sort of syntax that only does the one thing of setting the width of min-content to zero and have a separate bit of CSS control how the text wraps.

@kojiishi

This comment has been minimized.

Copy link
Contributor

commented Sep 18, 2018

Somewhere someone mentioned that authors do today:

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

so they can get at least break-all behavior if break-word is not supported. From web-compat perspective, moving this value to other properties will break these pages, right?

@CShepartd

This comment has been minimized.

Copy link

commented Sep 21, 2018

@kojiishi word-break: break-all mean to break in any point, word-break: break-word mean to break only if it's necessary to keep layout. Forcing create new will not break Web-compat but can make confusion like using proposed above line-break: anywhere and old word-break: break-all as one thing

@kojiishi

This comment has been minimized.

Copy link
Contributor

commented Sep 21, 2018

@CShepartd I'm sorry, I can't understand your second sentence. Can you explain a bit more?

I don't have opinion on this, if we want to challenge web-compat in another way, fine, but just wanted to make sure we're aware of the that.

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Oct 19, 2018

In summary, I think the best thing to do is to add a new value to overflow-wrap, probably called anywhere, that does the same thing as overflow-wrap: break-word, except it affects the intrinsic size.

This has the following advantages:

  • It is what overflow-wrap:break-word should always have done, even though we cannot change that due to compat
  • even though most of the properties and values related to line breaking are terribly named, overflow-wrap: anywhere is actually a pretty reasonable name for what it does: it lets the line wrap anywhere when there would be overflow.
  • The value name anywhere draws a parallel to line-break: anywhere, which is a good thing, since they allow the same breaks, the only difference being the priority (line-break allows the break always, overflow-wrap only when things would otherwise overflow).
  • It is possible to use overflow-wrap:anywhere in combination with the various i18n focused values of word-break, which is good because conceptually these are completely unrelated.

The alternative would be to specify the existing proprietary word-break:break-word. This is easiest since some implementations have it, but this value really does not belong in this property, so this is confusing to teach/learn and problematic to use, since it gets mixed with another property that has unrelated uses.

And if the compat situation is really bad (I think it might not be, given that Firefox and Edge have managed to resist the temptation to implement so far), we should probably just do both.

@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented Oct 22, 2018

The CSS Working Group just discussed word-wrap/overflow-wrap: break-word should affect min-content, and agreed to the following:

  • RESOLVED: Add an anywhere keyword to overflow-wrap
The full IRC log of that discussion <heycam> Topic: word-wrap/overflow-wrap: break-word should affect min-content
<heycam> github: https://github.com//issues/2682
<astearns> (summary: https://github.com//issues/2682#issuecomment-431503466 )
<heycam> florian: we have 2 things. we have overflow-wrap:break-word
<heycam> ... which says that if the line is too long, apply line breaking, if it still doesn't fit, break anywhere
<heycam> ... it doesn't affect intrinsic size
<heycam> ... if you have text in a table cell that says if i'm too long wrap anywhere, because teh table cell is sized to the intrinsic size
<heycam> ... same thing in flex boxes and some other situations
<heycam> ... we should have had overflow-wrap:break-word affect intrinsic size
<heycam> ... Mozilla found it's not web compatible to do that
<heycam> ... WebKit an Chrome have that switch, which doesn't the same thing as overflow-wrap:break-word plus intrinsic sizing, but it's on the wrong property
<heycam> ... the word-wrap property
<heycam> ... so there is some web compat pressure, but not an overwhelming amount, since even tho we've been talking about this for a while, both Edge and Firefox have resisted implementing it
<heycam> ... given that overflow-wrap:break-word should have done the right thing, we should add a new value that does so
<heycam> ... overflow-wrap:anywhere
<heycam> ... we already have an anywhere value in another overflow property
<heycam> ... line-break:anywhere allows it all the time, overflow-wrap:anywhere is only if you need to break
<heycam> ... maybe that will be enough and the web will slowly learn to use that rather than the WebKit thing
<heycam> ... if it turns out not to be the case, we should have both, rather than just breaks the property that otherwise makes sense
<heycam> eae: I agree with that
<fantasai> s/that/that, it makes sense to spec the right behavior and we would support that/
<heycam> florian: I propose we resolve on adding overflow-wrap:anywhere, we don't resolve on word-break:break-word, but only come back to that if web compat forces us to
<heycam> RESOLVED: Add an anywhere keyword to overflow-wrap
<heycam> myles: are overflow-wrap / word-wrap no longer going to be synonyms?
<heycam> Rossen: no they are

fantasai added a commit that referenced this issue Oct 23, 2018

[css-text-3] Add 'overflow-wrap: anywhere' with 'break-word' semantic…
…s except that the break opportunities *are* considered when calculating min-content. #2682 (comment)

@frivoal frivoal self-assigned this Oct 28, 2018

@frivoal frivoal closed this Nov 1, 2018

@emilio

This comment has been minimized.

Copy link
Collaborator

commented Nov 8, 2018

moz-wptsync-bot added a commit to web-platform-tests/wpt that referenced this issue Nov 9, 2018

Implement overflow-wrap: anywhere.
Per w3c/csswg-drafts#2682

Differential Revision: https://phabricator.services.mozilla.com/D11328

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1505786
gecko-commit: 9a315872bd6d11ac42871b083961a00fa53ee753
gecko-integration-branch: autoland
gecko-reviewers: xidorn, jfkthame

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Nov 9, 2018

moz-wptsync-bot added a commit to web-platform-tests/wpt that referenced this issue Nov 9, 2018

Implement overflow-wrap: anywhere.
Per w3c/csswg-drafts#2682

Differential Revision: https://phabricator.services.mozilla.com/D11328

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1505786
gecko-commit: 9a315872bd6d11ac42871b083961a00fa53ee753
gecko-integration-branch: autoland
gecko-reviewers: xidorn, jfkthame

emilio added a commit to emilio/servo that referenced this issue Nov 10, 2018

emilio added a commit to emilio/servo that referenced this issue Nov 10, 2018

@CShepartd

This comment has been minimized.

Copy link

commented Nov 14, 2018

overflow-wrap: anywhere solving very well problem of missing word-break: break-word https://jsfiddle.net/ofgd83um/80/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.