[css-text-3] break spaces

[frivoal]

No description provided.

[kojiishi]

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?

[frivoal]

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?

[kojiishi]

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.

[frivoal]

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]

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

[kojiishi]

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?

[frivoal]

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).

[kojiishi]

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?

[frivoal]

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.

[kojiishi]

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?

[frivoal]

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]

@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]

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.)

[frivoal]

@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]

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

[frivoal]

You're right. Fixed.

[kojiishi]

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]

Discussed offline to resolve misunderstandings, lgtm.