W3C home > Mailing lists > Public > public-appformats@w3.org > April 2007

XBL2 and tabbing

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 10 Apr 2007 20:27:57 -0700
Message-ID: <461C55BD.4090407@sicking.cc>
To: public-appformats@w3.org

Hi all,

I was recently talking to Alex Vincent about how tabbing should work in
XBL1. Currently it is something of a mess and not something I think we
should pay attention to. However I do think that we should define how
XBL2 interacts with tabbing.

Section 6.10 sort of mentions what should happen;

"When the user tabs such that the file control should become focused,
the user agent determines if any shadow content should also become
focused, using the tab order specified by the shadow content elements.
It then generates a focus event on the text field inside the file
control. As this event flows across shadow scopes, it is retargeted to
be a focus event on the file control itself."

But first of all this is located in a very illogical place, and second,
the language used isn't very normative.

What I think should happen is this:

When a bound element gets focus, for example by the user tabbing to the
bound element, or using some API such as HTMLInputElement.focus, the
implementation looks though the shadow content of the binding and
focuses the first focusable per the following algorithm:


1. Start with the most derived binding.
2. Use the nodes in the shadow tree of the binding to create a list
    of focusable[a] elements sorted in tabbing order[b]. Make sure
    to consider <inherited> elements as focusable when creating this
    list.
3. Remove all but the first <inherited> elements from the list.
4. If there is an inherited binding with a shadow tree, and there is an
    <inherited> element in the list, create a list of focusable elements
    for that binding according to steps 2-4 and replace the <inherited>
    element with that list.

If the resulting list is non-empty the first element in the list is 
focused along with the bound element. Note that focusing the inner 
element can recursively the same process if that element has bindings 
attached to it.

If the list is empty only focus the bound element.

[a] We should define focusable here such that it matches what users can
tab to today. This means that an element who has visibility:hidden is
not focusable, and an element that has, or has an ancestor that has,
display:none, is not focusable.

[b] The order of this list typically both takes into account any 
explicit tab ordering defined on the elements, such as using the 
tabindex attribute on HTML elements, and the order of the elements in 
the DOM.

Further, when tabbing use the following steps:

1. Create a list of the currently focused elements. The first element in
    the list should be the element in the bound document that currently
    has focus. The second element in the list is the element in the most
    derived binding with a shadow tree that has focus, and so on.
2. If the list is only one item long use the normal tab mechanism for
    the UA and stop.
3. Select the last element in the list and remove it from the list.
4. For the new last element in the list, create a sorted list of
    focusable elements using the above steps.
5. Find the selected element in that list. If the selected element is
    not last in the list, focus the element after it and stop.
6. Restart at step 2 using the new list of focused elements.

The result of this is that when tabbing and the focused element has 
bindings containing multiple focusable elements, those elements are 
first cycled through before focus moves to the next focusable element in 
the bound document. Another result is that tab indexes are local to each 
binding.

What do other people think?

Best Regards
/ Jonas Sicking
Received on Wednesday, 11 April 2007 03:29:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:22 GMT