Csswg-drafts: [css-text] white-space collapse at end of line: test case and queries

[kojiishi]

From https://lists.w3.org/Archives/Public/www-style/2017Nov/0009.html

---

Hi all

I have attached a test case (also at https://jsfiddle.net/bgq0wmo1/4/) designed
to show the details of whitespace collapsing, which is giving inconsistent
results across browsers. I'm hoping for clarification as we are presently
in the process of implementing this.

The two relevant paragraphs from CSS3-TEXT (latest working draft/editors
draft are currently identical)

from 4.1.1 (phase 1 initial collapse): "Any space immediately following another collapsible space—even one outside the boundary of the inline containing that space, provided both spaces are within the same inline formatting context—is collapsed to have zero advance width. (It is invisible, but retains its soft wrap opportunity, if any.)"

and from 4.1.3 (phase 2 per line collapse):"A sequence of collapsible spaces at the end of a line is removed."

The problem: when the sequence of spaces at the end of the line is interrupted by a non-replaced inline containing only collapsible whitespace, all of which are collapsed in phase 1, then:

1. Firefox is collapsing all the way through the inlines in phase 2, as if they were transparent to this process. This gives consistent results for all rows.

2. Webkit and Chrome are doing something I can't quite figure out, but which looks wrong. Specifically they are both removing a non-anonymous inline from the render tree on rows M, P and R.

3. Neither are doing what I think is specified: in phase 1 collapse all spaces after the first down to nothing, leaving rows A-G effectively identical with one space before the green box. There's no action for phase 2 as the specification does not imply skipping over inlines at all. The "sequence of collapsible spaces" _immediately_ preceding the end-of line has already been collapsed and the final render tree looks like this:

   [ "A", <preserved space>, <collapsed spaces>*, <span>, <collapsed spaces>*, </span>, <collapsed spaces also collapsible in phase 2>* ]

So I was hoping to clarify: In phase 2, does "A sequence of collapsible spaces at the end of a line is removed" imply spaces from the same inline formatting context (as in option 1), or just spaces from the final text node (as in option 3). If it's the former, could we modify the language in 4.1.3 to state this? Or, if Safari and Chrome are correct, can someone explain why?

Cheers... Mike

[ edited by @dbaron to link the word "attached" to the attachment ]

[kojiishi]

Engine | Behavior
--- | ---
Blink, WebKit | A-D has a trailing space before the span.
Edge, Trident | A-G has a trailing space before the span.
Gecko, Blink w/LayoutNG | No trailing spaces.

Servo doesn't seem to render borders and that I can't confirm.

As Mike pointed out, M, P, R on Blink/WebKit looks like a bug. Blink fixes this in LayoutNG.

[palemieux]

See also https://lists.w3.org/Archives/Public/www-style/2017Jan/0021.html

[upsuper]

@kojiishi I don't see any trailing space in the testcase on Gecko on Windows (I tested Firefox 56 as well as 58). What version of Firefox and platform are you testing?

[kojiishi]

Ah, sorry, I swapped Gecko with Edge. Fixed.

[frivoal]

I agree that what Webkit and Blink (without LayoutNG) do seems to be a bug.
But between the Edge behavior (3) and the Firefox behavior (1), I am neither sure what the spec means, nor what is the prefered behavior.

Does anyone have use cases that indicates a preference between 1 and 3?

[fantasai]

So, agree the spec could be clarified on this point. As for clarifying to which behavior...

The behavior should definitely be symmetric between the start and end edges: both because it's more consistent (especially in consideration of all text-align values), and because the spec does use identical wording for both edges and so clearly intended symmetry. Given that we trim through the inlines on the start edge in all implementations, and in the end edge in 50% of not-nonsensical implementations, it seems like converging on trimming through the inlines has a little more weight implementation-wise. (Also Edge for some reason doesn't measure the space that it preserves in this case; try shrinkwrapping the <div> around the text and watch it overflow--so it needs some fixing anyway.)

Another line of argument is that unstyled inline boxes are generally expected to have no effect on rendering, and that one inline boundary (end of inline) shouldn't behave any differently than two (start and end of empty inline). So there's a strong argument that unstyled inline boundaries should not affect white space trimming at the end of the line, and in fact this is what happens in Gecko and Edge. In considering the testcase in which they are styled: while adding margins/padding/border might be expected to have an effect on things like text shaping and positioning, it seems odd for them to have an effect on the contents of the text string being rendered, particularly given they're not considered anywhere else in text transformations.

