[csswg-drafts] [css-nav-1] changing the spatnav scroll controls from JS to declarative (#3401)

frivoal has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-nav-1] changing the spatnav scroll controls from JS to declarative ==
During TPAC, several engineers from Google (including I believe @eaenet and @chrishtr ) expressed concern over the `navbeforescroll` event, on the grounds that having to run any kind of synchronous JS right before scrolling (and even more so in the middle of scrolling, as could be the case if the user tries to repeatedly navigate in the same direction) was a performance concern.

Changing from an even to an observer would slightly attenuate that concern as it is cheaper, but not completely as that still involves running JS synchronously at that point.

In theory, I believe the 3 events (`navbeforescroll`, `navbeforefocus`, and `navnotarget`) are necessary and sufficient to be able to intercept spatnav before anything happens. However, in practice, I can only think of one use case that calls for `navbeforescroll`: the one illustrated in [example 5](https://drafts.csswg.org/css-nav-1/#focus-only), which allows the authors to switch the behavior from searching for candidates from within just the visible elements in the container to within all elements in the container regardless of visibility.

In [the spatial navigation steps](https://drafts.csswg.org/css-nav-1/#spatial-navigation-steps ), steps 5.1 and 7 invoke [`finding focusable areas`](https://drafts.csswg.org/css-nav-1/#find-focusable-areas), relying on the optional `visibleOnly` argument defaulting to `true`. Invoking it with `visibleOnly` set to `false` would switch to the other behavior we're trying to cover here.

Providing a declarative solution to this problem is very easy, and has none of the performance downsides: an inherited css property whose computed value on `searchOrigin` in step 5.1 or on `container` in step 7 would act as the switch between the two modes. Strawman name:
```css
spatial-navigation-candidates: visible | all
```

If we add this, I think we could remove `navbeforescroll` and not lose any useful capability, solving the performance concern.


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3401 using your GitHub account

Received on Thursday, 6 December 2018 07:14:57 UTC