Closed fantasai closed 5 years ago
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.
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.
word-wrap/overflow-wrap
affects the display effect of the text,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 ?
@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.
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
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
@fantasai It will pass test? https://jsfiddle.net/ofgd83um/53/
@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.)
(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 You are wrong. Box 6. overflow-wrap: break-word;
should look like 4. word-break: break-word
(on Chrome/Chromium or others blink/webkit engines), not like 2. word-break: break-all
.
overflow-wrap: break-word
should break word only if it's necessary to "hold" layout in correct state, like working word-break: break-word
on Chrome/Chromium (and others blink/webkit engines). break-word
its not break-all
@CShepartd I didn't say that it would look like Box 2, only that it should have the same width.
Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1472386 Chromium issue: https://bugs.chromium.org/p/chromium/issues/detail?id=862127
Since we have Web-compat blocking this proposal (see #2682), it seems like we have to re-visit this issue. The use case remains valid, so we should definitely have some kind of syntax to trigger it.
IMHO the ideal solution would be to add a second keyword to overflow-wrap
, maybe overflow-wrap: anywhere
to mirror line-break: anywhere
. This keeps these two related values together in one property that controls secondary line-breaking opportunities.
(line-break
and word-wrap
currently only control primary line-breaking opportunities, i.e. ones that are preferred/considered normal.)
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.
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?
@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
@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.
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:
overflow-wrap: anywhere
is actually a pretty reasonable name for what it does: it lets the line wrap anywhere when there would be overflow.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).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.
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
overflow-wrap: anywhere
solving very well problem of missing word-break: break-word
https://jsfiddle.net/ofgd83um/80/
See https://github.com/w3c/csswg-drafts/issues/2270#issuecomment-390053485 and https://github.com/w3c/csswg-drafts/issues/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 abreak-word
value toword-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
andword-break: break-word
compounding the situation. Also I suspect that making the already-existingword-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.