Tag review preparation

Hello TAG！

I'm requesting a TAG review of:

• Name: Spatial Navigation
• Specification URL: https://wicg.github.io/spatial-navigation/
• Explainer, Requirements Doc, or Example code:
  • explainer
  • Overview section in the spec
  • Several examples in the spec, including sample code in the api section
  • Polyfill (this is early stage, has bugs, and is not fully spec compliant yet. We do not request a review of the polyfill, but it may be useful to try things out).
  • Demo page using the polyfill
• Tests: just starting, there a few tests in our wicg repo. Will submit to WPT later.
• Primary contacts: http://github.com/frivoal/ & http://github.com/jihyerish/

Further details (optional):

• Relevant time constraints or deadlines: No strict deadline, but speedy feedback appreciated. Unless someone raises a big issue, high level design is complete. Polyfill implementation started. Details still need more work, and native implementation not started yet (but we will start lobbying for that soon). In other words, big changes are still possible at this stage, but it will soon start getting more expensive.

• I have read but not yet filled out the Self-Review Questionnare on Security and Privacy.

  Known issues:

  • https://github.com/WICG/spatial-navigation/issues/28
  • https://github.com/WICG/spatial-navigation/issues/58

• I have reviewed the TAG's API Design Principles

  • Open issue about 3.1 https://github.com/WICG/spatial-navigation/issues/60

  • Not following advice from 3.2, in favor of this sentence from the DOM spec:

    Apart from signaling, events are sometimes also used to let an application control what happens next in an operation. For instance as part of form submission an event whose type attribute value is "submit" is dispatched. If this event’s preventDefault() method is invoked, form submission will be terminated.

    Can consider alternative approaches, but we think the current design makes sense in this case. If you disagree, please give an example of what would be better (including how it would work with the examples in the spec).

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]