florian: spatial navigation is similar to sequential (tab) navigation, but different. A similar feature has been available in Presto and others...
... with arrow-based heuristics. so authors need some form of control.

<jihye> https://drafts.csswg.org/css-ui/#nav-dir

florian: enabling component control would at least share a lot of APIs.

So there are a bunch of issues to start from.

rbyers: where are implementations today?

florian: in Presto, and in some forks of Blink (particularly on TVs, etc)

dan appelquist: are the TV semantics captured in this?

florian: yes. It is poorly implemented across UAs.

rbyers: I think everyone agrees it's a valuable feature, just want to get a uniform system.

florian: there is a command-line flag to enable in Chrome

<jihye> option flag; --enable-spatial-navigation

<jihye> > you can enable the heuristic spatial navigation in blink

aboxhall: it was pointed out that this would make a good match with shadow dom (for the boundaries of a spatial navigation container). so having these properties would be a good fit,

<jihye> Your slide in the breakout session yesterday: https://lgeweb.github.io/spatial-navigation/docs/Spatial%20Navigation%20in%20the%20Web%20(LG%20Electronics).pdf

<aboxhall> "Groups of contents based on their functions or behaviors" is the slide I was thinking of

florian: we're not talking about the properties, we're talking about whether the arrow keys are enabled for spatial navigation.

bkardell: There's a difference between navigation/focus, and just changing position in the doc (what happens with arrow keys today)

Ian Pouncey: both of those are interesting - e.g. navigation visually via a grid, but that cell may contain interactive elements (Edit button, e.g.)

(partially missed: discussion of screenreader interaction with focus)

florian: micro-conclusion: for spatial navigation, it seems a CSS property would be better than an attribute, but there is are open questions on how this should interact between content navigation and focus navigation.

cwilso: <exp with Google TV> - was hard to get most developers interested in this.

florian: next two issues: https://github.com/w3c/csswg-drafts/issues/1910 is what's in CSS today

https://github.com/lgeweb/spatial-navigation/issues/2

https://github.com/lgeweb/spatial-navigation/issues/6

https://github.com/lgeweb/spatial-navigation/issues/7

florian: probably should think about JS OM like AOM; have primarily been thinking about the cardinal directions, but I hear the request for more detailed spatial navigation.

aboxhall: we don't have that for sequential navigation, so it would actually be nice to do those at the same time,

florian: maybe we just expose these, and standardize them after we see what developers do with them.

I was initially thinking of up/down/l/r events, but jihye suggested a query "what would be focused if I went up," and then call focus on that, and I think she's right.

aboxhall: interesting.

florian: not sure about directions other than cardinal?

aboxhall: we have a similar problem - how do we express a richer set of actions/relationships. Would be nice to have a consistent set.

florian: naive proposal would be keyword-based, and start with up/down/left/right/next/previous

francois: I think the interesting thing to look at is UI Events.

sangwhan: "Noo!"

<fremy> https://w3c.github.io/indie-ui/indie-ui-events.html

florian: the CSS issue above has the assumption that maybe we don't want to discard the nav-right, etc. properties that are currently defined in CSS.

naive thing to say is search in document order for focusable elements, but there's probably something better we can do there.

robdodson - probably similar to what we do in shadow dom - we find the first child in a shadow-root that's focusable.

kochi- that's contentious. spec says find first focusable element in shadow root.

robdodson: look at delegate in shadow dom spec.

kochi: shadow dom spec does contain some text on that.

<aboxhall> "The first focusable area in focus navigation order"

<aboxhall> https://www.w3.org/TR/shadow-dom/#x5.2-focus

DKA, sangwhan, florian: <discussion of indie UI events> . Summary: it's related but not a direct replacement.

cwilso: sounds like it's time to transfer this into WICG?

florian/jihye: yes

bkardell: goal is to define smallest layer necessary here - and it seems like it shares some interaction with sequential nav - should this be "nav" or something similar, rather than specifically spatial nav?

dan appelquist: seems to make more sense to solve small, discrete problems?

cwilso: seems like a layering question, no?

florian: we need to solve spatial nav, but not forget about sequential nav. Screenreader pointer from earlier is probably related, but shouldn't be solved at the same time.

aboxhall: I agree.
... what are next steps?

dka: jihye and cwilso need to transfer repo

<aboxhall> non-pointer based navigation

dka, florian: sounds good.

sangwhan: last question - should the spec cover the heuristic algorithm?

tantek: it's super-gnarly.

florian: yeah

fremy: but that means we'd not get interop?

<general discontent at being at -30seconds left in discussion>

<break>

Spatial Navigation incubation has moved to WICG: https://github.com/WICG/spatial-navigation

<tantek> chairnick: cwilso

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/??/Ian Pouncey/
Succeeded: s/"Noo!"/sangwhan: "Noo!"/
Present: tantek bkardell_ jihye sangwhan dka aboxhall florian cwilso hober jcraig kochi johnfoliot rbyers robdodson
No ScribeNick specified.  Guessing ScribeNick: cwilso
Inferring Scribes: cwilso

WARNING: No "Topic:" lines found.


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)