Description
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, 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, steps 5.1 and 7 invoke finding 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:
spatial-navigation-candidates: visible | allIf we add this, I think we could remove navbeforescroll and not lose any useful capability, solving the performance concern.