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

> On May 7, 2015, at 7:20 PM, Hayato Ito 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 both are point

Re: Directory Upload Proposal

On Tue, May 5, 2015 at 10:50 AM, Ali Alabbas 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" attribut

RE: Custom Elements: is=""

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 complete

RE: Custom Elements: is=""

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 [mailto

Re: Custom Elements: is=""

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=""

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

Re: Custom Elements: is=""

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: Me You -Justin On Fri, May 8, 2015 at 12:56 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > The 'is' attribute is only a declarative

RE: Custom Elements: is=""

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

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

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, L

Re: Custom Elements: insert/remove callbacks

On Thu, May 7, 2015 at 10:56 PM, Elliott Sprehn wrote: > > On Thu, May 7, 2015 at 10:44 PM, Anne van Kesteren > wrote: > >> On Fri, May 8, 2015 at 7:42 AM, Elliott Sprehn >> wrote: >> > That actually seems pretty similar to what we have, ours is in the form >> of: >> > >> > Node#insertedInto(No

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

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 to

Re: Stability of Widget DigSig

On Friday, May 8, 2015, 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/

Re: Stability of Widget DigSig

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] On 5/8/15 7:14 AM, Arthur Barstow wrote: [ + Marcos and Freder

Re: Stability of Widget DigSig

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: https

Re: Custom Elements: insert/remove callbacks

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

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: https://developer.mozilla.org/en-US/Add-ons/SDK/H

Re: Stability of Widget DigSig

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, F

Re: Stability of Widget DigSig

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 wrote: > > [ + Marcos and Frederick ] > > Hi Andrew, > >

Re: Stability of Widget DigSig

On Friday, May 8, 2015, Arthur Barstow 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 spec's namesp

[clipboard] queryCommandEnabled() and before* events

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* event

Re: Stability of Widget DigSig

[ + 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: [[

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

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 28552] [Shadow]: Shadow DOM v1

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 28558] [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 Hayato Ito changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 28564] [Shadow]: Event model

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