[css-nav-1] Proper definition of 'spatial-navigation-action' property

[jihyerish]

spatial-navigation-action CSS property can define the spatial navigation behavior for the scrollable element.

Definition:

Name	spatial-navigation-action
value	auto | focus | scroll
initial	auto
applies to	scroll containers
inherited	no

This demo shows how this works.

Currently, the spec describes this property is applied to scroll containers and not be inherited.
I'd like to ask if this description is proper.

If the scrollable element is specified with spatial-navigation-action, its children element, which are all kinds of element also be affected by the feature of the property.

For example, if there is a page like below,

<div class="container" tabindex="0" style="width:600px; height:100px; overflow-y: scroll; spatial-navigation-action: focus;">
   <button id="box1" class="box" style="top: 170px; left: 100px;"></button>
   <button id="box2" class="box" style="top: 550px; left: 100px;"></button>
  ...
    <button  id="box10" class="box" style="top: 550px; left: 100px;"></button>
</div>

('focus' value for spatial-navigation-action means that the directional input only works for moving the focus, not scrolling.)
Once the focus moves inside .container element, the focus moves among button elements.
But the behavior of moving the focus by directional input works as just moving the focus and not scrolling manually. This is because the button elements still are affected by spatial-navigation-action: focus which specified on the .container element.

Does the current description of the property suit the intended behavior that is described in the spec and shown in the demo above?

For my understanding, the CSS property which isn't inherited but affects the applied element's children is the one who creates the stacking context.
Do I understand right?
Can spatial-navigation-action also create a stacking context?

[jihyerish]

@frivoal, I wonder your opinion about this.

I think the property description would be one of :

1. spatial-navigation-action: auto | focus | scroll (Applies to: all elements, inherited: yes)
2. spatial-navigation-action: auto | focus | scroll (Applies to: scroll containers, inherited: no)

[css-meeting-bot]

The CSS Working Group just discussed [css-nav-1] Proper definition of 'spatial-navigation-action' property.

The full IRC log of that discussion

