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] overflow-wrap: break-spaces can effect behavior even when there are previous breaking opportunities in the line #2003

Closed
litherum opened this Issue Nov 21, 2017 · 8 comments

Comments

Projects
None yet
4 participants
@litherum
Contributor

litherum commented Nov 21, 2017

https://drafts.csswg.org/css-text-3/#propdef-overflow-wrap

overflow-wrap: break-word says:

An otherwise unbreakable sequence of characters may be broken at an arbitrary point if there are no otherwise-acceptable break points in the line.

overflow-wrap: break-spaces says:

Any sequence of preserved white space ... must be broken ... before the first space in the sequence if none would fit and both break-word and break-spaces are specified.

Then, there's a note that says:

This last clause is due to the fact that 'overflow-wrap: break-words'' allows breaks between any two characters to avoid overflow

But this isn't quite right. break-word only kicks in when there are no otherwise-acceptable break points in the line, but break-spaces applies in all situations.

Consider the following example, styled with white-space: pre-wrap; overflow-wrap: break-word break-spaces, where the square represents a space character:
screen shot 2017-11-21 at 11 09 21 am
In this situation, break-word is irrelevant, so it seems that there should be a line break before the word "text".

However, in this example:
screen shot 2017-11-21 at 11 13 38 am
break-word kicks in, and would find the breaking position between the "t" and the space character, so it seems that the string should break between these characters.

@litherum

This comment has been minimized.

Contributor

litherum commented Nov 21, 2017

I guess my proposal would be to remove the clause:

or before the first space in the sequence if none would fit and both break-word and break-spaces are specified.

and remove the note, and let the behavior described in the note fall out of the existing behavior of break-word.

@frivoal

This comment has been minimized.

Contributor

frivoal commented Nov 22, 2017

In the absence of break-spaces, break-word is expected not to break before the first space of the preserved sequence at the end of the line, as it is supposed to hang (or to be collapsed, but that's already ruled out in this case, see below). If we remove the bit you suggest we remove, then what cause the requirement to change from "hang" to "break before the first space"?

We have:

  • in https://drafts.csswg.org/css-text-3/#white-space-phase-1

    If white-space is set to pre or pre-wrap, any sequence of spaces is treated as a sequence of non-breaking spaces. However, a soft wrap opportunity exists at the end of the sequence.

  • in https://drafts.csswg.org/css-text-3/#white-space-phase-2

    If spaces or tabs at the end of a line are non-collapsible but have white-space set to pre-wrap the UA must either hang the white space or visually collapse the character advance widths of any overflowing spaces such that they don’t take up space in the line. However, if overflow-wrap is set to break-spaces, collapsing their advance width is not allowed, as this would prevent the preserved spaces from wrapping.

If we removed the thing you said we should remove, I am worried that the following interpretation becomes either the only possible one, or a possible ambiguity:

  • white-space is pre-wrap, therefore per 4.1.1's second bullet sequences of white spaces are turned into sequences of of non-breaking spaces with a wrap opportunity at the end, but not elsewhere (and specifically, not at the beginning).
  • white-space is pre-wrap and overflow-wrap has break-spaces, so per 4.1.3 point 4, I cannot collapse the end-of-line preserved spaces, and must instead hang them.
  • white-space is pre-wrap and overflow-wrap has break-spaces, so per the definition of break-spaces, in addition to soft wrap opportunity at the end of the sequence given by 4.1.1, there are also opportunities between each of the spaces, but since the break-spaces no longer (per your suggestion) explicitly allows breaks before the first space in the preserved sequence that space character should just be hanging, (as per 4.1.3.), and we break after that space (as per the definition of break-spaces).

With all that said, I agree that this whole thing is hard to follow, and that being sure of exactly what behavior is expected by the interaction of this various parts is quite hard, and also that the note itself may not be terribly well phrased.

So I support rephrasing either the normative text, or the note, or both, but I don't think the simple removal you suggest actually works out well.

@litherum

This comment has been minimized.

Contributor

litherum commented Nov 27, 2017

I think I understand everything you said, but I'm missing the problem.

Let's consider this situation, where the square represents a space character and green represents the width of the container.

screen shot 2017-11-27 at 12 55 23 pm

According to the current spec text,

  • If this is styled with white-space: pre-wrap; overflow-wrap: break-spaces, then there would be a line break between the last space and the second-to-last space
  • If this is instead styled with white-space: pre-wrap; overflow-wrap: break-word break-spaces, then there would be a line break just after the word "text" (before the second-to-last space).

The only difference between these two sets of styles is the addition of overflow-wrap: break-word. However, overflow-wrap: break-word shouldn't cause any behavior change, because white space exists earlier in the line.

My suggestion would be to change the behavior of white-space: pre-wrap; overflow-wrap: break-word break-spaces to make the line break occur between the last space and the second-to-last space.

Do you think you could be more explicit about the problem this raises?

@litherum litherum changed the title from [css-text-3] Note about overflow-wrap: break-spaces seems wrong to [css-text-3] overflow-wrap: break-spaces can have effect even when there are previous line breaking opportunities in the line Nov 27, 2017

@litherum litherum changed the title from [css-text-3] overflow-wrap: break-spaces can have effect even when there are previous line breaking opportunities in the line to [css-text-3] overflow-wrap: break-spaces can effect behavior even when there are previous line breaking opportunities in the line Nov 27, 2017

@litherum litherum changed the title from [css-text-3] overflow-wrap: break-spaces can effect behavior even when there are previous line breaking opportunities in the line to [css-text-3] overflow-wrap: break-spaces can effect behavior even when there are previous breaking opportunities in the line Nov 27, 2017

@frivoal

This comment has been minimized.

Contributor

frivoal commented Dec 15, 2017

Ok, now I understand what you're talking about.

I am not sure I understand why you want that change though. Can you elaborate on "overflow-wrap: break-word shouldn't cause any behavior change, because white space exists earlier in the line."

From my point of view, there's are many variations that different people can want in different contexts, and the current syntax seemed to me that it enabled all the ones I knew about.

In particular, the variation you seem to want to get rid of (break between t and the first space) is the one that matches command line / terminals / vi and similar things.

That said, this was introduced before line-break:anywhere existed, and maybe now that is sufficient to cover this use case.

In other words, if white-space: pre-wrap; overflow-wrap: break-spaces; line-break:anywhere does breaks between the t and space in your example, then I'd probably be OK if white-space: pre-wrap; overflow-wrap: break-word break-spaces didn't.

I'm not sure I 100% understand why you'd want to change it this way (and how you'd update the text to make it go that way), but I'd probably be OK with it.

@fantasai

This comment has been minimized.

Contributor

fantasai commented Mar 5, 2018

line-break: anywhere allows breaks between spaces (between any two characters, in fact) so should solve the terminal-style breaking use case.

frivoal added a commit to frivoal/csswg-drafts that referenced this issue Mar 5, 2018

@fantasai

This comment has been minimized.

Contributor

fantasai commented Mar 5, 2018

fantasai added a commit that referenced this issue Mar 5, 2018

@frivoal frivoal added the Agenda+ label Mar 6, 2018

@frivoal

This comment has been minimized.

Contributor

frivoal commented Mar 6, 2018

Agenda+ to get confirmation for 1a6a12d

@css-meeting-bot

This comment has been minimized.

Member

css-meeting-bot commented Mar 21, 2018

The Working Group just discussed overflow-wrap: break-spaces can effect behavior even when there are previous breaking opportunities in the line, and agreed to the following resolutions:

  • RESOLVED: Simplify the definition of break-spaces as in this commit: https://github.com/w3c/csswg-drafts/commit/1a6a12db7f8b431fe4646c634aa823105208f1d4
The full IRC log of that discussion <dael> Topic: overflow-wrap: break-spaces can effect behavior even when there are previous breaking opportunities in the line
<dael> github: https://github.com//issues/2003#issuecomment-370652901
<dael> florian: myles noticed a complication in a corner case of the handling of break space. Initially intentionally introduced, but it is a complication. Since line-break-anywhere exists this brings nothing to the platform. All varients remain possible.
<dael> myles: Background, we are interested in using icu breaking iterators. There's a bunch of modifiers for breaking including overflow-wrap which should only kick in if a breaking oportunity wasn't in the line until the end.
<dael> myles: Corner case is where we couldn't look at all properties and create icu breaking iterator because breaking opportunities depending on earlier in the line. It would be great if this corner case could be removed.
<dael> myles: I believe the commit fantasai maded satisfies that constraint so it's okay now.
<dael> astearns: Concerns with this simplification?
<dael> Rossen_: Trying to wrap my head around what it means for impl that impl the corner case.
<dael> florian: no one impl yet.
<dael> Rossen_: I think not in a shipping form.
<dael> myles: As I understand if I impl what was in there before I need special handling and an if statement. I think after there's no if or special handling. I don't know how the Edge impl works but Iwould imagine it would be simplier.
<dael> florian: There was also a slight error in the wording for the spec. [reads] If we remove the normative requirement there's independance where there was interference before the change.
<dael> florian: For the details of what and why we're need a whiteboard.
<dael> Rossen_: If we can attach the JS to exemplify that would be great.
<dael> myles: I couldn't fiddle but I did mockups in pngs insided the thread.
<dael> myles: Proposed resolution is to accept fantasai's commit.
<dael> Rossen_: I did review. I won't object. I'm just trying to work through ramifications.
<dael> astearns: So Rossen_ are you okay to resolve now or do you want time?
<dael> Rossen_: We can resolve now. I will pay witht he behavior and try to come up with the test cases myles was trying to examplify. I don't think i t'll be a problem.
<dael> astearns: Obj to simplify defintion of break spaces?
<dael> Rossen_: What is the technical version of that resolution?
<dael> astearns: WE have the commit. Simplify the definition of break-spaces as in this commit.
<florian> url to the commit: https://github.com/w3c/csswg-drafts/commit/1a6a12db7f8b431fe4646c634aa823105208f1d4
<dael> Rossen_: great
<dael> RESOLVED: Simplify the definition of break-spaces as in this commit: https://github.com/w3c/csswg-drafts/commit/1a6a12db7f8b431fe4646c634aa823105208f1d4

@fantasai fantasai closed this Mar 22, 2018

frivoal added a commit to frivoal/web-platform-tests that referenced this issue Apr 25, 2018

fantasai added a commit to web-platform-tests/wpt that referenced this issue Apr 25, 2018

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

Bug 1456747 [wpt PR 10628] - [css-text] tests for overflow-wrap with …
…break-word + break-spaces, a=testonly

Automatic update from web-platform-tests[css-text] tests for overflow-wrap with break-word + break-spaces

Covers the spec changes made for:
w3c/csswg-drafts#2003

--

wpt-commits: 5084587f6b05bf99ad09e7844be66dcc61070cdf
wpt-pr: 10628

mykmelez pushed a commit to mozilla/gecko that referenced this issue May 3, 2018

Bug 1456747 [wpt PR 10628] - [css-text] tests for overflow-wrap with …
…break-word + break-spaces, a=testonly

Automatic update from web-platform-tests[css-text] tests for overflow-wrap with break-word + break-spaces

Covers the spec changes made for:
w3c/csswg-drafts#2003

--

wpt-commits: 5084587f6b05bf99ad09e7844be66dcc61070cdf
wpt-pr: 10628
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment