@rule for nav-loop?

[frivoal]

It is not entirely clear to me that having different values of nav-loop on different parts of the page is useful. If there are indeed use cases that would benefit from it, the then current design (modulo issue #1 ) is fine, but if not, it introduces unnecessary complexity.

It also seems like an easy way to accidentally create designs that would frustrate users: if a DOM sub-tree has nav-loop: repeat, but there are focusable elements outside of that subtree, the users will not be able to get there. The same thing can already happen with poor usage of nav-up / nav-down / nav-right / nav-left, but doing so accidentaly seems more likely with nav-loop as a property.

This would solve the key use case, without having that downside:

@nav-loop: auto | repeat | repeat-x | repeat-y | no-repeat

Alternatively, if we end up with other spat-nav related things that belong in at-rules, we could have:

@spat-nav {
  [...]
  loop: auto | repeat | repeat-x | repeat-y | no-repeat;
}

Unless someone has use cases that call for the property, I'd suggest keeping it simple and using an at-rule.

[jihyerish]

Yes, I also prefer to specify focus looping with at-rule, and a descriptor something like loop at you mentioned above seems nice to me.

[frivoal]

As discussed in issue #3, enabling spat-nav on a component basis, rather than page basis, seems to make sense. In that case, this should probably be possible to enable/disable with the same granularity.

That said, Like issue #1, I think we should postpone this until we get the APIs discussed in issue #2 so that we can try to polyfill and/or experiment with this first.

[jihyerish]

I think this feature, the focus looping doesn't have to be supported by CSS.
The event such as noFocusableElementFound can be combined with this feature.

[frivoal]

I agree, at least for a first pass. If people use it all the time, maybe we can introduce an declarative API for it later on.

[frivoal]

We don't need so many issues about nav-loop.
Closing as a duplicate of #1