Keep window.navigate() or not about spatial-navigation HOT 7 CLOSED

Add a description about window.navigate() to define its scope more clearly. (Action item 1)

Agreed

Consider about renaming navigate()

I have no objection to trying to find a better name, but I don't know of a better name.

how about closing this issue after (Action item 1) is done and discussing (Action item 2) on the new issue?

Yes.

from spatial-navigation.

I've made a PR (#118) for Add a description about window.navigate() to define its scope more clearly, and a new issue (#120) for discussing its name.

from spatial-navigation.

A new DOM method directly attached to the window object must be carefully designed in terms of a essential requirement for meaningful use cases.

For the testing purpose, It seems identical to ones using spatNavSearch() as follows:

• window.navigate("right");
• document.activeElement.spatNavSearch( { dir: "right" } ).focus();

You can see a simple test code to understand the things above in the following link.
https://codepen.io/anawhj/pen/PaeRYJ

Also, I'm not sure we have another use cases that is required to use the window.navigate() method. Even if any, we can make it by using other spatnav APIs. (eg. spatNavSearch)

from spatial-navigation.

We have found a few use cases for window.navigate:

• If the page author wants to interupt navigation to do some asynchronous operation (e.g. load more content in an infinite scroller) then resume where they cancelled, they can use this API.
• To create on on screen directional pad (to be clicked), you'd use this API
• If an author wants to manually bind the arrow keys (or some other key of their choice) to spatnav regardless of browser defaults (which is something that component authors may very well want to do), they can use this API.

It seems identical to ones using spatNavSearch() as follows:

• window.navigate("right");
• document.activeElement.spatNavSearch( { dir: "right" } ).focus();

This is not actually identical. window.navigate triggers the whole spatial navigation steps as defined in section 7.2, including recursive search up the tree and event firing. This may result in a new element being focused, but it may also result in a scrollable element being scrolled, and some events will be fired.

document.activeElement.spatNavSearch( { dir: "right" } ).focus(); is one sub-step in that broader algorithm, corresponding to find focusable areas and select the best candidate of section 7.3. It only searches for a focusable element, non recursively, does not fire events, and does not scroll anything…

So they are not equivalent.

In any case, there is an issue inline in the spec highlighting that this API is less certain than some other parts, so if we end up having actual problems with it, we have identified it as something that can be removed. But I don't think we gain anything to removing it preventively, especially when it has some known use cases.

from spatial-navigation.

Thank you for the clarification. I totally misunderstood the functionality of window.navigate(); described in spatnav spec. I agreed that it definitely causes the different result. The second command doesn't even consider an implicit(no specific DOM element) starting point as well.

I also agreed that window.navigate(); could be used to helpfully support some use cases, so it seems good to keep window.navigate(); in the spec for the time being.

In my thought, the core behavior of window.navigate(); is not a navigation itself (e.g. scrolling isn't relevant to a navigation), but just a simulation as if user pushed an arrow key. In all circumstances in a web page, window.navigate(right); can be perfectly mapped to the result of a right arrow key inputted by a user in terms of moving focus, scrolling, and triggering events.

With that promises above, I'd like to put some issues regarding window.navigate(); as follows:
(We could separately make each issues below in the future, if needed, so this issue can be closed for now.)

1. renaming of navigate
   In the boundary of the web, a navigate term has been frequently used such as page navigation, sitemap, dropdown (see here). The focus navigation is one of them, but it seems to be a bit confused if someone first see window.navigate(dir);.

2. no support for the key input simulation on the web for now
   In terms of web usability, the simulation of key input hasn't been allowed in the web until now, even though several web developers want to use it. That is the reason "javascript simulate key input" is one of the famous questions in google search. (auto completion). I put a bold sentence in a stackoverflow page as follows:

But as of recently, there is no [DOM] way to actually trigger keyevents leaving the browser-sandbox. And all major browser vendors will adhere to that security concept.

If we want to simulate the arrow key input via a standard web API, it seems we need to carefully design the proposed API considering the web usability.

from spatial-navigation.

In my thought, the core behavior of window.navigate(); is not a navigation itself (e.g. scrolling isn't relevant to a navigation), but just a simulation as if user pushed an arrow key.

Yes and no. Spatial navigation is typically triggered using arrow keys, but it is not necessarily. Depending on the user agent, Spatnav can also be triggered using different keys, or gestures, voice commands, or anything.

Also, arrow keys do other things that spatnav: move the text insertion caret, change the volume on a video control...

window.navigate() doesn't do all the other things that arrows keys may do. Only trigger spatnav.

At the same time, it is true that the name "navigate" is very generic, and could be confusing. For example, this API has nothing with navigating to a new URL, or with the <nav> element; so maybe it would be good if we could find a more specific name.

However, I don't know what name to use.

• window.navigateFocus() doesn't seem right, since it also involves scrolling
• window.spatialNavigate() would sort of work for now, but blocks us from extending it later to also support sequential navigation with something like window.navigate("next"). That is not a priority for now, but we should leave that door open.

from spatial-navigation.

For UA's input testing purpose, window.navigate() can be used, but it may be tricky because there are no limitations of input method or input processing of UA for this API.
Maybe we can suggest a new API for the testing purpose which can emulate whole web engine processing from key inputs, but I'm afraid that it's out of the scope of the Spatial Navigation.
So, it would be better for us to focus on the spec for now. : )

Therefore, I suggest:

• Add a description about window.navigate() to define its scope more clearly. (Action item 1)
  Such as, window.navigate() emulates spatnav focus moving and scrolling from the directional input.
• Consider about renaming navigate() (Action item 2)
  To be honest, it's hard to find out what would be the best name instead of this but it's true that the current name is confusing.
  We also need to think about the possibility to use this in the sequential navigation, but I wonder what will be the use cases for it.
  Can 'directionalNavigate' include spatnav and seqnav?

Also, how about closing this issue after (Action item 1) is done and discussing (Action item 2) on the new issue?
In the new issue, I'd also like to discuss about changing the abbreviation of "spatnav" to "spatialNavigation", because I've received this same opinion from several people.

from spatial-navigation.