Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposed change for Focus Navigation #381

Closed
wants to merge 88 commits into from

Conversation

TakayoshiKochi
Copy link
Member

As discussed in
#375

This adds a clarification about focus navigation order for
nodes distributed under a slot element.

Also added handling tabindex="-1" case.

As discussed in
WICG#375

This adds a clarification about focus navigation order for
nodes distributed under a slot element.

Also added handling tabindex="-1" case.
@TakayoshiKochi
Copy link
Member Author

@hayatoito PTAL

@@ -1139,6 +1141,27 @@
</li>
</ol>

<p>Likewise, the <a>sequential focus navigation order</a> for <a>distributed nodes</a>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrong... This should not be distributed nodes. This should be assigned nodes.

In addition to that, you should consider the followings:

  1. Do not forget to include descendants of assigned nodes into this focus navigation group.
  2. Consider the fallback contents of slots, in addition to assigned nodes.
  3. When you try to consider 1 and 2, do not forget the case where a slot is a descendant of another slot.
  4. The traversal order is not defined for sequential focus navigation order for distributed nodes. Define the traversal order of this focus navigation group.
  5. Exclude an assigned node (and more) from its root node's focus navigation group. One node should not join more than one focus navigation group.
  6. Mention how tabindex values are scoped at each focus navigation order.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.

Probably we want to start using 'control group' (defined in HTML spec) for the scope.
I am working on rewriting with it.

@TakayoshiKochi
Copy link
Member Author

@hayatoito PTAL.

I tried to get this upstreamable to HTML spec, section 6.4,
but it is hard to do in a single step, as the HTML spec describes the
navigation order as an algorithm to iteratively find the next focusable node,
while the Shadow DOM spec (before my modification) assumes there is a
(somewhat) pre-computed focus navigation order for each scope and
describes how they are merged together.

So this is my attempt to include the #375 as exactly as possible by
following the current way of describing focus navigation in Shadow DOM.

At this point it seems to me to patch the upstream spec requires lot more work.


<p>If a <a>node</a> doesn’t <a data-lt="participates">participate</a> in the <a>document flat tree</a>, the <a>node</a> <strong>must</strong> be skipped from the <a>sequential focus navigation</a>.</p>

<p>The <a>sequential focus navigation order</a> for a given <a>shadow tree</a> <var>A</var> <strong>must</strong> be inserted into the <a>sequential focus navigation order</a> for the <a>parent tree</a> <var>B</var> as follows:</p>
<p>Each <a>shadow root</a> and <a>slot</a> element is a <a>control group owner</a> and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A control group is more upper layer concept, isn't it?

I mean:

  • There is 1 : N relationship between [a control group] and [focus navigation order in each scope].
  • There is 1 : 1 relationship between [a control group] and [global focus navigation order], which is the result of merging multiple [focus navigation order in each scope].

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that frames own its own control group (e.g. <iframe>) and its own sequence, but from user's standpoint, tab navigation sequence look global. Thus sequences for each group is merged.

@hayatoito
Copy link
Contributor

I think you will not get a good definition by the current approach. I recommend you to have a more formal approach:

e.g.

algorithm:

  • Input: a document composed tree
  • Output: set of owners, where each owner owns a group

algorithm:

  • Input: node, NODE, in a document composed tree
  • Output: a group which NODE belongs to

Thus, we can define the disjoint sets clearly. Then,

algorithm:

  • Input: node A and node B where A nad B joins the same group
  • Output: A or B, which comes before in the group

Thus, the oder is clearly defined.

@TakayoshiKochi
Copy link
Member Author

It looks iterative reviews won't work well if completely different structure is suggested.

I've written the draft following your suggestion:
https://docs.google.com/document/d/1mNV2Z231SrAZuMJvBVNfVNHfULkMwUZOZ75vZM1K9zY/edit?usp=sharing (anyone can comment)

For the 3rd algorithm (ordering) in the comment,
for document/shadow root scope, the order is probably obvious (tree order),
but for slot scope (not fallback content scope) the traversal order is depth-first
search on result of getAssignedNodes()?

In addition, do we want to describe how to compare 2 focusable areas with tabindex here
to get the scoped order of the sequence?

That would add almost dead-copy of HTML 6.4.3 and
super redundant.

@TakayoshiKochi
Copy link
Member Author

@hayatoito comment on the doc linked above is welcome.

domenic and others added 15 commits March 10, 2016 14:08
Somehow my brain hadn't made the switch so every time I worked on new
text I kept reintroducing the old name. Oops.
Operating under the assumption that this is going to DOM, @annevk's
specs don't use semicolons :-S
- Figure out where custom elements will go in HTML, and started writing as if they were there
- Fleshes out and moved around examples and motivation to form an "introduction" section
- Separates out and rearranges concepts a bit better (fixes WICG#437)
- Moves the registry to the Window instead of the Document (fixes WICG#369)
- Moves to `window.customElements`, an instance of `CustomElementsRegistry`, with one `define` method currently (fixes WICG#431)
@TakayoshiKochi
Copy link
Member Author

@hayatoito Updated the draft. PTAL.

hayatoito and others added 10 commits March 16, 2016 17:37
Re-fixes WICG#431. Closes WICG#446. Also updates acknowledgments to be easier to
maintain, and adds @rniwa who was missing (in addition to @rianby64 who
spotted this and proposed WICG#446).
- markup for <var>
- period or colon at the end of bullet
- more links to definition
- remove title.
- fix autolink
As discussed in
WICG#375

This adds a clarification about focus navigation order for
nodes distributed under a slot element.

Also added handling tabindex="-1" case.
Addresses comments from hayato.
- markup for <var>
- period or colon at the end of bullet
- more links to definition
- remove title.
- fix autolink
@TakayoshiKochi
Copy link
Member Author

@hayatoito this branch went into some weird state, so I created another PR #447.
Could you take a look?

@TakayoshiKochi TakayoshiKochi deleted the focusScope branch May 6, 2016 10:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants