Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[css-text-3] break spaces #111

Merged
merged 6 commits into from
Sep 20, 2016
Merged

[css-text-3] break spaces #111

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
8ddda77
[css-text] Add 'break-spaces'
frivoal May 13, 2016
8a74b58
[css-text-4] Remove 'pre-wrap-auto' from Level 4
frivoal May 13, 2016
1e017c1
Merge branch 'master' into florian/break-spaces
frivoal Jun 26, 2016
d522b46
Merge branch 'master' into florian/break-spaces
frivoal Sep 12, 2016
851871f
[css-text] Rephrase 'break-spaces' description
frivoal Sep 13, 2016
807a5eb
[css-text] Fix typo in markup
frivoal Sep 13, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 2 additions & 17 deletions css-text-4/Overview.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,7 @@ White Space Collapsing: the 'text-space-collapse' property</h3>

<pre class="propdef">
Name: text-space-collapse
Value: collapse | discard | preserve | preserve-auto | preserve-trim | preserve-breaks | preserve-spaces
Value: collapse | discard | preserve | preserve-trim | preserve-breaks | preserve-spaces
Initial: collapse
Applies to: all elements
Inherited: yes
Expand Down Expand Up @@ -66,16 +66,6 @@ White Space Collapsing: the 'text-space-collapse' property</h3>
from collapsing sequences of white space.
<a>Segment breaks</a> are preserved as forced line breaks.

<dt><dfn>preserve-auto</dfn>
<dd>
This value preserves white space and <a>segment breaks</a> as for ''preserve''.
However, in order to match platform conventions for editable text fields,
the UA <em>may</em> visually collapse
the advance widths of preserved white space
that occurs at the end of a line,
<em>or</em> treat them as collapsed for the purpose of wrapping text
(such that the white space overflows the line instead of wrapping to the front of the next line).

<dt><dfn>preserve-trim</dfn>
<dd>
This value preserves white space and <a>segment breaks</a> as for ''preserve''.
Expand Down Expand Up @@ -460,7 +450,7 @@ Shorthand for White Space and Wrapping: the 'white-space' property</h2>

<pre class="propdef">
Name: white-space
Value: normal | pre | nowrap | pre-wrap | pre-wrap-auto | pre-line
Value: normal | pre | nowrap | pre-wrap | pre-line
Initial: auto
Applies to: all elements
Inherited: yes
Expand Down Expand Up @@ -507,11 +497,6 @@ Shorthand for White Space and Wrapping: the 'white-space' property</h2>
<td>''text-space-collapse/preserve''
<td>''text-wrap/normal''
<td>''text-space-trim/none''
<tr>
<th>''pre-wrap-auto''
<td>''text-space-collapse/preserve-auto''
<td>''text-wrap/normal''
<td>''text-space-trim/none''
<tr>
<th>''pre-line''
<td>''text-space-collapse/preserve-breaks''
Expand Down
10 changes: 9 additions & 1 deletion css-text/Overview.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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'',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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''"

collapsing their advance width is not allowed,
as this would prevent the preserved spaces from wrapping.

Note: Hanging the white space rather than collapsing it
allows users to see the space when selecting or editing text.
Expand Down Expand Up @@ -1296,7 +1299,7 @@ Line Breaking Details</h3>

<pre class='propdef'>
Name: overflow-wrap, word-wrap
Value: normal | break-word
Value: normal | break-word | break-spaces
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thought this was for L4, but I admit that I wasn't paying much attention to which level we resolved on. Have a link to the resolution?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the resolution (SF or Syndey) specified if it was level 3 or 4. My main reason for preferring having it in L3 is:

  • This value is new, but the behavior is already present in some browsers, triggered by a different property/value: Firefox and Safari wrap spaces like this when word-break is break-all (FF all preserved spaces, Safari only nbsp) (see http://output.jsbin.com/degaqe). Since we have clarified that the break-word property is not supposed to do that and that this is supposed to be triggered by overflow-wrap:break-spaces, rather than have them remove this behavior now and put it back later under a different name, I thought it made sense to add the switch in the current Level.

Also from a spec editing point of view, L3 is easier (but I agree this is not an important reason):

  • L4 does not yet have the equivalent of section 4 (#white-space-processing), and that this makes some modification to it (section 4.1.3 point 4).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Totally understandable, and I don't have preference either way, but when I want to follow the resolution, you and I having different understanding looks like a sign that it's better to double-check with WG, no? In my understanding, fantasai said L4 at the beginning of the discussion and that was applied to all the discussion, but now it's unclear to me too.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. I've pinged the WG now, let's see what comes out of this.
https://lists.w3.org/Archives/Public/www-style/2016May/0134.html

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RESOLVED: Add overflow-wrap: break-spaces to level 3
http://logs.csswg.org/irc.w3.org/css/2016-05-25/#e692109

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kojiishi ping. Do you want me to adjust something in the pull request before you can merge it, or is it fine like this?

Initial: normal
Applies to: all elements
Inherited: yes
Expand Down Expand Up @@ -1324,6 +1327,11 @@ Canonical order: N/A
Shaping characters are still shaped as if the word were not
broken, and grapheme clusters must stay together as one unit.
No hyphenation character is inserted at the break point.
<dt><dfn>break-spaces</dfn></dt>
<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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

</dl>

<p><a>Soft wrap opportunities</a> introduced by ''overflow-wrap: break-word''
Expand Down