[css-scroll-anchoring-1] Can anchor node be an inline-block?

[emilio]

If you go to this test-case, then scroll so that the red box is only partially visible, then click it, what should happen?

Firefox and Chrome disagree on this one, and I think Firefox is right per spec. However the user expected Chrome's behavior.

In particular:

• Firefox chooses the text as the scroll anchor, and thus when the box grows the text keeps its position relative to the viewport.

• Chrome seems to choose the red box as an anchor, and thus when it grows it moves the text down.

I think per spec Firefox is right. https://drafts.csswg.org/css-scroll-anchoring/#anchor-node-selection says:

The anchor node is either a non-anonymous block box or a text node.

Where block box is https://drafts.csswg.org/css-display-3/#block-box. An inline-block element is clearly not a "block box" (its display outside is inline), so the next eligible anchor node is the text.

However it seems Chromium does select inline-blocks as anchor nodes?

Is this an oversight in the specification, or a bug in Chromium?

cc @skobes @eqrion @dholbert

[skobes-chromium]

I think this is a spec bug; we did not intend to exclude inline-block elements from being anchor nodes.

Probably any box-shaped element should be suitable for anchoring to.

[emilio]

What should the spec say about stuff like inline-blocks or inlines split across multiple lines?

[emilio]

In particular, the spec says:

The scroll anchoring bounding rect of a DOM node N is N’s scrollable overflow rectangle if N is a block box, or the bounding rect of its line boxes if N is a text node.

Also, the spec seems messy here. N cannot be both a box and a node.

[emilio]

Also, blink seems to skip inlines, how does that make sense while not skipping inline-blocks?

So, basically, the blink condition for whether something it's an acceptable anchor if I'm reading the code right is:

!IsAnonymous() && !IsInline() && (IsText() || IsBox())

What does IsBox() really mean? what is the rect that blink uses for boxes that are not blocks? Why does the above condition make sense?

[skobes-chromium]

An inline-block has a "layout box" in Blink. Like a block, it occupies a rectangular space, so its coordinates are simple to reason about.

Blink skips inlines because we didn't want to worry about elements that are split across lines. I suppose we could have taken an enclosing rect around the line boxes similar to what we do for text nodes, but we didn't find cases where this seemed important.

We do anchor to img elements.

[emilio]

Right, I see that an inline-block returns true for IsBox() in Blink, so does probably LayoutReplaced and all that.

But we need to come up with a definition that we can interoperably implement. "Everything that inherits from LayoutBox in Blink but it's not a LayoutInline" is not a sensible thing to put on a spec.

[skobes-chromium]

https://www.w3.org/TR/css-display-3/ has some concepts that may be useful here, such as "block container" and "replaced element".

[emilio]

Sure, but is that what Blink implements? There's a whole bunch of stuff inheriting from LayoutBox, not all of those are block containers or replaced.

[skobes-chromium]

I think those are the important ones. We can patch for other cases as they arise. I wouldn't overfit the spec to the exact set of things that make IsBox() true.

[emilio]

I don't think that approach really works to get interoperable implementations...

We should define exactly what it's supposed to be an anchor, and we should adjust implementations to follow it.

Do you think everything but inline boxes and ruby containers would be a good definition? Those are the only non-text things that can split across lines, afaict.

[skobes-chromium]

Sounds good to me.