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
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
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28558
Hayato Ito hay...@chromium.org changed:
What|Removed |Added
Status|NEW |RESOLVED
[ + 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:
[[
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*
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
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,
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
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
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
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
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,
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:
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
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:
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
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?
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
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
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
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 ]
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
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
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
25 matches
Mail list logo
