[css-text] Prevent line break after hyphen preceded by space

[valtlai]

I want to prevent a line break after a hyphen that is preceded by a space.

So a string like

foo bar -baz

can be broken as

foo bar
-baz

but not

foo bar -
baz

I’m not sure if this can be solved by CSS spec (e.g., a new keyword for hyphens or overflow-wrap, etc.) or if it’s a browser bug: Firefox does like described by default, Chrome doesn’t.

(Demo: https://codepen.io/valtlai/pen/WLRjeo/left/?editors=1100)

Another example

String: ``` foo -webkit-baz ``` Allowed: ``` foo -webkit- baz ``` Disallowed: ``` foo - webkit-baz ```

[AmeliaBR]

I have this problem all the time with -prefixed-css-properties! But I would consider it a browser bug. The browsers have a lot discretion in determining line-breaking positions. But whoever wrote that code in certain browsers clearly didn't consider this case.

The only reason to add CSS control would be if there was a situation where you would want the line to leave an initial hyphen hanging on its own.

[AmeliaBR]

Related to the discussion in https://github.com/w3c/csswg-drafts/issues/3434#issuecomment-448726726

[fantasai]

https://www.w3.org/TR/css-text-3/#line-break-details

UAs that allow wrapping at punctuation other than spaces should prioritize breakpoints. (For example, if breaks after slashes are given a lower priority than spaces, the sequence "check /etc" will never break between the "/" and the "e".) As long as care is taken to avoid such awkward breaks, allowing breaks at appropriate punctuation other than spaces is recommended, as it results in more even-looking margins, particularly in narrow measures. The UA may use the width of the containing block, the text’s language, and other factors in assigning priorities: CSS does not define prioritization of line breaking opportunities.

[fantasai]

Agree with @AmeliaBR that this is a quality-of-implementation issue. I think the spec clearly expects the behavior you're expecting; but we could maybe benefit from a testcase.

[fantasai]

Committed https://github.com/w3c/csswg-drafts/commit/4789b41c2b2dec71f9dac8cc08f5c2eb98860b2a to clarify that

• prioritization applies to all word separators, not just spaces
• prioritization of word separators is not expected for word-break: break-all
• included line-break in list of factors suggested for consideration of prioritization rules
• noted that prioritization is forbidden when line-break: anywhere is specified (This is clearly specified under the definition of anywhere, but it seemed useful to point out here as well.)

I think that should help with drawing up tests here. Marking Agenda+ for review as we are in Last Call. Otherwise I think this issue is closed, spec-wise.

[css-meeting-bot]

The CSS Working Group just discussed Prevent line break after hyphen preceded by space, and agreed to the following:

• RESOLVED: accept these changes for text L3

The full IRC log of that discussion

<dael> Topic: Prevent line break after hyphen preceded by space
<dael> github: https://github.com/w3c/csswg-drafts/issues/3463#issuecomment-450522790
<dael> fantasai: This is [space]-foo and don't break before hyphen
<dael> fantasai: I added clarifications because there were points missing. Prioritization shoudl apply to all word separators. Second was clarify prioritization isn't expected for word-break:break-all
<dael> fantasai: Added you're allowed to consider a bunch of factors, there's no limit but have a list of things you should consider. Added a note that says prioritization forbidden when there's line-break:anywhere. That's already stated in line-break:anywhere
<dael> fantasai: Wanted to check WG is okay with changes
<dael> florian: Okay with changes, not sure they solve issue. I suppose hyphen is punct. but it seems worth mentioning explicitly. Even if you don't break around a / we do at hyphen
<dael> fantasai: Have same problem with /. Have same with ".
<dael> florian: Do people allow break around / and "?
<dael> fantasai: Some allow break after a /. This is why it says SHOULD
<dael> fantasai: I don't think we can define all exceptions we want people to follow. There's a lot of information in different sources. We can't dictate everything
<dael> astearns: Given issue was opened on hyphen it would be nice to have an example of a break to avoid with a hyphen to go along with break to avoid after a /
<dael> fantasai: Can add an example
<dael> myles_: These subjective choices should be made in a lang and local specific way
<dael> fantasai: Right
<dael> astearns: True and section does mention writing systems
<dael> florian: You said people break around /. FF doesn't. I tihnk that's what makes hyphen different. People do wrap after hyphen
<dael> fantasai: Sometimes it's appropriate
<dael> florian: Is when hyphen starts word
<dael> fantasai: space hyphen Chinese character, do we forbid that? I can't define every rule for every system
<dael> dauwhe: My company has people who spend their day worrying about these things and it's highly contextual
<dael> myles_: I'm happy with should
<dael> astearns: I'm falling against additional examples b/c we can't go through all bits of context to consider
<dael> astearns: Other comments on these changes?
<dael> astearns: Objections to accept these changes for text L3?
<dael> RESOLVED: accept these changes for text L3

[valtlai]

Chromium issue: https://crbug.com/974470

[valtlai]

Chromium issue: https://crbug.com/974470

This is marked as WontFix. Is this an issue with Unicode?

[frivoal]

@valtlai Maybe but not necessarily. Chrome can fix this if they want to, with the specs as they are today. The specs aren't precise enough to require that behavior, but they allow it, and this kind of refinement is expected from good quality implementations. If Chrome wants to fix this case only if the Unicode spec requires them to, then asking Unicode to change is a possible path forward. Convincing Chrome that they should change with the specs as they are is another one. No strong opinion as to which is more likely to be successful.