And lastly there's the point that trailing spaces just look bad, and that having a space just inside the closing tag of an inline or before a <br> is a reasonably common unintentional markup pattern that shouldn't have a bad effect on rendering. The preserved trailing space becomes noticeable both when the inline is styled, as in the example given by @palemieux, and also when we chose text alignments other than start. This gives a real-world use case indicating a preference for Firefox's behavior.

So altogether, I'd say, we should clarify the spec to say that white space trimming at the start and end of the line operates through any inline box boundaries.

[FremyCompany]

FWIW this is the behavior I see in our next-gen layout engine vs our current engine:
vs

[FremyCompany]

So it looks like the next generation of all layout engines have converged on "no trailing space" gecko currently has, and I would be fine to have this standardized in the spec

[css-meeting-bot]

The Working Group just discussed white-space collapse at end of line: test case and queries, and agreed to the following resolutions:

• RESOLVED: spec Gecko's behavior at the ends of lines in display text?

The full IRC log of that discussion

<dael> Topic: white-space collapse at end of line: test case and queries

<dael> github: https://github.com/w3c/csswg-drafts/issues/1997

<dael> florian: I can try and cover for fantasai

<dael> florian: If she's not here.

<dael> fantasai: I'm here.

<dael> fantasai: There's inline box bounderies that prevent the whitespace from collapsing at the end of the line for certain impl.

<dael> fantasai: You can see from the example in the issue.

<dael> fantasai: Question is will we collapse all consequitive spaces and we have the end of the line and after the space the inline tag closes. Does the space at the end collapse even though there's an inline box boundary. I say yes for the reasons in the comment.

<dael> astearns: Looks like we will have interop with Gecko, upcoming Blink, upcoming Edge.

<dael> fantasai: I don't remember the Blink testcase, but we will have some engines that do that.

<dael> fantasai: An important reason to do this is authors will expect this. When closing tags aren't tight against the last it just hangs out and it's unexpected. havging a space hanging out inside be different then outside doesn't make a whole lot of sense.

<dael> astearns: Any concerns with trimming the trailing psace?

<dael> florian: Agree

<dael> myles: I don't quiteunderstand the test case. I thought spec was all trimmed except the first. So the space shown isn't from inside the span? Maybe I should take this offline

<dael> fantasai: Space is after the first. If you have a series fo collapsable spaces the first is preserved.

<dael> myles: It's before the span with the border-left in the firstline

<dael> fantasai: Test cases have checks for before the text and after. Whitespace does 2 phases, one go down to one space and then go through the line and any space adjacent to start or end is trimmed.

<dael> myles: Let's take this offline. Resolution is fine.

<dael> Rossen_: You're okay to resolve on current behavior and continue to define?

<dael> myles: I'm a little confused about the test case, but in the issue there was a proposed resolution to use the FF behavior.

<dael> Rossen_: I would point out that even though you'll get similar renderings with at least our current work in progress as well as what I'm assuming the NG layout is aiming for in Chrome. I can't speak to webkit. As soon as you start interacting with this particular test case in content: editable or you select it, you get very different behavior.

<dael> Rossen_: I'm not sure how much this resolution captures this.

<dael> florian: I thinkt he problem of having more divergence as to what happened to spaces when you select them goes way beyond this test case. We probably should tackle that sep.

<dael> Rossen_: My point is we should either, ideally have a note for this or test cases that involve selection. Something that allows us to proceed forward more interop. I think we've discussed extensively in the past and made some progress.

<dael> Rossen_: I want to point out this issue doesn't address any of that.

<dael> florian: That's fair and this is something I'm interested in looking into. I'll try and see what the spec says about when selecting and editing. It's separate, but I want to look into it.

<dael> astearns: Setting content editable and selection aside, it sounds likew e're converging on Gecko's behavior for trimming at the end of lines for displayed test

<dael> astearns: Objections to spec Gecko's behavior at the ends of lines in display test?

<dael> RESOLVED: spec Gecko's behavior at the ends of lines in display text?

[litherum]

@css-meeting-bot means "in displayed text" as opposed to highlighted text (which may be different)