[css-scroll-anchoring-1] `display: flex` can't be selected as an anchor node

[eqrion]

The anchor selection algorithm is specified to only select a non anonymous block box or text node. This means that display: flex element can't be an anchor node.

It appears that Chrome allows display: flex to be anchors in this test case.

The specification should probably be updated to allow this, unless this is a bug in Chrome.

[eqrion]

It also seems like display: inline-block can also be selected as an anchor node in Chrome in this test case.

[dholbert]

Relatedly: what about <span> with display:inline? That's definitely not a "block box", and definitely not a "text node" (though it kind of lays out like one, e.g. getting split across lines of its containing block).

And what about form controls, e.g. <button> and <input>? What about <img>? None of these are "block boxes" nor "text nodes".

Right now the spec defines its term scroll anchoring bounding rect of a DOM node N in such a way as to assume that every node N must be either a "block box" or a "text node", but clearly that's inaccurate/incomplete.

Here's the problematic spec text from the bottom of section 2.1 (bulleting added for emphasis):

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.

This leaves this rect undefined for most DOM nodes (everything with display: [anything but block]).

This spec text needs fixing to clarify what it actually intends to say and to ensure this rect is actually defined for all DOM nodes.

[eqrion]

cc @dbaron @theres-waldo @skobes

[dholbert]

It also seems like display: inline-block can also be selected as an anchor node in Chrome

One more note on this: @eqrion found that the web-platform test start-edge-in-block-layout-direction.html currently relies on the browser selecting an inline-block as an anchor node (which goes against what the spec says right now).

He's landing a small patch (with r=me) to remove that dependency, so that the test is better-justified by the current spec text -- just adding a block-level box inside of the inline-block. And this new block-level box is allowed to be selected as an anchor, per the current spec text.

[skobes-chromium]

The spec states this more directly near the top of 2.1:

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

This was mainly to avoid the difficulty of trying to define a bounding rect for things that aren't box-like. The intent was not to exclude inline-block, img, or flex boxes, so I suppose the language here should be updated to allow those.

[dholbert]

Maybe it wants to say "block-level box", then? (Not "block box")

Though, note that even block-level elements can be fragmented just like inline-level elements can (across columns of a multicol, rather than across lines). So if fragmentation is the non-rectangular thing we're trying to avoid, then blockness doesn't necessarily help (but "box" might be sufficient to point to just a single fragment).