[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.

[css-meeting-bot]

The CSS Working Group just discussed Can an anchor node be an inline block, and agreed to the following:

• RESOLVED: An anchor node only can be every box except a non-atomic inline box
• RESOLVED: An anchor node can be any box except non-atomic inline boxes

The full IRC log of that discussion

<myles> Topic: Can an anchor node be an inline block
<astearns> github: https://github.com//issues/4247
<myles> emilio: A bit of the issues we've found with the spec, the spec uses terms, and the terms don't map to the implementation that wrote teh spec. The spec says "the anchor is either a block box or text" but what blink does is "well any thing that is non an inline or an anonymous block can be an anchor"
<myles> emilio: that is not great. I think we've reached agreement with Steve about better terms for the spec. The spec needs some love.
<myles> emilio: I'm happy to help out to refine the spec.
<myles> emilio: Proposal: Changing the definition of anchor node to be every box but inline boxes and fragmentainers, which are the only things that fragment across <missed>
<myles> emilio: This is what Blink does.
<myles> astearns: Any concerns?
<myles> iank_: There's some discussion on the github issue?
<myles> oriol: Instead of explicitly specifing the inlines, can we use atomic inline from the display specification? We can use terms from that spec for future additions to the spec?
<myles> emilio: So right now, the definition is accurate. That term from the other spec sounds better.
<myles> emilio: Proposal: An anchor node can be every box except a non-atomic inline box
<myles> RESOLVED: An anchor node only can be every box except a non-atomic inline box
<myles> RESOLVED: An anchor node can be any box except non-atomic inline boxes