Re: Better focus support for Shadow DOM
Hi, Thanks for the feedback from you all. During the discussion on the feedback, I've filed a couple of bugs. Any comments are welcome. [Shadow]: Shadow host with tabindex=-1, all descendent tree should be ignored for tab navigation https://www.w3.org/Bugs/Public/show_bug.cgi?id=27965 Focus on shadow host should slide to its inner focusable node https://www.w3.org/Bugs/Public/show_bug.cgi?id=28054 On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) wrote: > Hi, > > For shadow DOMs which has multiple focusable fields under the host, > the current behavior of tab navigation order gets somewhat weird > when you want to specify tabindex explicitly. > > This is the doc to introduce a new attribute "delegatesFocus" to resolve > the issue. > > https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing > > Any comments are welcome! > -- > Takayoshi Kochi > -- Takayoshi Kochi
[Bug 28054] New: Focus on shadow host should slide to its inner focusable node
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: dglaz...@chromium.org
Reporter: ko...@google.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
When a shadow host which is normally unfocusable (e.g. ), have focusable
elements (e.g. ) 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.
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:
| #shadow
|
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:
| #shadow
| ... Some widget here, no focusable element...
In this case, $("host").focus() or hitting TAB from #input-A, focus should move
to "#host".
This is an existing behavior.
Example3:
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.
Mozilla on Privileged Hosted Apps
It seems that the web indeed is at a cross-road when it comes to applications that are intended to be on par with native: https://groups.google.com/forum/#!topic/mozilla.dev.webapi/pCY77YAg_i4 The Web2Native Bridge is another take on this matter: https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html It has one major advantage over the web solutions and that is that could make whatever API possible to expose on the web (after vetting the application), in addition to not requiring browser vendor involvement when APIs are evolving. Naturally both schemes are usable but something along the lines of the Web2Native Bridge is most urgent because currently Apple Pay-like web payments are infeasible. Anders
Web Components F2F in April 2015
Folks, Following Art's suggestion [1], I propose a Web Components-specific F2F with with the primary goal of reaching consensus on the Shadow DOM contentious bits [2]. When: Friday, April 24, 2015 Where: Google San Francisco or Mountain View (to be confirmed) What: a one-day meeting Tentative agenda: 1) Go over the contentious bits, discuss pros/cons 2) Brainstorm/present ideas on changes to current spec 3) Decide on changes to current spec 4) If we have time left, review custom elements bits [3] I stubbed out the basics in https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting :DG< [1]: https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0407.html [2]: https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits [3]: https://wiki.whatwg.org/wiki/Custom_Elements
[Bug 28051] [imports]: showing from import
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28051 Anne changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM |Component Model Assignee|ann...@annevk.nl|dglaz...@chromium.org --- Comment #1 from Anne --- DOM is not the correct component. Component Model is. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Showing from HTML import
Filed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28051 Ashley On 18 February 2015 at 15:29, Dimitri Glazkov wrote: > Can you file a spec bug? > > > https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=&blocked=20683&short_desc=%5Bimports%5D%3A%20&product=WebAppsWG&import=import%20Model > > :DG< > > On Wed, Feb 18, 2015 at 5:18 AM, Ashley Gullen wrote: > >> I filed crbug.com/458799 for Chrome recently since showing a >> defined in a HTML import did not work as I thought it should. I can't >> compare to any other browsers since right now AFAIK Chrome is the only >> browser shipping both HTML imports and . There seemed to be some >> confusion from the browser developers over what the spec says ought to >> happen. >> >> It sounds like the current spec says that showing a dialog marks the >> "node document" of the dialog as being blocked. I would imagine a >> in a HTML import has the invisible HTML import document as the node >> document of the . Therefore it never appears on-screen (in the main >> document) when you call showModal(), but still throws if you try to open it >> twice. >> >> It can be worked around with JS: the dialog element can be detached from >> its current document and appended to the main document, and then >> showModal() works as expected. >> >> I think the spec may need to be altered. I think it's an obvious use case >> that a web component may want to show a dialog, and naturally that dialog >> will be defined in one of the web component's HTML imports. As it stands >> though the dialog will never appear unless the JS hack is used. I can also >> foresee that a large codebase making use of lots of dialogs ends up with >> loads of dialogs appended to the main document, instead of leaving them in >> the components where they came from. >> >> Not sure how this would be specified though - perhaps the dialog should >> be attached to the main document in showModal(), then re-inserted where it >> came from in close()? Sounds like a bit of a hack in itself... >> >> Ashley >> >> >
Re: Showing from HTML import
Can you file a spec bug? https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=&blocked=20683&short_desc=%5Bimports%5D%3A%20&product=WebAppsWG&import=import%20Model :DG< On Wed, Feb 18, 2015 at 5:18 AM, Ashley Gullen wrote: > I filed crbug.com/458799 for Chrome recently since showing a > defined in a HTML import did not work as I thought it should. I can't > compare to any other browsers since right now AFAIK Chrome is the only > browser shipping both HTML imports and . There seemed to be some > confusion from the browser developers over what the spec says ought to > happen. > > It sounds like the current spec says that showing a dialog marks the "node > document" of the dialog as being blocked. I would imagine a in a > HTML import has the invisible HTML import document as the node document of > the . Therefore it never appears on-screen (in the main document) > when you call showModal(), but still throws if you try to open it twice. > > It can be worked around with JS: the dialog element can be detached from > its current document and appended to the main document, and then > showModal() works as expected. > > I think the spec may need to be altered. I think it's an obvious use case > that a web component may want to show a dialog, and naturally that dialog > will be defined in one of the web component's HTML imports. As it stands > though the dialog will never appear unless the JS hack is used. I can also > foresee that a large codebase making use of lots of dialogs ends up with > loads of dialogs appended to the main document, instead of leaving them in > the components where they came from. > > Not sure how this would be specified though - perhaps the dialog should be > attached to the main document in showModal(), then re-inserted where it > came from in close()? Sounds like a bit of a hack in itself... > > Ashley > >
Showing from HTML import
I filed crbug.com/458799 for Chrome recently since showing a defined in a HTML import did not work as I thought it should. I can't compare to any other browsers since right now AFAIK Chrome is the only browser shipping both HTML imports and . There seemed to be some confusion from the browser developers over what the spec says ought to happen. It sounds like the current spec says that showing a dialog marks the "node document" of the dialog as being blocked. I would imagine a in a HTML import has the invisible HTML import document as the node document of the . Therefore it never appears on-screen (in the main document) when you call showModal(), but still throws if you try to open it twice. It can be worked around with JS: the dialog element can be detached from its current document and appended to the main document, and then showModal() works as expected. I think the spec may need to be altered. I think it's an obvious use case that a web component may want to show a dialog, and naturally that dialog will be defined in one of the web component's HTML imports. As it stands though the dialog will never appear unless the JS hack is used. I can also foresee that a large codebase making use of lots of dialogs ends up with loads of dialogs appended to the main document, instead of leaving them in the components where they came from. Not sure how this would be specified though - perhaps the dialog should be attached to the main document in showModal(), then re-inserted where it came from in close()? Sounds like a bit of a hack in itself... Ashley
Re: [WebCrypto.Next] Any ideas on how to proceed?
On 2015-02-18 08:59, David Leon Gil wrote: W.r.t. WebCrypto-Next: It would be wonderful to see a few useful algorithms added to the spec: - a modern VOF (e.g., SHAKE256) - a fast hash function (e.g., BLAKE2b) - a sequential-hard KDF (e.g., scrypt) - some non-NSA curves as well as a slightly higher-level interface that makes it less complicated to do things like (cryptographically sound) ECDH without shooting yourself in the foot repeatedly. (I tried with the current API, and I have fewer toes.) There are some other things that would be great to see standardized in this area, but WebCrypto may not be the appropriate WG. This belongs to a WebCrypto "maintenance" task which is an entirely different topic than the stuff referred to in my posting. Anders On Tue, Feb 17, 2015 at 10:30 PM, Anders Rundgren wrote: As you probably noted, all proposals related to http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/ were shot down. Are we waiting on something, and if so is the case, exactly what? Is the idea of building on an already semi-established solution like Chrome Native Messaging unacceptable? Or should this disparate community rather standardize on U2F? Another solution (IMO "workaround") is using local services supplying "Security Services" through Redirects, XHR or WebSockets. Since the (in)famous plugins were simply removed without any thoughts of the implications, it seems that the browser vendors currently "own" this question. Anders
Re: [WebCrypto.Next] Any ideas on how to proceed?
W.r.t. WebCrypto-Next: It would be wonderful to see a few useful algorithms added to the spec: - a modern VOF (e.g., SHAKE256) - a fast hash function (e.g., BLAKE2b) - a sequential-hard KDF (e.g., scrypt) - some non-NSA curves as well as a slightly higher-level interface that makes it less complicated to do things like (cryptographically sound) ECDH without shooting yourself in the foot repeatedly. (I tried with the current API, and I have fewer toes.) There are some other things that would be great to see standardized in this area, but WebCrypto may not be the appropriate WG. On Tue, Feb 17, 2015 at 10:30 PM, Anders Rundgren wrote: > As you probably noted, all proposals related to > http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/ > were shot down. > > Are we waiting on something, and if so is the case, exactly what? > > Is the idea of building on an already semi-established solution like Chrome > Native Messaging unacceptable? > > Or should this disparate community rather standardize on U2F? > > Another solution (IMO "workaround") is using local services supplying > "Security Services" through Redirects, XHR or WebSockets. > > Since the (in)famous plugins were simply removed without any thoughts of the > implications, it seems that the browser vendors currently "own" this > question. > > Anders >
