[css-nav-1] Condition of visible candidates for custom spatial navigation container

[jihyerish]

In the current spec, the candidates within the spatial navigation container are the visible focusable element in the inside area of the spatial navigation container.
The inside area of container C is defined as below:

• the optimal viewing region of C if C is a scroll container,
• the viewport of C’s browsing context if C is a Document,
• the border box of C otherwise

However, the third case, when the container C is the element specified with spatial-navigation-contain: contain (which means custom spatial navigation container), there are some confusing cases if the inside area is defined as the border box of the container.
For example,

 <div id="container1">
    <div id="container2" style="--spatial-navigation-contain: contain;">
      <button id="b1" style="top:40px; left:-60px; background-color: purple;"></button>
      <button id="b2" style="top:30px; left:200px; background-color: pink;"></button>
    </div>
    <button id="b3" style="top:10px; left: 20px; background-color: green;"></button>
  </div>

Depending on the current definition, button#b1 and button#b2 aren't included in the candidates of #container2 because those are out of #container2's the border box.
But button#b1 and button#b2 are definitely visible, so someone may feel it's strange.

Therefore how about changing the definition of inside area for the custom spatial navigation container?
It could be changed to the viewport of the container's browsing context.

[hugoholgersson]

In general, and not only for custom containers, I don't think SpatNav should care too much about DOM order (unless perhaps, when breaking ties). Users only see "visual order" so that's what's most important?

I think these two phrases need a change:

Let focusables be the set of all the focusable areas whose DOM anchor are descendants of C.

and

Let insiders be the subset of candidates items whose DOM anchor are descendants of searchOrigin...

Not only can child nodes be visually placed outside C (as in your example), siblings and parents of C can be visually placed inside (think "on top of") C too...

[bokand]

This seems like an odd edge case, what does it mean for a container to have visible elements outside of it?

Perhaps --spatial-navigation-contain: contain; should imply paint containment/overflow clipping?

[jihyerish]

SpatNav should care too much about DOM order (unless perhaps, when breaking ties). Users only see "visual order" so that's what's most important?

Yes, you're right. The order decided by the visual layout is the most important, but we have the 'container' concept in the spec. That is making the elements within the same container take higher priority when finding the element where the focus will go next.

Not only can child nodes be visually placed outside C (as in your example), siblings and parents of C can be visually placed inside (think "on top of") C too...

This is related to the discussion in #3386 (comment).
So, do you think those two sentences would be changed like below? :

Let focusables be the set of all the focusable areas whose DOM anchor are visually inside the border boundary of C.

and

Let insiders be the subset of candidates items whose DOM anchor are visually inside the border boundary of C.

[jihyerish]

This seems like an odd edge case, what does it mean for a container to have visible elements outside of it?

You're right. This may be a rare case.
The container indicates the elements which share the same container will take higher priority.
The grouped elements in a container mean they are semantically related contents.

Perhaps --spatial-navigation-contain: contain; should imply paint containment/overflow clipping?

spatial-navigation-contain: contain; doesn't work like overflow: clip.
If it does, the element which is clipped can be unreachable.

[hugoholgersson]

So, do you think those two sentences would be changed like below? :

Let focusables be the set of all the focusable areas whose DOM anchor are visually inside the border boundary of C.

Sounds OK if you remove the visibleOnly argument (it will have no effect?) and stop saying "DOM anchor" (use "boundary box" instead). The DOM anchor of an <area> is its <img>. An <area>'s <img> can be [partly] visible while the <area> itself isn't..

and

Let insiders be the subset of candidates items whose DOM anchor are visually inside the border boundary of C.

To avoid confusion around image maps, and to emphasize that we only really care about boundary boxes, I'd instead write something like:

Let insiders be the set of focusable areas whose boundary boxes are completely inside searchOrigin.

Note that we in Chrome don't handle insiders as a separate case. They are handled in the same code flow as any other focusable but with a favored distance score. Also, note that we simply define insiders as "candidates that are completely inside the current focus rect". Perhaps you could copy Chrome here?

[frivoal]

I think this is mistaken:

Let insideArea be:

• the optimal viewing region of C if C is a scroll container,
• the viewport of C’s browsing context if C is a Document,
• the border box of C otherwise.

and the last one should have been:

the optimal viewing region of C's nearest scroll container ancestor

[jihyerish]

Sounds OK if you remove the visibleOnly argument (it will have no effect?) and stop saying "DOM anchor" (use "boundary box" instead). The DOM anchor of an is its . An 's can be [partly] visible while the itself isn't..

visibleOnly argument affects the result of focusables depending on its value, and its default value is true.
This detailed description about visibleOnly is related to focusableAreas() API.
So, please just take account when true is given to visibleOnly for the default behavior of spatial navigation.
(If it is specified with true , focusables are the set of all the focusable areas which are visually inside the border boundary of the container.
Else, focusables are the set of all the focusable areas (including invisible ones) which are children of the container.)

Let insiders be the set of focusable areas whose boundary boxes are completely inside searchOrigin.

Thanks, your description is simpler.