[css-ruby] "consecutive" in the Anonymous Ruby Box Generation, and out of flow

[frivoal]

Several steps of the ruby box fixup use the notion of "consecutive" boxes. Consecutive is defined by CSS2 in the anonymous table object section:

Two sibling boxes are consecutive if they have no intervening siblings other than, optionally, an anonymous inline containing only white spaces. A sequence of sibling boxes is consecutive if each box in the sequence is consecutive to the one before it in the sequence.

(css-tables agrees with that definition)

Importantly, this does not say that two boxes are consecutive when the only thing that separates them is an out-of-flow box. Leaving aside whether that's a good idea for tables (tables are weird anyway), it has odd consequences for ruby (in decreasing order of weirdness, in my opinion):

8. Generate anonymous level containers: Any consecutive sequence of ruby bases [...] not parented by a ruby base container is wrapped in an anonymous ruby base container. Similarly, any consecutive sequence of ruby annotations [...] not parented by a ruby annotation container is wrapped in an anonymous ruby annotation container.

Thus, in the following example, the two <rt>are not consecutive, and end up in two different anonymous ruby annotation container, and thus two different levels:

<style>i { position: absolute; }</style>
<ruby><rb>b</rb><rt>a1</rt><i></i><rt>a2</rt></ruby>

3. Wrap misparented inline-level content: Any consecutive sequence of text and inline-level boxes directly parented by a ruby container or ruby base container is wrapped in an anonymous ruby base. […]

Thus, in the following example, the two spaces are not consecutive, and end up in two different anonymous ruby bases (only one of which will be removed by step 4's trimming of leading white space):

<style>i { position: absolute; }</style>
<ruby> <i></i> <rb>b</rb><rt>a1</rt></ruby>

2. Generate anonymous ruby containers: Any consecutive sequence of improperly-contained ruby base containers, ruby annotation containers, ruby bases, and/or ruby annotations (and any intervening white space) is wrapped in an anonymous ruby container.

Thus, in the following example, we would end up with two ruby containers: one containing the first base only, and one containing the other base and the two annotations.

<style>i { position: absolute; }</style>
<rb>b1</rb><i></i><rb>b2</rb>
<rt>a1</rt><rt>a2</rt>

This is all technically possible, and anchoring out of flow elements in the middle of a ruby structure is an odd case anyway, so maybe it doesn't matter, but it doesn't seem to me to be inherently wrong to attach abspos elements pretty much anywhere (maybe they're being used for tooltips?) in the document, and I would not expect them to disturb the layout of the elements they're being anchored in.

Assuming that we cannot change what consecutive means for tables, how about coining a different term which would allow intervening out of flow element? Maybe contiguous?

Two sibling boxes are contiguous if they have no intervening siblings other than, optionally, any combination of anonymous inline boxes containing only white-space, and out-of-flow boxes. A sequence of sibling boxes is contiguous if each box in the sequence is contiguous to the one before it in the sequence.

[frivoal]

we should have a look at what existing implementations do, particularly firefox.

[frivoal]

From superficial testing, Firefox's behavior seems to neither follow the specified behavior nor the one I suggest in case 1 (it creates an additional segment and puts "a2" there), and to be consistent with the behavior as specified (not the one I am proposing) for case 2 and 3.

So if we go by compat only, Firefox seems closer to the spec than to my suggestion, though it doesn't exactly match either.

From a usage point of view, I still think my suggestion makes more sense, but it doesn't seem terribly important either, so if we're stuck with compat (I doubt it), or if it would be hard to implement (I don't know), I'll yield.

@upsuper, what do you think?

[frivoal]

Upon further thinking, it seems to me that firefox's behavior is better explained by saying considering that it an abspos element leaves behind an anchor, and that that's treated like any other in-flow thing.

[upsuper]

Yes, Firefox's behavior is that an abspos element leaves an anchor which is treated like an in-flow thing. As an implementation details, we put a placeholder in the normal flow in order to track its normal position and probably for other things.

I don't think what you proposed here would be terribly hard to implement, but the whole box fixup thing has been reasonably complicated in implementation already and I'm not very keen to further complicate it if not necessary.