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-break: break-all doesn't break before sentence-ending punctuation if UAX #14 is used #1171

Closed
littledan opened this Issue Apr 5, 2017 · 25 comments

Comments

Projects
None yet
7 participants
@littledan

littledan commented Apr 5, 2017

word-break: break-all is specified as:

Breaking is allowed within “words”: in addition to normal soft wrap opportunities: specifically, any typographic character units resolving to the NU (“numeric”), AL (“alphabetic”), or SA (“Southeast Asian”) line breaking classes [UAX14] are instead treated as ID (“ideographic characters”) for the purpose of line-breaking. Hyphenation is not applied. This option is used mostly in a context where the text consists predominantly of CJK characters with only short non-CJK excerpts, and it is desired that the text be better distributed on each line.

For layout implementations based on UAX 14, this tailoring doesn't affect code points like "." (FULL STOP), which is categorized as IS. In UAX 14,

When not used in a numeric context, infix separators are sentence-ending punctuation. Therefore they always prevent breaks before.

This is codified in later text, where LB13 specifies not breaking before IS, and breaking around ideographs is specified by LB31 (break everywhere else), which is at a lower precedence.

The result seems a little counter-intuitive. I would've expected word-break: break-all to break in the middle of a long string of ., for example, but it seems like it is specified to not do this. Was this the intended behavior?

Dumb, higher-level question: why doesn't word-break: break-all break at all grapheme boundaries?

cc @frivoal

@mrego mrego added the css-text-3 label Apr 5, 2017

@kojiishi

This comment has been minimized.

Show comment
Hide comment
@kojiishi

kojiishi Apr 5, 2017

Contributor

higher-level question: why doesn't word-break: break-all break at all grapheme boundaries?

Because this value was designed for a use case in East Asia to break non-East Asian (e.g., Latin) words at every character boundary, but then many non-East Asian authors found it's useful for other purposes. The naming was unfortunate. You might also found that this value is not interoperable, which is also unfortunate.

We could add a new value if implementers agree to implement. Could you tell us your use case? In what case you want to break between two FULL STOPs, and isn't it sufficed by break-word instead?

Contributor

kojiishi commented Apr 5, 2017

higher-level question: why doesn't word-break: break-all break at all grapheme boundaries?

Because this value was designed for a use case in East Asia to break non-East Asian (e.g., Latin) words at every character boundary, but then many non-East Asian authors found it's useful for other purposes. The naming was unfortunate. You might also found that this value is not interoperable, which is also unfortunate.

We could add a new value if implementers agree to implement. Could you tell us your use case? In what case you want to break between two FULL STOPs, and isn't it sufficed by break-word instead?

@littledan

This comment has been minimized.

Show comment
Hide comment
@littledan

littledan Apr 5, 2017

@kojiishi Just curious, do East Asian use cases not want to break between consecutive . characters? What's break-word?

littledan commented Apr 5, 2017

@kojiishi Just curious, do East Asian use cases not want to break between consecutive . characters? What's break-word?

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Apr 6, 2017

Contributor

Just curious, do East Asian use cases not want to break between consecutive . characters?

It depends why you have consecutive . characters. I would guess that the most common one is using three of them (...) instead of the ellipsis character (… U+2026). In that case, you do not want a break between the characters.
So you get

|どうでしょ   |
|う...      |

and not

|どうでしょう.|
|..         |

or

|どうでしょう.|..

What's break-word?

overflow-wrap: break-word
Makes it so that there can be linebreaks anywhere, including between a sequence of "." if things would otherwise overflow.

That last part means it is probably not what you're after, because what it will do is:

|foo bar     |
|baz.........|
|.......     |

it doesn't need to break between the periods to prevent the first line from overflowing, as breaking between baz works as well. It does need to break between the periods on the second line to prevent overflowing, so it does. If that's what you want, overflow-wrap: break-word

If what you want is this

|foo bar baz.|
|............|
|...         |

Then I think the only solution that matches the various specs is to put <wbr> between the periods.

Contributor

frivoal commented Apr 6, 2017

Just curious, do East Asian use cases not want to break between consecutive . characters?

It depends why you have consecutive . characters. I would guess that the most common one is using three of them (...) instead of the ellipsis character (… U+2026). In that case, you do not want a break between the characters.
So you get

|どうでしょ   |
|う...      |

and not

|どうでしょう.|
|..         |

or

|どうでしょう.|..

What's break-word?

