Re: [w3ctag/design-reviews] Spatial Navigation (#287)

Thanks for the detailed feedback!

I think some of the issues can be solved as below:

### Hostile iframe

Yes, I think the Feature policy can solve this issue.
We are discussing this in this approach, and I've written the proposal about the Feature Policy:
 - https://github.com/WICG/spatial-navigation/issues/58#issuecomment-437228150
  (More detail: https://github.com/WICG/feature-policy/issues/175)

### Distance computation algorithm

1. Define more reasonable distance function

   I've started to investigate the distance measuring algorithm.
   Using the listed test cases, we can choose a reasonable algorithm.
   The test cases are written with the template of the web platform test.
   Please note that the result of each case doesn't match with the current spec, but the UX point of view decides it.

   - Test page: https://jihyerish.github.io/spatial-navigation/tests/ux/result.html

   Also, the additional distance algorithms will be added.

2. Define P1 from the starting point and P2 from the candidate element for the distance function

   Depending on the result of "Defining the distance function", we can also decide how to define P1 and P2 for the distance function which is described in the current spec.
   - Related issue: https://github.com/w3c/csswg-drafts/issues/3353

### Focusable Areas

I'm not sure I understand this point clear.
Is this (A) or (B)?
(A) Add the options object similar to the IntersectionObserver() for the [focusableAreas()](https://drafts.csswg.org/css-nav-1/#dom-element-focusableareas)
(B) Use the IntersectionObserver instead of the [focusableAreas()](https://drafts.csswg.org/css-nav-1/#dom-element-focusableareas) 

If it is (A), using the `root`, `threshold` field of the options object seems useful.
But is it possible to apply this behavior to the iframe which is the cross-origin from the current document?

(B) doesn't seem to match with the intention of the  focusableAreas().
The target elements and the expected result for both API are different.
The  focusableAreas() returns the visible focusable element inside the specific element (in general, container element).
However, the IntersectionObserver let us know whether the specified element is visible or not inside the container element.

### Returnable focus traversal
(e.g. pressing the right-left-right arrow keys makes the focus return to the initial element)
This behavior is useful, but it seems hard to be handled by combining with the distance measuring algorithm.
I can think of it the other way around, adding the option for taking the already visited element higher priority in the selecting the best candidate step, after measuring the distance.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/287#issuecomment-443124965