- From: <bugzilla@jessica.w3.org>
- Date: Thu, 19 Feb 2015 01:46:33 +0000
- To: public-webapps@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28054 Bug ID: 28054 Summary: Focus on shadow host should slide to its inner focusable node Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglazkov@chromium.org Reporter: kochi@google.com QA Contact: public-webapps-bugzilla@w3.org CC: mike@w3.org, public-webapps@w3.org When a shadow host which is normally unfocusable (e.g. <div>), have focusable elements (e.g. <input>) in its shadow tree, focus()ing on the host, or when tabindex attribute is set on the host and keyboard navigation reaches the host, the focusing behavior should not stop on the host but slide to its inner shadow tree if any elements in the shadow tree is focusable. Without this default behavior, if a developer wants to emulate e.g. <input> with a shadow DOM, some tricky workarounds are needed or at least exposing HTML "tab focusable flag" on an element[1]. This is not specified in the shadow DOM spec [2] as of now, but this behavior should be more convenient for a component developer. Example1: <input id="input-A"> <div id="host" tabindex=0> | #shadow | <input id="inner"> </div> <input id="input-B"> In this case, $("host").focus() or hitting TAB from #input-A, focus should move to "#inner", rather than "#host". In reverse order, hitting Shift + TAB from #input-B should move to #inner, then #input-A. This is the new behavior that this bug is proposing. Example2: <input id="input-A"> <div id="host" tabindex=0> | #shadow | <div>... Some widget here, no focusable element...</div> </div> <input id="input-B"> In this case, $("host").focus() or hitting TAB from #input-A, focus should move to "#host". This is an existing behavior. Example3: <input id="input-A"> <div id="widget" tabindex=0> <input id="inner"> </div> <input id="input-B"> In this case, $("widget").focus() or hitting TAB from #input-A, focus should move to "#widget". This is also an existing behavior. This came up from conversation with Ian Hickson over the shadow DOM tabindex focus behavior document[1]. [1] Tabindex Focus Navigation Explainer https://docs.google.com/a/chromium.org/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit [2] Shadow DOM http://w3c.github.io/webcomponents/spec/shadow/ -- You are receiving this mail because: You are on the CC list for the bug.
Received on Thursday, 19 February 2015 01:46:36 UTC