overflow-wrap: break-word
Makes it so that there can be linebreaks anywhere, including between a sequence of "." if things would otherwise overflow.

That last part means it is probably not what you're after, because what it will do is:

|foo bar     |
|baz.........|
|.......     |

it doesn't need to break between the periods to prevent the first line from overflowing, as breaking between baz works as well. It does need to break between the periods on the second line to prevent overflowing, so it does. If that's what you want, overflow-wrap: break-word

If what you want is this

|foo bar baz.|
|............|
|...         |

Then I think the only solution that matches the various specs is to put <wbr> between the periods.

@karlrim

This comment has been minimized.

Show comment
Hide comment
@karlrim

karlrim Apr 10, 2017

Sometimes people just might type a few periods like.... um....
In my case I'm writing a text editor with a fixed layout and number of max characters, like a 60x15 grid of characters. We have business reasons for this. In any case when the text wraps unexpectedly, it throws off our layout and simply looks bad. Adding <wbr> between the periods as well as any other punctuation that might cause this wrapping is doable but a pain to implement.

In other browsers like FireFox, the break occurs on the period character and to me seems to work more naturally. It's hard for me to imagine why anyone would WANT the break to occur between the last two letters instead of the periods.
If the issue is interfering with existing behavior, is it possible to introduce some new break setting to insure the break occurs at the last character no matter what the character is?

karlrim commented Apr 10, 2017

Sometimes people just might type a few periods like.... um....
In my case I'm writing a text editor with a fixed layout and number of max characters, like a 60x15 grid of characters. We have business reasons for this. In any case when the text wraps unexpectedly, it throws off our layout and simply looks bad. Adding <wbr> between the periods as well as any other punctuation that might cause this wrapping is doable but a pain to implement.

In other browsers like FireFox, the break occurs on the period character and to me seems to work more naturally. It's hard for me to imagine why anyone would WANT the break to occur between the last two letters instead of the periods.
If the issue is interfering with existing behavior, is it possible to introduce some new break setting to insure the break occurs at the last character no matter what the character is?

@frivoal frivoal added the Agenda+ label Apr 11, 2017

@frivoal frivoal self-assigned this Apr 11, 2017

@kojiishi

This comment has been minimized.

Show comment
Hide comment
@kojiishi

kojiishi Apr 11, 2017

Contributor

It's hard for me to imagine why anyone would WANT the break to occur between the last two letters instead of the periods.

That's what some writing systems want, I understand it's unlikely for Latin writing systems though.

I'm fine to add a new value, like break-any if desired. What to do with spaces might be needed to discuss, and maybe controversial. Do you want, when a space appear beyond the end of line, the space appear at the beginning of the next line? That's what most terminal programs do, but text editors seem to vary.

Note, this test page tells which combinations of characters can prevent breaks (though there's a bit more complex logic is performed than the combination of two adjacent characters.)

Contributor

kojiishi commented Apr 11, 2017

It's hard for me to imagine why anyone would WANT the break to occur between the last two letters instead of the periods.

That's what some writing systems want, I understand it's unlikely for Latin writing systems though.

I'm fine to add a new value, like break-any if desired. What to do with spaces might be needed to discuss, and maybe controversial. Do you want, when a space appear beyond the end of line, the space appear at the beginning of the next line? That's what most terminal programs do, but text editors seem to vary.

Note, this test page tells which combinations of characters can prevent breaks (though there's a bit more complex logic is performed than the combination of two adjacent characters.)

@kojiishi

This comment has been minimized.

Show comment
Hide comment
@kojiishi

kojiishi Apr 11, 2017

Contributor
Value When Break At Preferred Width
word-break: break-all Anytime Except certain punctuation Same as line break
word-break: break-any Anytime Anywhere Same as line break
word-break: break-word If no other break opportunities Anywhere Same as line break
overflow-wrap: break-word If no other break opportunities Anywhere Compute using normal break

So maybe the space behavior should match to the one of break-word.

Contributor

kojiishi commented Apr 11, 2017

Value When Break At Preferred Width
word-break: break-all Anytime Except certain punctuation Same as line break
word-break: break-any Anytime Anywhere Same as line break
word-break: break-word If no other break opportunities Anywhere Same as line break
overflow-wrap: break-word If no other break opportunities Anywhere Compute using normal break

So maybe the space behavior should match to the one of break-word.

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Apr 11, 2017

Contributor

@kojiishi Do you know of any place where work-break: break-word is defined? I know it exists in some implementations, but it is non standard and I don't understand it well. (Also, I thought the implementations where it exists where trying to remove it. How's that going?)

Also, I wonder what this proposed break-any is supposed to do with &nbsp;, 'WORD JOINER' (U+2060), etc. If we can all agree that it should break everything all the time, then the value is probably justified. If the answer ends up being "it depends", maybe we need a different custom control, rather than an ever expanding list of break-sometimes, break-often, break-usually… keywords

Contributor

frivoal commented Apr 11, 2017

@kojiishi Do you know of any place where work-break: break-word is defined? I know it exists in some implementations, but it is non standard and I don't understand it well. (Also, I thought the implementations where it exists where trying to remove it. How's that going?)

