[Bug 28564] [Shadow]: Event model

2015-05-08 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28564 Bug 28564 depends on bug 28558, which changed state. Bug 28558 Summary: [Shadow] Rename .path to .deepPath and make it hide closed shadow trees in case it is accessed from open/light DOM https://www.w3.org/Bugs/Public/show_bug.cgi?id=28558

[Bug 28552] [Shadow]: Shadow DOM v1

2015-05-08 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28552 Bug 28552 depends on bug 28558, which changed state. Bug 28558 Summary: [Shadow] Rename .path to .deepPath and make it hide closed shadow trees in case it is accessed from open/light DOM https://www.w3.org/Bugs/Public/show_bug.cgi?id=28558

[Bug 28560] [Shadow] investigate if there should be deepRelatedTargets and touch.deepTargets

2015-05-08 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28560 Bug 28560 depends on bug 28558, which changed state. Bug 28558 Summary: [Shadow] Rename .path to .deepPath and make it hide closed shadow trees in case it is accessed from open/light DOM https://www.w3.org/Bugs/Public/show_bug.cgi?id=28558

[Bug 28558] [Shadow] Rename .path to .deepPath and make it hide closed shadow trees in case it is accessed from open/light DOM

2015-05-08 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28558 Hayato Ito hay...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED

Re: Stability of Widget DigSig

2015-05-08 Thread Arthur Barstow
[ + Marcos and Frederick ] Hi Andrew, The group stopped working on XML Digital Signature for Widgets several years ago and there is no plan to resume work (except to process errata as required). Marcos, Frederick - this spec's namespace document includes the following statement: [[

[clipboard] queryCommandEnabled() and before* events

2015-05-08 Thread Hallvord Reiar Michaelsen Steen
Hi, I've just reported https://github.com/w3c/clipboard-apis/issues/4 - pasting text below: Through onbefore* events, JS can ensure copy/cut/paste UI in the browsers is enabled even if there is no selection or editable context. However, unless we spec queryCommandEnabled() to fire onbefore*

Re: Custom Elements: insert/remove callbacks

2015-05-08 Thread Adam Klein
On Thu, May 7, 2015 at 10:56 PM, Elliott Sprehn espr...@chromium.org wrote: On Thu, May 7, 2015 at 10:44 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, May 8, 2015 at 7:42 AM, Elliott Sprehn espr...@chromium.org wrote: That actually seems pretty similar to what we have, ours is in

A Second Edition of Web Storage? [was: Re: Web Storage Rec errata?]

2015-05-08 Thread Xiaoqian Wu
Thanks for bringing this up, Anssi. The diff between the REC and the latest Editor’s Draft[1] indicated at least two normative changes, so I’d like to propose a second edition of Web Storage. What do you say? Here’s my analysis for the current mutex. All your comments are welcome. * ED L174,

RE: Custom Elements: is=

2015-05-08 Thread Travis Leithead
The 'is' attribute is only a declarative marker; it's the indicator that the native element has a [potential] custom prototype and hierarchy, right? I don't mean to drudge up past history and decisions already laid to rest, but if subclassing native elements is a good compromise until we get to

Re: Custom Elements: is=

2015-05-08 Thread Elliott Sprehn
On Fri, May 8, 2015 at 12:56 PM, Travis Leithead travis.leith...@microsoft.com wrote: The 'is' attribute is only a declarative marker; it's the indicator that the native element has a [potential] custom prototype and hierarchy, right? I don't mean to drudge up past history and decisions

Re: Custom Elements: is=

2015-05-08 Thread Justin Fagnani
If I'm understanding your proposal correctly, wouldn't this limit any document to have a single subclass per native element? How would you express: button is=my-fancy-buttonMe/button button is=your-fancy-buttonYou/button -Justin On Fri, May 8, 2015 at 12:56 PM, Travis Leithead

RE: Custom Elements: is=

2015-05-08 Thread Travis Leithead
Yes, I think you are understanding correctly, and it appears this would be a side-effect ☺. You have the same problem with two implementations of x-button though the pool of custom element names is going to be larger. Do you think this will be a problem in practice? From: Justin Fagnani

Re: Stability of Widget DigSig

2015-05-08 Thread Anders Rundgren
On 2015-05-08 14:32, Frederick Hirsch wrote: no objection, the referenced document is a Recommendation, isn't it? http://www.w3.org/TR/widgets-digsig/ This seems to be a rather theoretical discussion: https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/widget Anders regards,

Re: Stability of Widget DigSig

2015-05-08 Thread Arthur Barstow
On 5/8/15 8:47 AM, Anders Rundgren wrote: On 2015-05-08 14:32, Frederick Hirsch wrote: no objection, the referenced document is a Recommendation, isn't it? http://www.w3.org/TR/widgets-digsig/ This seems to be a rather theoretical discussion:

Re: Custom Elements: insert/remove callbacks

2015-05-08 Thread Boris Zbarsky
On 5/8/15 1:42 AM, Elliott Sprehn wrote: That actually seems pretty similar to what we have, ours is in the form of: Node#insertedInto(Node insertionPoint) Node#removedFrom(Node insertionPoint) To be clear, ours is also in the form of two methods (BindToTree/UnbindFromTree) that take various

Re: Stability of Widget DigSig

2015-05-08 Thread Anders Rundgren
On 2015-05-08 14:50, Arthur Barstow wrote: On 5/8/15 8:47 AM, Anders Rundgren wrote: On 2015-05-08 14:32, Frederick Hirsch wrote: no objection, the referenced document is a Recommendation, isn't it? http://www.w3.org/TR/widgets-digsig/ This seems to be a rather theoretical discussion:

Re: Stability of Widget DigSig

2015-05-08 Thread Arthur Barstow
Andrew - seeing no objections from the group to removing the Implementers ... statement from [NS] document, if that statement is removed, does that address your concern? -Thanks, ArtB [NS] http://www.w3.org/ns/widgets-digsig/ On 5/8/15 7:14 AM, Arthur Barstow wrote: [ + Marcos and Frederick

Re: Stability of Widget DigSig

2015-05-08 Thread Marcos Caceres
On Friday, May 8, 2015, Anders Rundgren anders.rundgren@gmail.com wrote: On 2015-05-08 14:50, Arthur Barstow wrote: On 5/8/15 8:47 AM, Anders Rundgren wrote: On 2015-05-08 14:32, Frederick Hirsch wrote: no objection, the referenced document is a Recommendation, isn't it?

[widgets] implementation data [Was: Re: Stability of Widget DigSig]

2015-05-08 Thread Arthur Barstow
On 5/8/15 8:52 AM, Anders Rundgren wrote: On 2015-05-08 14:50, Arthur Barstow wrote: On 5/8/15 8:47 AM, Anders Rundgren wrote: On 2015-05-08 14:32, Frederick Hirsch wrote: no objection, the referenced document is a Recommendation, isn't it? http://www.w3.org/TR/widgets-digsig/ This seems

Re: Directory Upload Proposal

2015-05-08 Thread Jonas Sicking
On Tue, May 5, 2015 at 10:50 AM, Ali Alabbas a...@microsoft.com wrote: I recommend that we change the dir attribute to directories and keep directory the same as it is now to avoid clashing with the existing dir attribute on the HTMLInputElement. All in favor? There's no current directory

Re: Stability of Widget DigSig

2015-05-08 Thread Marcos Caceres
On Friday, May 8, 2015, Arthur Barstow art.bars...@gmail.com wrote: [ + Marcos and Frederick ] Hi Andrew, The group stopped working on XML Digital Signature for Widgets several years ago and there is no plan to resume work (except to process errata as required). Marcos, Frederick - this

Re: Stability of Widget DigSig

2015-05-08 Thread Frederick Hirsch
no objection, the referenced document is a Recommendation, isn't it? http://www.w3.org/TR/widgets-digsig/ regards, Frederick Frederick Hirsch Chair XML Security WG fjhirsch.com @fjhirsch On May 8, 2015, at 7:14 AM, Arthur Barstow art.bars...@gmail.com wrote: [ + Marcos and Frederick ]

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-05-08 Thread Ryosuke Niwa
On May 7, 2015, at 7:20 PM, Hayato Ito hay...@chromium.org wrote: Ryosuke, could you file a bug for the spec if you find an uncomfortable part in the spec? I want to understand exactly what you are trying to improve. I don't think there is any issue with the spec per se. What Anne and I

Re: Custom Elements: is=

2015-05-08 Thread Justin Fagnani
On Fri, May 8, 2015 at 1:10 PM, Travis Leithead travis.leith...@microsoft.com wrote: Yes, I think you are understanding correctly, and it appears this would be a side-effect J. You have the same problem with two implementations of x-button though the pool of custom element names is going to

RE: Custom Elements: is=

2015-05-08 Thread Domenic Denicola
From: Travis Leithead [mailto:travis.leith...@microsoft.com] It always seemed weird to me that 'prototype' of ElementRegistrationOptions can inherit from anything (including null), and be completely disassociated from the localName provided in 'extends'. Yes, the current spec is completely