[css-text] How to handle leading ideographic space sequences ? #4180
Comments
Result 2 is the expected one. Here is why:
|
|
Good ! Thanks for the explanation, which confirms my understanding as well. |
|
I'm facing some troubles implementing the handling of leading ideographic spaces, so before reopening this issue, I'd like to clarify some details of @frivoal explanation above. 1- I'm quite shocked about the statement that " the two U+3000 at the end of line 1 get removed." since this sequence is both, a leading and a trailing sequence at the same time. Are you sure we want this ambiguity to be applied on any case ? This would imply that steps 1 of 2 of Phase 2 produce the same result, even though ideographic spaces are not collapsible spaces: https://drafts.csswg.org/css-text-3/#white-space-phase-2
I'm not sure how to implement this behavior of wrapping the line, so that the "X" character is moved to the second line, but then removing the spaces that motivated the line wrapping. The fact that this is only perceptible if the space sequence has some specific style (background or underline) is also strange. |
|
Yes, I am quite sure that this is what the spec says, and it seems like good behavior to me. ideographic spaces don't collapse with eachoter, or with spaces. Unlike regular spaces, they being at the beginning of the line doesn't cause them to be discarded, but they do get discarded when they are the end of the line. In the case you are talking about, they are both at the beginning and at the end of the line, because there's nothing else in the line. In that case, yes, it give the same results as step 1 even though they're not collapsible, but that's just true in this special case, not in general. As for how to implement, how about replacing them with a preserved line feed in that situation? If that turns out to be too hard, I suppose we could replace step 3 two steps, like:
(that's kind of the same as the first sub bullet of step 4, for collapsible values of white-space in addition non conditional on white-space:pre-wrap. Also, note that we have an open issue on the details of step 4 #3440). That seems more complicated to me, to largely achieve the same results, but it wouldn't leave us with empty lines (and authors could paint a background on these if they wanted). |
|
I think we can leave the spec as it is for now; I just wanted to double check whether the behavior for this special case makes sense. I got some progress to implement it, so we can leave this issue closed. Thanks again for the promptly feedback. |
|
Let me re-open this so that we can discuss a bit more. I think wasn't thinking well-enough when it was resolved, sorry about that, but I agree with @javifernandez that we should hang trailing ideographic spaces, without removing them. I have a few reasons to believe so, but I'd like to see what others think about this: @fantasai @MurakamiShinyu @himorin @r12a @macnmm |
I'd be OK with that. |
|
Hanging multiple ideographic spaces could cause the inline bounds to extend off screen though - making things like background-color and selection also go off screen. |
… of removing them Close w3c#4180
|
I've made PRs to enact the proposed change: |
… of removing them Close w3c#4180
… of removing them Close w3c#4180
Yeah, that is one of the effects I would like. I think the ideographic space at line end should be selectable, just like other hanging punctuation are. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<TabAtkins> Topic: How to handle leading ideographic space sequences<TabAtkins> florian: this has evolved over time; they're a strange kind of space, like figure spaces, ideographic spaces, etc <astearns> github: https://github.com//issues/4180 <TabAtkins> florian: These now have the treatment that they'r enot collapsible, that hasn't changed, bu tthey're discarded at the end of the line (assuming white-space:normal) <TabAtkins> florian: Unfortunate consequence: if the line is *only* these spaces, they're not discarded for being at the beginning of the line, but they're also at the end of the line and need to be discarded. That leaves an empty line, which is weird. <TabAtkins> florian: We coul dinsted hang them. <TabAtkins> florian: Diff is you could still see them if you underline or background them. <TabAtkins> florian: But from layout, it would be the same as an empty line. <TabAtkins> florian: This was found by Igalia when implementing the spec as written, and it seemed weird to them. <TabAtkins> florian: I think there's no real author preference between discarding and hanging. So since hanging is simpler for impls, would be preferable. <TabAtkins> florian: I made a PR for this, I know fantasai is okay with this. <TabAtkins> ???: Is there precedence fo rhaving that many hanging spaces? <astearns> s/???/stantonm/ <TabAtkins> florian: Yes, we have some other situations like white-space:pre-wrap. <TabAtkins> florian: There's an open issue for some variant situations, but... <TabAtkins> stantonm: The inline border does seem strange. <TabAtkins> stantonm: An inline with a border would project off the edge of the element. <TabAtkins> florian: Like any overflowing content, es. <TabAtkins> florian: Example: "<span>a b </span>". If the spaces can hang, these can stay on one line. If they can't and must overflow, instead you must break before b, then let that second line overflow anyway. So not hanging isn't avoiding overflow at all, just introducing extra linebreaks that shouldn't be necessary. <TabAtkins> koji: Hanging would require changes to our whitespace code that we'd like to avoid if possible. <TabAtkins> myles: there are like 5000 ways to make text look bad on the web already <TabAtkins> stantonm: Is there a way to avoid this? <TabAtkins> florian: Yes, text-underline-skip for example. <TabAtkins> astearns: So proposed resolution is to accept the PR, which states that the spaces will hang. <TabAtkins> astearns: Objections? <TabAtkins> RESOLVED: Trailing "other-separator spaces" will hang, accepting Florian's PR. |
…n response to w3c/csswg-drafts#4180, a=testonly Automatic update from web-platform-tests [css-text] Adjust trailing space tests in response to w3c/csswg-drafts#4180 (#18949) -- wpt-commits: 0bfde9f6a8bfde0fde4dba73d7172a8eed6e946e wpt-pr: 18949
…n response to w3c/csswg-drafts#4180, a=testonly Automatic update from web-platform-tests [css-text] Adjust trailing space tests in response to w3c/csswg-drafts#4180 (#18949) -- wpt-commits: 0bfde9f6a8bfde0fde4dba73d7172a8eed6e946e wpt-pr: 18949
…n response to w3c/csswg-drafts#4180, a=testonly Automatic update from web-platform-tests [css-text] Adjust trailing space tests in response to w3c/csswg-drafts#4180 (#18949) -- wpt-commits: 0bfde9f6a8bfde0fde4dba73d7172a8eed6e946e wpt-pr: 18949 UltraBlame original commit: ee990e885d2f739e9be99f327b65853c870ca4a2
…n response to w3c/csswg-drafts#4180, a=testonly Automatic update from web-platform-tests [css-text] Adjust trailing space tests in response to w3c/csswg-drafts#4180 (#18949) -- wpt-commits: 0bfde9f6a8bfde0fde4dba73d7172a8eed6e946e wpt-pr: 18949 UltraBlame original commit: ee990e885d2f739e9be99f327b65853c870ca4a2
…n response to w3c/csswg-drafts#4180, a=testonly Automatic update from web-platform-tests [css-text] Adjust trailing space tests in response to w3c/csswg-drafts#4180 (#18949) -- wpt-commits: 0bfde9f6a8bfde0fde4dba73d7172a8eed6e946e wpt-pr: 18949 UltraBlame original commit: ee990e885d2f739e9be99f327b65853c870ca4a2
The definition of the various values of the white-space property in section 3 does not go into much detail about exactly how they work, and just provides a high level intro to what they do. The details are provided in section 4, and in particular 4.1 and 4.3 (so called “phase 1” and “phase 2” of white space processing). While this phase 2 has been updated (see w3c#2500 w3c#3879 w3c#4180) to define that not only space characters, but also other space separators hang / don't hang / wrap / don't wrap, etc, based on the value of the white-space property, the high level definition of these values was not updated to reflect that. While this is not necessarily a bug, as it is already called out that details are in section 4, apparent contradictions or omissions can be confusing. Therefore, in the part of these definitions that explicitly talked about white space wrapping/hanging (or not), include other space separators as well, as defined in 4.3.
|
Hi florian, Despite we have closed this issue, which I agree with the resolution, I'm not sure the changes in the test reflected what we have resolved; it may be possible I haven't understood it correctly, so I'd appreciate this get clarified before I reopen it, or maybe better create a new issue. The test I'm talking about is trailing-ideographic-space-001.html . There is a comment in that test precisely stating that the trailing ideographic space, which is hanging, should not extend the width of its parent, which has max-content width. However, this trailing ideographic space is followed by a forced-break, so If I understood correctly what the spec dictates, it should conditionally hang, which means that it should account for it's parent's max-content width.
|
I'm not sure whether the spec covers some extreme cases related to full-width spaces, specifically ideographich spaces (x3000).
As far as I know, leading ideographich space sequences should not be collapsed, even when the white-space property allows to do so (normal, nowrap, or pre-line). However, I'm not sure what to do in cases like this one:
<div width: 2em; white-space:normal">　　XX</div>First of all, 'white-space: normal' allows wrapping, as it's stated in the spec:
The Phase II: Trimming and Positioning section describes several scenarios and steps to evaluate, but I don't know which one this cases should be applied to:
In this case, these are full-width spaces, so they can not be considered as collapsible, despite the value of the white-space property (normal).
If we allow breaking after the last U+3000 space, the space sequence will fill the whole line. Should we apply this step and remove the sequence ? In that case, it'd be the same than applying the step 1, which I think is not what we want for ideographic spaces.
So, I wonder which of the following results would be the expected one, according to the current specs, for this case:
The text was updated successfully, but these errors were encountered: