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 anders.rundgren@gmail.com 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 anders.rundgren@gmail.com 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
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
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
Re: Showing dialog from HTML import
Can you file a spec bug? https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=blocked=20683short_desc=%5Bimports%5D%3A%20product=WebAppsWGimport=import%20Model :DG On Wed, Feb 18, 2015 at 5:18 AM, Ashley Gullen ash...@scirra.com wrote: I filed crbug.com/458799 for Chrome recently since showing a dialog 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 dialog. 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 dialog in a HTML import has the invisible HTML import document as the node document of the dialog. 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 dialog from HTML import
I filed crbug.com/458799 for Chrome recently since showing a dialog 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 dialog. 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 dialog in a HTML import has the invisible HTML import document as the node document of the dialog. 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 dialog 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 dglaz...@google.com wrote: Can you file a spec bug? https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=blocked=20683short_desc=%5Bimports%5D%3A%20product=WebAppsWGimport=import%20Model :DG On Wed, Feb 18, 2015 at 5:18 AM, Ashley Gullen ash...@scirra.com wrote: I filed crbug.com/458799 for Chrome recently since showing a dialog 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 dialog. 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 dialog in a HTML import has the invisible HTML import document as the node document of the dialog. 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
[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. 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.
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 (河内 隆仁) ko...@google.com 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
