W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2017

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

From: Koji Ishii via GitHub <sysbot+gh@w3.org>
Date: Sat, 18 Nov 2017 10:39:18 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-275070454-1511001557-sysbot+gh@w3.org>
kojiishi has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-text] white-space collapse at end of line: test case and queries ==
>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

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1997 using your GitHub account
Received on Saturday, 18 November 2017 10:39:24 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 18 November 2017 10:39:26 UTC