[css-text-3] break spaces #111

frivoal · 2016-05-13T09:52:07Z

No description provided.

Based on resolutions from the 2016 San Francisco and Sydney Face-to-face meetigns.

As resolved at the 2016 Sydney face-to-face meeting. This 'pre-wrap-auto' had already been removed from Level 3, but was still in level 4.

kojiishi · 2016-05-16T02:14:29Z

css-text/Overview.bs

@@ -755,6 +755,9 @@ Languages and Typesetting</h4>
         the UA must either <a>hang</a> the <a>white space</a>
         or visually collapse their character advance widths
         such that they don't take up space in the line.
+         However, if 'overflow-wrap' is set to ''break-spaces'',


When ''break-spaces'', spaces breaks, so it no longer be "at the end of a line". I think I understand your intention but it can confuse rather than help. Maybe you could add such note that this will not happen if ''break-spaces'' if you think having text here is important?

When 'break-spaces' is specified, spaces should break. But this would not happen if they have already been collapsed, so I am trying to (normatively) make it explicit that you cannot do that. I thought this text was easier to understand here than in the definition of the break-spaces value. Do you think it should be moved? Do you have a suggestion of a better way to phrase it?

By re-reading this, you're modifying an item that I don't understand, so it's not your problem, but you'd have to ask fantasai to review.

This item starts with:

If spaces or tabs at the end of a line are non-collapsible but have 'white-space' set to ''pre-wrap''

but I can't interpret this part. Does this "but" mean "except"? Maybe clear to native speakers but this is beyond my English capability, sorry.

I think this "but" could just as easily be replaced with "and". We're talking about a subset of of the non-collapsible spaces. "If there are non-collapsible spaces and when 'white-space' is set to ''pre-wrap''" is the same as "if there are non-collapsible spaces, but [only in the case when] 'white-space' set to ''pre-wrap''"

frivoal · 2016-06-16T01:42:53Z

@kojiishi @fantasai Ping. Can you either merge this or tell me what's wrong with it?

kojiishi · 2016-06-16T07:33:41Z

css-text/Overview.bs

+    <dd>Line breaks are handled identically to ''overflow-wrap/normal'',
+      except that any sequence of <a>preserved</a> white space
+      that would otherwise overflow the line under these rules
+      must be broken after the last white space character that would fit the line.


So when you say

sequence of preserved white space...must be broken

you want to break between preserved white spaces but not before/after? Can you try to clarify?

Would this be clearer?

Line breaks are handled identically to ''overflow-wrap/normal'',
except that if a sequence of preserved white space
would otherwise overflow the line under these rules,
the line must be broken after the last white space character of that sequence
that would fit the line.

This is meant to be the same behavior, but should be more explicit. Break in places unrelated to the white space sequence are allowed as usual; it allows the break to happen after the last character in the sequence. It does not create a break opportunity between the first white space character in the sequence and whatever comes before it, to avoid wrapping a single space to the next line (I think you were the first to suggest that that would be a bad idea).

As a member, I still don't understand why one would want this, but as an editor, I can review PRs according to resolutions. That makes me a good reviewer though. Since I don't understand how it's used, I can review how the text reads to implementors without any background ;-)

What will happen if there are no spaces that can fit?

Sorry for the delayed answer.

If there is no spaces that would fit, you deal with it the way you would otherwise: break the line somewhere earlier if you can, or overflow if you cannot.

I don't actually have a strong opinion whether we should allow a break before the first space in a sequence of not, but I believe you were the one who expressed a preference for disallowing it.

Please make a call, as I said, I don't understand how it's used.

So from what I understand, when all of the following condition met:

If white-space: pre-wrap and

if a non-breakable word and at least one trailing space fit within the line, and

If subsequent spaces follow, and

If those subsequent spaces do not fit within the line

You want to break between spaces, but not before/after?

Very sorry for the slow answer.

You want to break between spaces

correct, if overflow-wrap is break-spaces. you break and wrap in the middle of the space sequence instead of letting it overflow.

but not before

Not before the first space if overflow-wrap is only break-spaces. If it is overflow-wrap:break-word | break-spaces, you can also break before the first space, since overflow-wrap: break-word allows for breaks anywhere.

I think this is the best behavior, but I am not very strongly attached to this nuance, so if the rest of the proposal is OK and this is blocking, I am open to changing this part.

or after?

I don't think there's anything in the wording I proposed that prohibits breaking after spaces. If the end of the line falls earlier than the last space, you should break at that earlier point, but if it falls right after that space, breaking there is the normal thing to do.

2 questions:

Are you OK with the behavior?

Do you think the proposed text (a) correctly and (b) understandably describes this behavior?

frivoal · 2016-09-12T03:36:19Z

@kojiishi @fantasai this PR has been open for pretty long now, and I'd like to wrap it up. In light of my answer to Koji's question, can you either merge it, or tell me if you either want more clarification or some change to the proposed text?

If there is anything left to be tweaked, I'd like to make sure that we get it done before the end of TPAC, so if you'd like me to prepare something before then, let me know what.

kojiishi · 2016-09-12T07:36:23Z

Sorry for my slow response too but the PR doesn't look to address a case when it says:

after the last white space character that would fit the line.

it doesn't define the behavior when there's no white space that would fit the line, correct?