Also, I wonder what this proposed break-any is supposed to do with &nbsp;, 'WORD JOINER' (U+2060), etc. If we can all agree that it should break everything all the time, then the value is probably justified. If the answer ends up being "it depends", maybe we need a different custom control, rather than an ever expanding list of break-sometimes, break-often, break-usually… keywords

@kojiishi

This comment has been minimized.

Show comment
Hide comment
@kojiishi

kojiishi Apr 11, 2017

Contributor

Do you know of any place where work-break: break-word is defined?

IIRC we resolved to add, but the spec want updated yet, sorry, my bad.

We tried to remove, but sites did not agree due to different behavior on preferred width.

Contributor

kojiishi commented Apr 11, 2017

Do you know of any place where work-break: break-word is defined?

IIRC we resolved to add, but the spec want updated yet, sorry, my bad.

We tried to remove, but sites did not agree due to different behavior on preferred width.

@kojiishi

This comment has been minimized.

Show comment
Hide comment
@kojiishi

kojiishi Apr 11, 2017

Contributor

I wonder what this proposed break-any is supposed to do with...

I think it's best to make it the same as break-word, making "when" is the only difference.

If more controls are needed, we can extend further, but that should affect break-word too I think.

Contributor

kojiishi commented Apr 11, 2017

I wonder what this proposed break-any is supposed to do with...

I think it's best to make it the same as break-word, making "when" is the only difference.

If more controls are needed, we can extend further, but that should affect break-word too I think.

@kojiishi

This comment has been minimized.

Show comment
Hide comment
@kojiishi

kojiishi Apr 12, 2017

Contributor

There was a suggestion to add the new value to line-break property instead, so update the summary table.

Value When Break At Preferred Width
New desired behavior Anytime Anywhere Same as line break
line-break: auto/normal/strict/loose Anytime Language dependent[1] Same as line break
word-break: break-all Anytime Except certain punctuation (tests) Same as line break
word-break: break-word[2] Only if no other break opportunities Anywhere Same as line break
word-wrap/overflow-wrap: break-word Only if no other break opportunities Anywhere Compute using normal break

[1] Controls line break before/after East Asian letters, punctuation, symbols, and some common punctuation/symbols. ICU currently supports variants for Chinese, Japanese, and Finnish.
[2] Resolved to add (IIRC) but the spec not updated yet.

Contributor

kojiishi commented Apr 12, 2017

There was a suggestion to add the new value to line-break property instead, so update the summary table.

Value When Break At Preferred Width
New desired behavior Anytime Anywhere Same as line break
line-break: auto/normal/strict/loose Anytime Language dependent[1] Same as line break
word-break: break-all Anytime Except certain punctuation (tests) Same as line break
word-break: break-word[2] Only if no other break opportunities Anywhere Same as line break
word-wrap/overflow-wrap: break-word Only if no other break opportunities Anywhere Compute using normal break

[1] Controls line break before/after East Asian letters, punctuation, symbols, and some common punctuation/symbols. ICU currently supports variants for Chinese, Japanese, and Finnish.
[2] Resolved to add (IIRC) but the spec not updated yet.

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Apr 13, 2017

Contributor

Actually, I think there is another solution to this problem, which does not need anything new to be added to the spec.

white-space: pre;
overflow-wrap: break-word;

or depending on how you feel about breaks in consecutive runs of spaces maybe

white-space: pre;
overflow-wrap: break-word break-spaces;

That way, the fact that overflow-wrap:break-word only applies if there's no other break point is countered by the fact that white-space:pre has cancelled other break points.

So you would get

|foo bar baz.|
|............|
|...         |

@littledan, would this solve your problem, or does it have undesirable side effects?

Contributor

frivoal commented Apr 13, 2017

Actually, I think there is another solution to this problem, which does not need anything new to be added to the spec.

white-space: pre;
overflow-wrap: break-word;

or depending on how you feel about breaks in consecutive runs of spaces maybe

white-space: pre;
overflow-wrap: break-word break-spaces;

That way, the fact that overflow-wrap:break-word only applies if there's no other break point is countered by the fact that white-space:pre has cancelled other break points.

So you would get

|foo bar baz.|
|............|
|...         |

@littledan, would this solve your problem, or does it have undesirable side effects?

@karlrim

This comment has been minimized.

Show comment
Hide comment
@karlrim

karlrim Apr 13, 2017

@frivoal , I tried those settings however it doesn't cause the line to wrap. So I see this:

|foo bar baz.|......
|            |
|            |

karlrim commented Apr 13, 2017

@frivoal , I tried those settings however it doesn't cause the line to wrap. So I see this:

|foo bar baz.|......
|            |
|            |
@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Apr 13, 2017

Contributor

Strange. It does work in Safari, but not in other browsers. Safari does appear to be violating the spec, since overflow-wrap "only has an effect when white-space allows wrapping", but it seems to me that that is a more useful behavior, and since safari is shipping it, that's evidence that it is web compatible.

I'd love to have @fantasai 's take on this.

Contributor

frivoal commented Apr 13, 2017

Strange. It does work in Safari, but not in other browsers. Safari does appear to be violating the spec, since overflow-wrap "only has an effect when white-space allows wrapping", but it seems to me that that is a more useful behavior, and since safari is shipping it, that's evidence that it is web compatible.

I'd love to have @fantasai 's take on this.

@karlrim

This comment has been minimized.

Show comment
Hide comment
@karlrim

karlrim Apr 13, 2017

Well Firefox just wraps the characters regardless if it's punctuation or not. Every browser seems to violating the spec slightly. :-)

karlrim commented Apr 13, 2017

Well Firefox just wraps the characters regardless if it's punctuation or not. Every browser seems to violating the spec slightly. :-)

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Apr 14, 2017

Contributor

@karlrim Yes, there isn't full interop in this area. Which means its a good opportunity to figure out what behavior is desirable and make sure the spec says that, because once browsers will have converged, changing things will be much harder.

Contributor

frivoal commented Apr 14, 2017

@karlrim Yes, there isn't full interop in this area. Which means its a good opportunity to figure out what behavior is desirable and make sure the spec says that, because once browsers will have converged, changing things will be much harder.

@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Apr 20, 2017

Member

The CSS Working Group just discussed word-break: break-all doesn't break before sentence-ending punctuation if UAX #14 is used, and agreed to the following resolutions:

