[csswg-drafts] [css-ruby] siblings/children vs in-flow siblings/children in box fixup (#4958)

frivoal has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-ruby] siblings/children vs in-flow siblings/children in box fixup ==
By the end of steps 1 through 3 of [the anonymous ruby box generation](https://drafts.csswg.org/css-ruby-1/#box-fixup), all the **in-flow** content of a ruby container should be a properly structured set of ruby base containers, ruby annotation containers, ruby bases, ruby annotations, and inline-level content of the bases / annotations.

Out of flow content is left alone, and stays as it was initially.

The last sentence of step 3 says that for intra-ruby white space, we need to look at steps 4 through 6 to figure out if it is discarded or preserved, and if preserved, how.

However, steps 4 through 6 talk about siblings and children, without specifying whether they're only addressing in-flow children. Logically, that would mean they're talking about all children, but if that is the case, then the situations they describe are not exhaustive, and we're left with no answer about what we should be doing about the intra-ruby white space in some situations.

For instance, as far as I can tell, the following case would not be covered

```html
<style>i { position: absolute; }</style>
<ruby><i></i> <rb>b1</rb>x<rt>a1</rt><rt>a2</rt></ruby>
```
* step 1 doesn't apply
* step 2 doesn't apply
* step 3 makes the space into an intra-ruby white-space, and refers us to step 4 -6 to figure out what to do with it
* step 4 does not apply: the space is not a sole child, and it does not occur at the beginning or end => it is not removed
* step 5 does not apply, as the next box is neither a ruby annotation container nor a ruby annotation => it is not removed
* none of the cases in step 6 apply.

One possible interpretation is that any such intra-ruby white space that isn't covered by rules 4 to 6 is preserved, and is either a ruby base or a ruby annotation, depending on which kind of container it's in. So in the example above, the space would be wrapped in an anonymous ruby base.

However:
* This isn't explicit
* It's not really clear what then happens in step 8, given that that chunk of non-removed intra-ruby white-space has not been classified as any of inter-base white space, inter-annotation white space, or inter-segment white space. 
* This would mean that the presence or absence of out-of-flow elements changes the behavior of the surrounding in-flow content, which seems quite unexpected (in the example above, the space would have been removed at step 4 if it had not been preceded by an abspos)

Therefore, I suggest re-writing steps 4 to 6 as follows:

> 4. Trim leading/trailing white space: Any intra-ruby white space that is not the sole <ins>in-flow</ins> child of its parent and <del>occurs at the beginning or end</del><ins>is the first or last in-flow child</ins> of a ruby container, ruby annotation container, or ruby base container is removed, as if it had display: none

> 5.  Remove inter-level white space: Any intra-ruby white space whose immediately adjacent <ins>in-flow</ins> siblings match one of the patterns below is inter-level white space
and is removed, as if it had display: none. 
>
>    [table ommitted, unchanged]

> 6. Interpret intra-level white space: Any intra-ruby white space box whose immediately adjacent <ins>in-flow</ins> siblings match one of the patterns below is assigned the box type and subtype defined in the table below: 
>
>    [table ommitted, unchanged]

If we don't want to do that, and want to consider all the content, even out of flow, I suggest we clarify exactly what that means. My best guess would be:

> 3. Wrap misparented inline-level content: [first paragraph unchanged]
>
>     However, if an anonymous box so constructed contains only white space<ins> and any of the situations described in steps 4 to 6 apply</ins>, it is considered intra-ruby white space and is either discarded or preserved as described <del>below</del><ins>in the relevant step</ins>.<ins> Otherwise, it remains a ruby base or a ruby annotation as per the previous paragraph.

While that would make the whole thing unambiguous (I think), I don't think this would be great behavior though.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4958 using your GitHub account

Received on Thursday, 16 April 2020 06:29:32 UTC