<myles> Topic: [css-nav-1] Proper definition of 'spatial-navigation-action' property
<myles> GitHub: https://github.com//issues/4449
<myles> astearns: In the issue, you asked florian for an opinion. We don't have his opinion, and he's not here.
<myles> astearns: should we discuss this now?
<myles> jihye: I also asked another member of CSSWG about this issue. This is general CSS questions. I think we can proceed
<myles> astearns: OK
<chris> Amelia, https://wiki.csswg.org/spec/publish
<myles> jihye: This issue is about spatial navigation actions, and CSS properties.
<myles> jihye: Before going into the detailed discussions, i'd like to introduce spatial navigation actions. They are a CSS property, which can define the behavior for a scrollable element. The spatial navigation behavior is when a scrollable element has focus, and the user triggers spatnav, if there is af ocusable element in the scrollable element, the focus goes to the focusable element. Otherwise, scrolling happens.
<jihye> https://wicg.github.io/spatial-navigation/demo/sample/api_spatial_navigation_action.html
<myles> jihye: IF the focus value is given to this property, spatnav on the scrollable element only works to move. If the scroll value is given, spatnav only works for scrolling the scrollable element. You can see how it works with this link ^^^
<myles> jihye: I'd like to ask that the definition of this property is proper. Currently, the spec describes this property as "which is applied to scroll element, and not inherited" but the point that I'm confused about is the attempted behavior of this property is it also affects the spatnav behavior for children element of the scrollable element. The description says it is only applied to the scrolled element, not all elements. So it sounds like the property will
<myles> not affect the children element of the scrollable element, which teh spatial navigation action property is specified.
<myles> jihye: It seems like the intended behavior and the description in the spec don't match. Is this proper or not?
<fantasai> no, we resolved to get rid of Media Type
<myles> myles: I thoguht we resolved to get rid of all the "applies to" lines
<myles> AmeliaBR: There was soem discussion about whether it was normative or informative. The question here is you want to change it so the property both affects the scrollable container directly and the children of the scrollable container as far as how it affects whether they trigger scrolling ont he parent
<myles> jihye: I researched another CSS property which can affect its children elements. From my understanding, that property creates a stacking context, but that property is about layout. But this spatnav property isn't about layout, so it doesn't seem like a match
<myles> AmeliaBR: We don't have anything equivalent
<myles> AmeliaBR: Any other CSS property that defines whether a scroll is triggered separate from whether a scrollbar appears on this element or a parent element
<myles> AmeliaBR: It seems to me perfectly natural to say that this also can work on a property on a child element and it affects the scrollers going up. The concern then is what happens if you have nested scrolling containers. Is there a way to control where that scrolling affect stops? Vs if you specifically set the property on the scroll container itself.
<myles> AmeliaBR: Then it's more obvious what it applies to, because nothing bubbles up like an event
<myles> bkardell_: If you have focusable items ....
<myles> bkardell_: As I understand it, the reason this is desirable is because you have potentially a limited number of controls. You don't have tab buttons and shift-tab and things like that, so we want to define how that works with a d-pad controller. "spatially" navigate. So you want to move focus with those sorts of mechanisms. But in this example, you have a scroll container that contains focusable items. But if you use scroll, does it make it effectively not
<myles> focusable anymore?
<myles> bkardell_: How would someone focus the child?
<myles> jihye: If the value is "scroll" of this property, then the focus will not move inside or move between the child elements in the scrollable element. But pressing down or up arrow key will only scroll the scrollable element. If the focus or auto value is given to this property, the child element inside the focusable element will be focused and the focus will move between them.
<myles> bkardell_: right.
<myles> AmeliaBR: The issue isn't that you can't focus elements when you're using the scroller thing, it's that you don't jump to the next focusable element, you jump to the next element whether its focusable or not, and in that way you end up scrolling the scroll container. Otherwise, it skips the next items and jumps to the next focusable one
<myles> jihye: Yes, that's right
<myles> bkardell_: "auto" makes sense to me, "focus" makes sense to me. They are a different experience of the same thing. But "scroll" ... do we have other CSS properties that prevent your normal focusability?
<myles> myles: we have display:none...
<myles> bkardell_: but it's not on the screen
<myles> jihye: the "scroll" value is at risk. It can be useful when there is an iframe which can scroll but the user doesn't want to move inside it.
<myles> jihye: But I think this is a little bit out of the topic that I wanted to discuss.
<myles> jihye: I wanted to discuss - this property can apply to child elements of scrollable elements. Is this proper or not?
<myles> heycam: Generally, the "applies to" line is informative and not normative (as AmeliaBR was saying). It's just a general description of where you expect the property to have an effect. The behavior of scrolling will depend on the child elements and their focusability. It makes sense to say it applies to the scrollable element. The rest of the definition can say what it wants about the child elements and how they are focused.
<fantasai> yes, it's about on what elements can you set the property to have an effect
<myles> AmeliaBR: You mentioned in the issue, if we switch to that model where its a property of the individual elements rather than a property of the scroller, it needs to be inherited.
<myles> AmeliaBR: It would be a normative change
<myles> myles: can we make this match how scroll snapping works?
<myles> AmeliaBR: how does scroll snapping work?
<myles> <silence>
<myles> fantasai: scroll-snap sets something on the scroll container to define how snapping happens, and there are additional properties on child elements about whether that child should be paying attention to it. <provides an example>
<myles> myles: sounds to me that this should go on the scroller for spatnav
<myles> astearns: Another argumetn for putting it on the scroll container and having it not inherit, is we might get an incoherent set of things to do if the some subset of elements disagree about which value is specified. Inheriting to the children means the children can override what's on the container.
<myles> jihye: If we match the spatnav action navigation property with scroll snap, then we'll change the definition to say it applies to all elements and its inherited?
<myles> astearns: I'm arguing for it to stay the way it is. Where it applies to scroll containers and does not inherite. You can define how the children behave as saying "look at your nearest ancestor that its a scroll container and see what its spatnav action is"
<myles> jihye: It means that the current definition of the spec is reasonable and doesn't have to change.
<myles> astearns: yes
<myles> AmeliaBR: yes, unless you can come up with a specific example where you'd want the behavior to change partway through a scrollable container. I don't know what that might look like. Where you actually want different children to have different behaviors.
<myles> astearns: Can you think of a case where you'd have a scroll container where some of its children would want to focus and others would want to scroll?
<myles> <silence>
<myles> astearns: Why don't we resolve on this issue, saying we are not going to change the definition of how spatial-navigation-action at this point, but if come up with a use case for making the property inherit, we can change it at that point.
<myles> jihye: okay
<myles> jihye: The spatial-navigation-action property behaves as defined, and does not inherit.
<myles> astearns: Is there an issue for the scroll value? Is that why it's at risk?
<myles> jihye: It seems like the scroll value is less important than other values such as "auto" or "focus". This is the main reason.
<myles> astearns: bkardell_ could I have you take a longer look at this, and if you have concerns about the "scroll" value changing the focus behavior, have you raise an issue on it?
<myles> bkardell_: Yes. It's been a while since I looked at this.
<myles> bkardell_: In Toronto, we had <missed> from google present an interesting related thing. jihye, have you worked with him?
<dbaron> s/<missed>/David Bokan/
<myles> jihye: Yes, I talk with him regularly. We are investigating about that concept. I think this concept is not mature enough. We have to think about more details about that. We are working on that.
<myles> bkardell_: He would be good to review the question I raised. I can talk to him
<myles> jihye: thank you.