RESOLVED: put an issue in the spec for overflow: wrap to apply regardless of whitespace
RESOLVED: add line-break: break-all to the spec
The full IRC log of that discussion
<astearns> topic: word-break: break-all doesn't break before sentence-ending punctuation if UAX #14 is used
<astearns> github topic: https://github.com/w3c/csswg-drafts/issues/1171
<rachelandrew> florian: there are many variations on how to wrap text, one thing is wrap everywhere, get to the end of the line break and do a new one
<rachelandrew> florian: the main difference between this and word-break: break-all is that it allows wrapping points between letters but not punctuation
<rachelandrew> break between letters just like CJK
<rachelandrew> fantasai: this one is for Japanese
<rachelandrew> florian: this doesn't do what you want if you want the terminal wrapping
<rachelandrew> fantasai: right now the word-wrap property acts on letters and symbols not punctuation
<rachelandrew> the line-break property deals with punctuation rules
<rachelandrew> so we have logical separation of the two properties
<rachelandrew> adding a new value to word-break is weird as that isn't what it does
<rachelandrew> so we might want to add a value somewhere, maybe line-break: break-all
<rachelandrew> florian: the alt way to approach that is the overflow-wrap property, if things do overflow and you do overflow-wrap: break-word it allows the overflow to be anywhere
<rachelandrew> fantasai: overflow-wrap says pick some arbitrary place near the end of the word to wrap
<rachelandrew> florian: writes on the whiteboard
<rachelandrew> fantasai: so make overflow-wrap word regardless of the white-space value
<rachelandrew> it does make sense that overflow-wrap is allowed to apply as this is basically emergency breaking
<rachelandrew> we might also want to add a break-all value
<rachelandrew> we should add line-break: break-all and also make overflow wrap apply regardless of the white-space value
<rachelandrew> fantasai: I think that both behaviours are useful
<rachelandrew> koji: why do we need two things to do the same thing?
<myles__> rachelandrew: he is "koji"
<myles__> Ah ok you got it :)
<rachelandrew> fantasai: currently overflow-wrap can allow breaking or non-breaking of a word
<rachelandrew> this doesn't change your intrinsic sizing
<rachelandrew> the other properties actually change the line-breaking rules
<rachelandrew> I think the behaviour you would get for adding line-break is different to the behaviour you will get from overflow-wrap
<rachelandrew> we need a value that says break all, everthing. But we might also want to set the intrinsic size according to normal line breaking rules
<rachelandrew> koji; I think people want to change the intrinsic size, but not to change overflow behaviour
<rachelandrew> iank_ what about properties that override intrinsic sizes
<rachelandrew> fantasai: this is about how we calculate the size of overflow text
<rachelandrew> florian: we want t least one of the two
<rachelandrew> fantasai: we definitely need line-break: break-all
<rachelandrew> astearns: I have concerns about overflow
<rachelandrew> fantasai: I think we can resolve on the one, we should keep in mind the other question whether overflow should wrap regardless of white space
<rachelandrew> astearns: resolve to put an issue in the spec for overflow: wrap to apply regardless of whitespace
<astearns> RESOLVE: put an issue in the spec for overflow: wrap to apply regardless of whitespace
<astearns> RESOLVED: put an issue in the spec for overflow: wrap to apply regardless of whitespace
<rachelandrew> to add a value to line break that will say break anywhere with regards to punctuation
<rachelandrew> fantasai: then maybe add a shorthand to make this easier
<rachelandrew> fantasai: break-all is one possibility, anywhere is another possibility
<rachelandrew> koji: it's strange because line-break is a CJK property
<rachelandrew> fantasai: line-break is a property for different levels of punctuation strictness in different languages
<rachelandrew> florian: they forbid line breaking in various places
<rachelandrew> fantasai: word-break does letters and symbols, line-break does punctuation
<rachelandrew> astearns: so to get the terminal effect you would set line-break and word-break to break-all
<rachelandrew> koji: if we were to respond to original request it is easy, it is just to change one thing
<rachelandrew> break-anywhere is easy, break anywhere at punctuation is a new thing
<rachelandrew> myles_: we would implement it at the system level
<rachelandrew> webkit doesn't want to be in the business of understanding all this stuff
<myles__> fantasai: https://github.com/w3c/csswg-drafts/issues/1252
<rachelandrew> koji: in Android we define the priority of which to support and cut some of them
<rachelandrew> this new mechanism is more complex
<rachelandrew> fantasai: I think it would be worth finding out if the combination is needed in Chinese (don't break a Latin word but break punctuation anywhere)
<rachelandrew> florian: I think the Japanese style of document, do English words get broken
<rachelandrew> koji: it does get broken
<rachelandrew> fantasai: if we find out if we need to add it then we just need to pick a syntax
<astearns> action xidorn to see if the case where you break at punctuation but not through english words is used in Chinese
<trackbot> Error finding 'xidorn'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
<astearns> based on that result, solve this issue with break-line: break-all (that allows that) or with a solution that breaks everywhere including punctuation
<rachelandrew> fantasai: I'm leaning to the syntax being line-break: break-all
<rachelandrew> we have to pick a property, and line-break already effects some letters word-break does not deal with punctuation
<rachelandrew> astearns: can we resolve to put line-break: break-all in the spec for the purpose of the terminal use case, if it does that use case only or if it does it with the other property depends on investigation
<rachelandrew> RESOLVED: add line-break: break-all to the spec
Member

css-meeting-bot commented Apr 20, 2017

The CSS Working Group just discussed word-break: break-all doesn't break before sentence-ending punctuation if UAX #14 is used, and agreed to the following resolutions:

RESOLVED: put an issue in the spec for overflow: wrap to apply regardless of whitespace
RESOLVED: add line-break: break-all to the spec
The full IRC log of that discussion
<astearns> topic: word-break: break-all doesn't break before sentence-ending punctuation if UAX #14 is used
<astearns> github topic: https://github.com/w3c/csswg-drafts/issues/1171
<rachelandrew> florian: there are many variations on how to wrap text, one thing is wrap everywhere, get to the end of the line break and do a new one
<rachelandrew> florian: the main difference between this and word-break: break-all is that it allows wrapping points between letters but not punctuation
<rachelandrew> break between letters just like CJK
<rachelandrew> fantasai: this one is for Japanese
<rachelandrew> florian: this doesn't do what you want if you want the terminal wrapping
<rachelandrew> fantasai: right now the word-wrap property acts on letters and symbols not punctuation
<rachelandrew> the line-break property deals with punctuation rules
<rachelandrew> so we have logical separation of the two properties
<rachelandrew> adding a new value to word-break is weird as that isn't what it does
<rachelandrew> so we might want to add a value somewhere, maybe line-break: break-all
<rachelandrew> florian: the alt way to approach that is the overflow-wrap property, if things do overflow and you do overflow-wrap: break-word it allows the overflow to be anywhere
<rachelandrew> fantasai: overflow-wrap says pick some arbitrary place near the end of the word to wrap
<rachelandrew> florian: writes on the whiteboard
<rachelandrew> fantasai: so make overflow-wrap word regardless of the white-space value
<rachelandrew> it does make sense that overflow-wrap is allowed to apply as this is basically emergency breaking
<rachelandrew> we might also want to add a break-all value
<rachelandrew> we should add line-break: break-all and also make overflow wrap apply regardless of the white-space value
<rachelandrew> fantasai: I think that both behaviours are useful
<rachelandrew> koji: why do we need two things to do the same thing?
<myles__> rachelandrew: he is "koji"
<myles__> Ah ok you got it :)
<rachelandrew> fantasai: currently overflow-wrap can allow breaking or non-breaking of a word
<rachelandrew> this doesn't change your intrinsic sizing
<rachelandrew> the other properties actually change the line-breaking rules
<rachelandrew> I think the behaviour you would get for adding line-break is different to the behaviour you will get from overflow-wrap
<rachelandrew> we need a value that says break all, everthing. But we might also want to set the intrinsic size according to normal line breaking rules
<rachelandrew> koji; I think people want to change the intrinsic size, but not to change overflow behaviour
<rachelandrew> iank_ what about properties that override intrinsic sizes
<rachelandrew> fantasai: this is about how we calculate the size of overflow text
<rachelandrew> florian: we want t least one of the two
<rachelandrew> fantasai: we definitely need line-break: break-all
<rachelandrew> astearns: I have concerns about overflow
<rachelandrew> fantasai: I think we can resolve on the one, we should keep in mind the other question whether overflow should wrap regardless of white space
<rachelandrew> astearns: resolve to put an issue in the spec for overflow: wrap to apply regardless of whitespace
<astearns> RESOLVE: put an issue in the spec for overflow: wrap to apply regardless of whitespace
<astearns> RESOLVED: put an issue in the spec for overflow: wrap to apply regardless of whitespace
<rachelandrew> to add a value to line break that will say break anywhere with regards to punctuation
<rachelandrew> fantasai: then maybe add a shorthand to make this easier
<rachelandrew> fantasai: break-all is one possibility, anywhere is another possibility
<rachelandrew> koji: it's strange because line-break is a CJK property
<rachelandrew> fantasai: line-break is a property for different levels of punctuation strictness in different languages
<rachelandrew> florian: they forbid line breaking in various places
<rachelandrew> fantasai: word-break does letters and symbols, line-break does punctuation
<rachelandrew> astearns: so to get the terminal effect you would set line-break and word-break to break-all
<rachelandrew> koji: if we were to respond to original request it is easy, it is just to change one thing
<rachelandrew> break-anywhere is easy, break anywhere at punctuation is a new thing
<rachelandrew> myles_: we would implement it at the system level
<rachelandrew> webkit doesn't want to be in the business of understanding all this stuff
<myles__> fantasai: https://github.com/w3c/csswg-drafts/issues/1252
<rachelandrew> koji: in Android we define the priority of which to support and cut some of them
<rachelandrew> this new mechanism is more complex
<rachelandrew> fantasai: I think it would be worth finding out if the combination is needed in Chinese (don't break a Latin word but break punctuation anywhere)
<rachelandrew> florian: I think the Japanese style of document, do English words get broken
<rachelandrew> koji: it does get broken
<rachelandrew> fantasai: if we find out if we need to add it then we just need to pick a syntax
<astearns> action xidorn to see if the case where you break at punctuation but not through english words is used in Chinese
<trackbot> Error finding 'xidorn'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
<astearns> based on that result, solve this issue with break-line: break-all (that allows that) or with a solution that breaks everywhere including punctuation
<rachelandrew> fantasai: I'm leaning to the syntax being line-break: break-all
<rachelandrew> we have to pick a property, and line-break already effects some letters word-break does not deal with punctuation
<rachelandrew> astearns: can we resolve to put line-break: break-all in the spec for the purpose of the terminal use case, if it does that use case only or if it does it with the other property depends on investigation
<rachelandrew> RESOLVED: add line-break: break-all to the spec
@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal May 4, 2017

Contributor

A leftover from the discussion at the F2F is that we still need to determine if authors will need to write word-break: break-all; line-break: break-all; or just line-break: break-all to get the effect discussed in this issue, which is to allow breaks absolutely anywhere.

The former would be needed if line-break: break-all only allows for breaks anywhere around punctuation, and we still need to apply word-break: break-all to allow for breaks anywhere within words, and the later would be sufficient if line-break: break-all on its own did both.

@r12a: To answer that, we would need your input and feedback from the i18n group to know if there are languages for which it would be desirable to control these separately. Specifically, is it ever useful to allow line breaks anywhere around punctuation while disallowing them within words?

Contributor

frivoal commented May 4, 2017

A leftover from the discussion at the F2F is that we still need to determine if authors will need to write word-break: break-all; line-break: break-all; or just line-break: break-all to get the effect discussed in this issue, which is to allow breaks absolutely anywhere.

The former would be needed if line-break: break-all only allows for breaks anywhere around punctuation, and we still need to apply word-break: break-all to allow for breaks anywhere within words, and the later would be sufficient if line-break: break-all on its own did both.

@r12a: To answer that, we would need your input and feedback from the i18n group to know if there are languages for which it would be desirable to control these separately. Specifically, is it ever useful to allow line breaks anywhere around punctuation while disallowing them within words?

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal May 22, 2017

Contributor

RESOLVED: put an issue in the spec for overflow: wrap to apply regardless of whitespace

Added a commit (fa0fb3c) doing that. Editors, feel free to be angry at me if you think I stepped on your toes.

Contributor

frivoal commented May 22, 2017

RESOLVED: put an issue in the spec for overflow: wrap to apply regardless of whitespace

Added a commit (fa0fb3c) doing that. Editors, feel free to be angry at me if you think I stepped on your toes.

frivoal added a commit to frivoal/csswg-drafts that referenced this issue May 22, 2017

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal May 22, 2017

Contributor

RESOLVED: add line-break: break-all to the spec

Created the #1438 pull request to do that. We had not decided if it should on its own trigger the line breaking style of terminals, or if it would need to be used together with word-break: break-all. Since implementors indicated that the later would be harder, and no use case has been brought forward to support the ability to break anywhere around punctuation but not within words, I've specified it so that line-break:break-all can work on its own.

Contributor

frivoal commented May 22, 2017

RESOLVED: add line-break: break-all to the spec

Created the #1438 pull request to do that. We had not decided if it should on its own trigger the line breaking style of terminals, or if it would need to be used together with word-break: break-all. Since implementors indicated that the later would be harder, and no use case has been brought forward to support the ability to break anywhere around punctuation but not within words, I've specified it so that line-break:break-all can work on its own.

@frivoal frivoal added the Agenda+ label Jun 6, 2017

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Jun 6, 2017

Contributor

Since there are two possible ways to resolve this, and I've made a PR based on one of the 2 ways, I'd like to see if we can get a resolution approving that approach, so agenda+ing.

Contributor

frivoal commented Jun 6, 2017

Since there are two possible ways to resolve this, and I've made a PR based on one of the 2 ways, I'd like to see if we can get a resolution approving that approach, so agenda+ing.

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Jun 21, 2017

Contributor

I asked at the last i18n telecon if they knew of a case which would relax kinsoku but keep inter-letter restrictions, and they said they hadn't heard of such a thing. So I think we're okay to make break-all affect all characters.

Contributor

fantasai commented Jun 21, 2017

I asked at the last i18n telecon if they knew of a case which would relax kinsoku but keep inter-letter restrictions, and they said they hadn't heard of such a thing. So I think we're okay to make break-all affect all characters.

@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Jun 21, 2017

Member

The CSS Working Group just discussed word-break: break-all doesn't break before sentence-ending punctuation if UAX #14 is used, and agreed to the following resolutions:

  • RESOLVED: line-break: break-all on its own has the effect of allowing breaks everywhere
The full IRC log of that discussion <dael> Topic: word-break: break-all doesn't break before sentence-ending punctuation if UAX #14 is used
<Florian> Github: https://github.com/w3c/csswg-drafts/issues/1171
<dael> Florian: Title is a bit old. Now, at the last F2F we agreed to add a break-all value to line-break that might, in isolation allow breaks anywhere and everywhere. We did not decide if this should work on its own or if putting it on line-break should only effect punctuation
<dael> Florian: We said impl would prefer it work on its own and it appeared unlikely there were use cases to have breaks around punctuation but not inside words, but we weren't sure.
<dael> Florian: I tried to ping i18n but there has been no answer
<dael> fantasai: I asked on the telecons, they said they had not heard of a use case
<dael> Florian: So we should have line-break: break-all have effects on its own.
<dael> fantasai: I agree
<dael> Rossen_: In the absense of other recommendations from i18n or any other proposals, do we resolve?
<dael> fantasai: I think we can.
<dael> Rossen_: Any other opinions or options before we resolve?
<dael> Florian: Proposal: Line-break: break-all on its own has the effect of allowing breaks everywhere
<dael> Rossen_: Objections?
<dael> RESOLVED: line-break: break-all on its own has the effect of allowing breaks everywhere
<dael> Rossen_: Is this a change to the current spec?
<dael> Florian: Yes, we're adding this new value.
<dael> Rossen_: And this is L3 or 4 of text?
<dael> Florian: I've made a pull for L3 but I'm not sure we resolved either way
<dael> Rossen_: fantasai, preference?
<dael> fantasai: I don't. I think the feature is so simple it could be in 3.
<dael> fantasai: We can mark at-risk
<dael> Rossen_: Okay.
<dael> Rossen_: We'll add it to L3
Member

css-meeting-bot commented Jun 21, 2017

The CSS Working Group just discussed word-break: break-all doesn't break before sentence-ending punctuation if UAX #14 is used, and agreed to the following resolutions:

  • RESOLVED: line-break: break-all on its own has the effect of allowing breaks everywhere
The full IRC log of that discussion <dael> Topic: word-break: break-all doesn't break before sentence-ending punctuation if UAX #14 is used
<Florian> Github: https://github.com/w3c/csswg-drafts/issues/1171
<dael> Florian: Title is a bit old. Now, at the last F2F we agreed to add a break-all value to line-break that might, in isolation allow breaks anywhere and everywhere. We did not decide if this should work on its own or if putting it on line-break should only effect punctuation
<dael> Florian: We said impl would prefer it work on its own and it appeared unlikely there were use cases to have breaks around punctuation but not inside words, but we weren't sure.
<dael> Florian: I tried to ping i18n but there has been no answer
<dael> fantasai: I asked on the telecons, they said they had not heard of a use case
<dael> Florian: So we should have line-break: break-all have effects on its own.
<dael> fantasai: I agree
<dael> Rossen_: In the absense of other recommendations from i18n or any other proposals, do we resolve?
<dael> fantasai: I think we can.
<dael> Rossen_: Any other opinions or options before we resolve?
<dael> Florian: Proposal: Line-break: break-all on its own has the effect of allowing breaks everywhere
<dael> Rossen_: Objections?
<dael> RESOLVED: line-break: break-all on its own has the effect of allowing breaks everywhere
<dael> Rossen_: Is this a change to the current spec?
<dael> Florian: Yes, we're adding this new value.
<dael> Rossen_: And this is L3 or 4 of text?
<dael> Florian: I've made a pull for L3 but I'm not sure we resolved either way
<dael> Rossen_: fantasai, preference?
<dael> fantasai: I don't. I think the feature is so simple it could be in 3.
<dael> fantasai: We can mark at-risk
<dael> Rossen_: Okay.
<dael> Rossen_: We'll add it to L3
@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Jun 21, 2017

Contributor

Ok, I reviewed the changes... the interaction of this directive and the mandatory glue characters (like nbsp) needs to be clearer.

Contributor

fantasai commented Jun 21, 2017

Ok, I reviewed the changes... the interaction of this directive and the mandatory glue characters (like nbsp) needs to be clearer.

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Jun 23, 2017

Contributor

@fantasai I've added some extra wording to clarify that interaction. Is this clear enough?

Contributor

frivoal commented Jun 23, 2017

@fantasai I've added some extra wording to clarify that interaction. Is this clear enough?

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Aug 10, 2017

Contributor

CSSWG resolved to add this functionality as line-break: anywhere.

Contributor

fantasai commented Aug 10, 2017

CSSWG resolved to add this functionality as line-break: anywhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment