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

Thank you Mike for pointing this out and the great test case. This will
need WG discussion, I filed:

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

Please follow the discussion in the issue above.

2017-11-17 18:32 GMT+09:00 Mike Bremford <mike-css@bfo.co.uk>:

> 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
> --
> -----------------------------------------------------
> Mike Bremford - CTO                   mike@bfo.com
> Big Faceless Organization             http://bfo.com
>