Also I prefer it be effective only when white space is preserved by the white-space property, rather than making the preservation automatically activated by the overflow-wrap, unless it was discussed and resolved (sorry if it did, in that case, I'm ok.)

This does not change the intended behavior, but the previous phrasing was ambiguous about some situations, and this should clarify.

frivoal · 2016-09-13T03:23:14Z

@kojiishi

doesn't look to address a case when it says:

after the last white space character that would fit the line.

it doesn't define the behavior when there's no white space that would fit the line, correct?

Hmmm. I thought the sentence was clear, but having re-read it a couple times, I see what you mean. I've pushed a rewording with a couple of clarifying notes. I think this now defines all cases. Let me know if you think it doesn't.

Also I prefer it be effective only when white space is preserved by the white-space property

Since this value only affects what happens in runs of preserved white space, in most cases, it will not do anything if the white-space property is not preserving the white spaces. The difference with what you are suggesting is that as currently specified, it would also call for breaks in overflowing runs of  . I'd rather keep it that way: I'd find it pretty counter intuitive if a value called break-spaces did not do that.

If you agree, great. If you don't (and there's no other issue left), can we get this merged, and open a separate issue to discuss this point?

kojiishi · 2016-09-13T09:25:42Z

css-text/Overview.bs

+    <dt><dfn>break-spaces</dfn></dt>
+    <dd>Line breaks are handled as usual,
+      except that any sequence of <a>preserved</a> white space
+      that would otherwise overflow the line and <a>hang</a> as per <a href="white-space-phase-2">Trimming and Positioning</a>


isn't "#" needed for "white-space-phase-2"?

You're right. Fixed.

kojiishi · 2016-09-13T09:35:44Z

Thanks for the update, that part looks good, except one possible nit I put as an inline comment. Please check.

If you agree, great. If you don't (and there's no other issue left), can we get this merged, and open a separate issue to discuss this point?

I feel sorry for taking long on this small PR but I prefer to split it out to another PR, discuss and resolve before the merge. I suspect our code reviewers will ask for a spec change if someone tries to contribute to Blink, so I'd like not to take that long path.

We need to check whether white spaces collapses or not on every page, so adding this condition will add slight cost for the additional if statement on every page on every user. It is a very hot code path we try hard to optimize, and I don't think this property is worth the cost for everyone.
This property is only effective when white-space allows wrapping. break-space being only effective when white-space does not collapse looks more consistent to me. There are other such example, such as text-orientation, which is only effective in vertical flow. That way, we pay the cost to check the property only in vertical flow.
I understand how you feel it more intuitive, but from another perspective, it's unintuitive to break consecutive white spaces when there are no such white spaces. I feel more intuitive for authors to create consecutive white spaces first before s/he allows them to break.

This PR looks good to me if this part was separated.

kojiishi · 2016-09-20T08:01:52Z

Discussed offline to resolve misunderstandings, lgtm.

* [css-text] Add 'break-spaces' Based on resolutions from the 2016 San Francisco and Sydney Face-to-face meetigns. * [css-text-4] Remove 'pre-wrap-auto' from Level 4 As resolved at the 2016 Sydney face-to-face meeting. This 'pre-wrap-auto' had already been removed from Level 3, but was still in level 4. * [css-text] Rephrase 'break-spaces' description This does not change the intended behavior, but the previous phrasing was ambiguous about some situations, and this should clarify. * [css-text] Fix typo in markup

This closes w3c#111

Fix syntax in example code

frivoal added 2 commits May 13, 2016 00:21

[css-text] Add 'break-spaces'

8ddda77

Based on resolutions from the 2016 San Francisco and Sydney Face-to-face meetigns.

[css-text-4] Remove 'pre-wrap-auto' from Level 4

8a74b58

As resolved at the 2016 Sydney face-to-face meeting. This 'pre-wrap-auto' had already been removed from Level 3, but was still in level 4.

frivoal assigned fantasai May 13, 2016

kojiishi reviewed May 16, 2016
View reviewed changes

frivoal assigned kojiishi and unassigned fantasai May 25, 2016

kojiishi reviewed Jun 16, 2016
View reviewed changes

Merge branch 'master' into florian/break-spaces

1e017c1

frivoal added the css-text-3 Current Work label Jun 26, 2016

frivoal changed the title ~~break spaces~~ [css-text-3] break spaces Jun 26, 2016

frivoal mentioned this pull request Jul 7, 2016

[css-text] spaces before break in 'pre-wrap' text should allow combination of hanging and collapsing #277

Closed

Merge branch 'master' into florian/break-spaces

d522b46

[css-text] Rephrase 'break-spaces' description

851871f

This does not change the intended behavior, but the previous phrasing was ambiguous about some situations, and this should clarify.

kojiishi reviewed Sep 13, 2016
View reviewed changes

[css-text] Fix typo in markup

807a5eb

kojiishi merged commit 995a077 into w3c:master Sep 20, 2016

birtles added a commit to birtles/csswg-drafts that referenced this pull request Dec 4, 2017

Make setting the start time set "did seek" to true

8bf2b10

This closes w3c#111

frivoal pushed a commit to frivoal/csswg-drafts that referenced this pull request Nov 15, 2018

Merge pull request w3c#111 from chrisn/example-code

a4d5a98

Fix syntax in example code

frivoal added the Tested Memory aid - issue has WPT tests label Apr 25, 2019

frivoal deleted the florian/break-spaces branch June 5, 2020 01:46

SebastianZ mentioned this pull request Dec 1, 2022

[css-images] stripes() interpolation makes no sense #8163

Closed

[css-text-3] break spaces #111

[css-text-3] break spaces #111

Uh oh!

Conversation

frivoal commented May 13, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

frivoal commented Jun 16, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

frivoal commented Sep 12, 2016

Uh oh!

kojiishi commented Sep 12, 2016

Uh oh!

frivoal commented Sep 13, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kojiishi commented Sep 13, 2016

Uh oh!

kojiishi commented Sep 20, 2016

Uh oh!

Uh oh!

frivoal commented Sep 13, 2016 •

edited

Loading