[css-ruby] siblings/children vs in-flow siblings/children in box fixup

[frivoal]

By the end of steps 1 through 3 of the anonymous ruby box generation, 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

<style>i { position: absolute; }</style>
<ruby><i></i> <rb>b1</rb><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 in-flow child of its parent and occurs at the beginning or endis the first or last in-flow child 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 in-flow 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 in-flow 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 and any of the situations described in steps 4 to 6 apply, it is considered intra-ruby white space and is either discarded or preserved as described belowin the relevant step. 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.

[upsuper]

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.

I believe Firefox's current implementation matches this interpretation, not necessarily intentionally. Rereading the spec, I think I missed "Any consecutive sequence of text and inline-level boxes" during implementation, so in this case it doesn't really become an intra-ruby whitespace. This feels like an implementation bug in Firefox that can probably be fixed.

And I think making it consider only in-flow content makes sense.

(Note to myself: we may need to additionally deal with placeholder frame inside ruby frame and ruby level container frames as they would no longer be wrapped.)

[css-meeting-bot]

The CSS Working Group just discussed css-ruby] siblings/children vs in-flow siblings/children in box fixup, and agreed to the following:

• RESOLVED: make the proposed change to make processing of ruby only work on inflow content

The full IRC log of that discussion

<dael> Topic: css-ruby] siblings/children vs in-flow siblings/children in box fixup
<dael> github: https://github.com//issues/4958
<castastrophe> castastrophe+
<dael> florian: fixup step. Ruby has structure and needs right boxes.
<dael> florian: Steps written as if they're exhaustive. But they're not b/c ignoring out of flow children of a ruby structure
<dael> florian: I think if something is abspos of ruby it isn't meant to be fixedup. I think things out of flow are left as is. If that's the intent it should say inflow chilred where it says children. If intent is something else I need to know what
<dael> fantasai: Ruby should only be in flow stuff.
<dael> fantasai: Out of flow should be ignored to extent we can ignore it
<dael> florian: I've written text in issue, but it's adding inflow in places where it's implied
<dael> fantasai: Let's add it
<dael> fantasai: We can move on unless there's anything else
<dael> astearns: Objections to make the proposed change to make processing of ruby only work on inflow content
<dael> RESOLVED: make the proposed change to make processing of ruby only work on inflow content