- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 10 Apr 2007 20:27:57 -0700
- 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 UTC