I created an example reproducing the issue. http://codepen.io/anon/pen/rezVVo You can see the difference in different browsers. Opening an issue here just in case we think there is something that should be fixed (Maybe not). It was initially raised on webcompat.com (see screenshots there) https://webcompat.com/issues/2397

Maybe something for Jonathan

(In reply to Karl Dubost :karlcow from comment #0) > You can see the difference in different browsers. Can you be more specific? Your codepen looks essentially the same to me in Firefox 48, Chrome 51, and Edge 13.

(Also: despite this bug's summary, I don't think there are any interactions between "hyphens: auto" and "word-break: break-all" at all. The left part of the codepen renders the same if I remove "hyphens: auto" styling. So the eager wrapping there is simply from "word-break:break-all" doing its thing and allowing breaks anywhere at all.)

Yes that's the interaction I'm talking about. Both are acting on long lines and seeing this two properties .foo { word-break:break-all; hyphens: auto; } .bar { hyphens: auto; word-break:break-all; } I would have a tendency to think that these too should have a different behavior. aka the last property being the one winning on the previous one. because hyphens do not really make sense anymore on a line which is breaking everywhere or maybe there is a use case I don't see. :)

> Can you be more specific? Your codepen looks essentially the same to me in Firefox 48, Chrome 51, and Edge 13. grmph. for sure if I fail to reproduce the code from the site. http://codepen.io/anon/pen/rezVVo Here the attachment on Safari

I still don't see anything unexpected here. word-break:break-all allows breaking between any two letters, so there's no call for hyphenation to even be attempted; the hyphens property is then irrelevant. Note that word-break:break-word is a non-standard webkit thing, not part of the spec.[1] So that declaration in your .breakall class is simply dropped by firefox. But in safari, it results in behavior similar to word-wrap:break-word,[2] but it ALSO overrides the earlier break-all. So your comparison isn't really meaningful; when viewed in webkit, the .breakall class does not actually have word-break:break-all at all. [1] https://www.w3.org/TR/css-text-3/#word-break-property [2] http://caniuse.com/#feat=word-break

Ah it seems I have difficulties to explain what troubles me. Right now in Webkit/Blink world word-break: break-all; word-break: break-word; <- wins. So hyphenation is taking place. hyphens: auto; <- or this one. It doesn't matter. In Gecko world word-break: break-all; <- wins word-break: break-word; no supported by moz. hyphens: auto; <- ignored. No hyphenation is happening. (As you said: "word-break:break-all allows breaking between any two letters, so there's no call for hyphenation to even be attempted;") Then rendering difference when hyphenation was expected by the designer. Note: I think we should outreach them, it's why I didn't close the webcompat issue. Now feel free to close this one. :) My inner voice tells me we should honor the hyphens and not the word-break: break-all, but I don't have a strong rationale for it.

A couple of things: first, looking again at your codepen, I notice that it lacks a lang tag, which means hyphens:auto is not actually doing anything -- the hyphenation you're seeing is just from the manually-inserted &shy; entities, and would be present even with the (default) hyphens:manual value. Add lang="en" to the outer <div> to make the example do was intended. Second, ignoring word-break:break-all if hyphens:auto is specified can't really be considered. break-all is primarily intended for CJK use cases, where they really do want to break between any letters, wherever the line happens to end. hyphens:auto may or may not be able to find a useful break point in any given word (even once the right lang is specified); there may still be cases where a long word won't fit and can't be broken. So it doesn't make break-all unnecessary for the case where the author wants all lines equally filled. Re: > word-break: break-all; <- wins > word-break: break-word; no supported by moz. > hyphens: auto; <- ignored. No hyphenation is happening. which doesn't behave the same in gecko vs webkit (true, but that's because of webkit's non-standard behavior, not a gecko bug)... it would make more sense, I think, for the author to say: word-wrap: break-word; hyphens: auto; so that hyphenation will be used where possible, but if an unhyphenatable word exceeds the available column width, it will be broken rather than overflow. (Note that word-wrap is renamed to overflow-wrap in the latest CSS Text draft, but gecko hasn't made that change yet.)

(In reply to Karl Dubost :karlcow from comment #7) > Now feel free to close this one. :) I'll take you up on this. :) AFAICT, we're following what the spec requires here, and we're behaving exactly like every other browser, except for the fact that we don't support a particular legacy webkit property-value.

(And as jfkthame said, "word-wrap: break-word" (note "word-wrap", not "word-break") is really what authors are really looking for, when they type CSS like the CSS in karl's codepen. See https://webcompat.com/issues/1671#issuecomment-155247294 for more on this.)