[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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[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
 Resolution|--- |FIXED

--- Comment #1 from Hayato Ito hay...@chromium.org ---
Done at
https://github.com/w3c/webcomponents/commit/3477733368b0c91d7f98bdbef457f701fb900c75

-- 
You are receiving this mail because:
You are on the CC list for the bug.



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:


[[
http://www.w3.org/ns/widgets-digsig/

Implementers should be aware that this document is not stable.
]]

Any objections from you or anyone else to remove this statement?

-Thanks, ArtB

On 5/7/15 5:55 AM, Andrew Twigger wrote:


ATSC and CEA are developing standards that include the ability to 
download digital signed applications. Their current specifications 
reference the W3C Recommendation for XML Digital Signature for Widgets 
(18 April 2013).  However, the associated Widgets Digital Signature 
Namespace (http://www.w3.org/ns/widgets-digsig/) contains a statement 
that “Implementers should be aware that this document is not stable.” 
which has raised questions as to the stability and suitability of 
referencing Widget DigSig.  The alternative would be to reference 
XAdES with the C and T forms to allow for the inclusion of timestamp 
and certificate revocation information which are not included in 
Widget DigSig.


I would be pleased to receive any information regarding the stability 
of Widget DigSig and whether referencing XAdES would provide a better 
alternative.


Thank-you,

Andrew Twigger






[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* events and return
true if those are prevented, we risk that queryCommandEnabled() returns
false even when the UI gets enabled and the actions are in fact available.

Proposal: the clipboard-apis spec can write an enabledness check
algorithm which the editing spec
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#querycommandenabled%28%29
can hook into.

The enabledness check will be spec'ed roughly like this:
1) Fire one onbefore event on document
2) When any event handler(s) are done, check if the default action was
prevented/return value was false. If this is the case, return true for
enabledness check
3) Otherwise, fall back to the implementation's default logic.

Criticism welcome.
 -Hallvord


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 the form
 of:
 
  Node#insertedInto(Node insertionPoint)
  Node#removedFrom(Node insertionPoint)
 
  where insertionPoint is the ancestor in the tree where a connection was
  added or removed which may be arbitrarily far up the ancestor chain.
 From
  that you can figure out all the cases Boris is describing.

 Cool. So maybe the DOM specification needs to be updated to have that
 model and we should expose that as low-level hook to web developers.


 We'd consider adding a new MutationObserver type, we'd prefer not to add
 any more tree mutation callbacks. Anything you can do with those you can do
 with an ancestorChanged record type and takeRecords().


We should think hard before adding ancestor information to
MutationObservers; like other DOM-tree-related APIs, they are very much
based around the model of information coming up the tree from below (you
can imagine how odd it would be to add event dispatch that flowed down the
tree towards the leaves).

- Adam


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, L283
- WEBIDL Updated. The getter of the Storage interface and the key of the 
StorageEvent are Nullable;
- The test suite has been update for these changes[2][3] . These changes are 
widely implemented by the browsers.
- These changes are normative and should be accepted in the second edition.

* ED L187
- The supported property names on a Storage object should be in the order that 
the keys were last added to the storage area”(added).
- I wrote a test case[4] for this but the implementation doesn’t seem to follow 
this instruction. It’s more likely to be *in the order of keys that was defined 
by the user-agent*.
- Giving the fact this change is non-normative, we should either ignore it or 
update the instruction to be *in the order of keys that was defined by the 
user-agent*.

* ED L262
- Remove 4.3.1 (LocalStorage) Security.
- The former section claimed that user agents must throw a SecurityError 
whenever any of the members of a Storage object originally returned by the 
localStorage attribute are accessed by scripts whose effective script origin is 
not the same as the origin of the Document of the Window object on which the 
localStorage attribute was accessed. 
- There was discussion[5] that this section wasn’t clear enough, dating back to 
2012. I couldn’t find any related topics in the mailing list about why the 
editor removed this section after the Rec.
- My test case[6] indicates none of Chrome/Firefox/Safari throws the 
SecurityError in that case.
- This is a normative change and should be accepted in the second edition.

Other changes are more editorial and can be kept in the second edition, imo. 
Moreover, the archives of the Issue section need to be updated in the new 
document because the formal archives are no longer available.

A draft second edition of WebStorage[7](diff[8]) is available in GitHub. Please 
feel free to raise issues or PRs there.

FYI, according to the 2014 process document[9], to modify a Rec, we can either 
go through FPWD-CR-PR-REC, or if we can prove wide review for the changes, 
things will be easier, i.e., CR-PR-REC.

Thanks.

—
xiaoqian

[1] https://www.diffchecker.com/npgkwj7d https://www.diffchecker.com/npgkwj7d
[2] https://github.com/w3c/web-platform-tests/pull/1784 
https://github.com/w3c/web-platform-tests/pull/1784
[3] 
https://github.com/w3c/web-platform-tests/blob/master/webstorage/event_constructor.html
 
https://github.com/w3c/web-platform-tests/blob/master/webstorage/event_constructor.html
[4] 
https://github.com/siusin/web-platform-tests/blob/add_key_order_test/webstorage/keys_added_in_order.html
 
https://github.com/siusin/web-platform-tests/blob/add_key_order_test/webstorage/keys_added_in_order.html
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=762409#c17 
https://bugzilla.mozilla.org/show_bug.cgi?id=762409#c17
[6] 
https://github.com/w3c/web-platform-tests/compare/master...siusin:localstorage_throws_securityerror
 
https://github.com/w3c/web-platform-tests/compare/master...siusin:localstorage_throws_securityerror
[7] https://github.com/w3c/webstorage https://github.com/w3c/webstorage
[8] https://www.diffchecker.com/dkbtofsi https://www.diffchecker.com/dkbtofsi
[9] http://www.w3.org/2014/Process-20140801/#rec-modify 
http://www.w3.org/2014/Process-20140801/#rec-modify
 On 2015-4-30, at 8:02pm, Kostiainen, Anssi anssi.kostiai...@intel.com wrote:
 
 Hi,
 
 On 28 Apr 2015, at 15:46, Arthur Barstow art.bars...@gmail.com wrote:
 
 On 4/21/15 5:39 AM, Kostiainen, Anssi wrote:
 Hi,
 
 Is there a plan to publish an errata to sync the Web Storage Rec [1] with 
 the latest? I counted 8 commits cherry picked into the Editor's Draft since 
 Rec [2].
 
 If no errata publication is planned, I'd expect the Rec to clearly indicate 
 its status.
 
 Re the priority of this issue, is this mostly a truth and beauty 
 process-type request or is this issue actually creating a problem(s)? (If 
 the later, I would appreciate it, if you would please provide some 
 additional context.)
 
 It was creating problems. Our QA was confused which spec was the 
 authoritative one, and wrote tests (additional ones, on top of the w-p-t 
 tests) against the Rec spec. These tests failed since Blink is compliant with 
 the latest, not the Rec. More context at: 
 https://crosswalk-project.org/jira/browse/XWALK-3527
 
 The main thing blocking the publication of errata is a commitment from 
 someone to actually do the work. I also think Ian's automatic push of 
 commits from the WHATWG version of Web Storage to [2] was stopped a long 
 time ago so there could be additional changes to be considered, and the 
 totality of changes could include normative changes. Did you check for these 
 later 

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 the 
underlying behaviors that make up native HTML elements, why should we limit 
registerElement to hyphenated custom element names?

In other words, why not simplify by:
1. Allow any localName to be used by registerElement. (This would imply the 
HTML namespace by default; we can later add registerElementNS if needed :)
2.  Drop the 'extends' member from the ElementRegistrationOptions dictionary.

With this simplification, serializing elements wouldn't include any sign that 
they are 'customized' in any way (as is done with 'is' today). I don't see this 
as a problem, since web devs today can already do this, but without the help of 
the parser.

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'.

If we drop support for 'is' in v1, then we can consider later bringing back 
subclassing in v2 without introducing 'extends' in the 
ElementRegistrationOptions or the 'is' attribute.

If we opt to keep the feature, I'd like to see it simplified as described above.

(In general: I'd also like to see a 'constructor' property added automatically 
to the prototype so that you can always get to the native constructor function 
from script even if you don't save the return value of registerElement.)


 On May 6, 2015, at 6:25 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 Open issues are kept track of here:
 
  https://wiki.whatwg.org/wiki/Custom_Elements
 
 I think we reached rough consensus at the Extensible Web Summit that 
 is= does not do much, even for accessibility. Accessibility is 
 something we need to tackle low-level by figuring out how builtin 
 elements work:
 
  https://github.com/domenic/html-as-custom-elements
 
 And we need to tackle it high-level by making it easier to style 
 builtin elements:
 
  http://dev.w3.org/csswg/css-forms/
 
 And if the parser functionality provided by is= is of great value, 
 we should consider parsing elements with a hyphen in them differently.
 Similar to how script and template are allowed pretty much 
 everywhere.
 
 Therefore, I propose that we move subclassing of builtin elements to 
 v2, remove is= from the specification, and potentially open an issue 
 on HTML parser changes.

We (Apple) support this proposal.

- R. Niwa





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 already laid to rest,
 but if subclassing native elements is a good compromise until we get to the
 underlying behaviors that make up native HTML elements, why should we limit
 registerElement to hyphenated custom element names?


This doesn't work, the parser needs to allocate the right C++ object
associated with the tag name. There's no way to do upgrades if we allow you
register any tag name you want. It was also disliked by Hixie because it
encourages using up the namespace so then the spec would need to invent
weirder names to work around ones that were already in wide spread use.



 In other words, why not simplify by:
 1. Allow any localName to be used by registerElement. (This would imply
 the HTML namespace by default; we can later add registerElementNS if needed
 :)
 2.  Drop the 'extends' member from the ElementRegistrationOptions
 dictionary.

 With this simplification, serializing elements wouldn't include any sign
 that they are 'customized' in any way (as is done with 'is' today). I don't
 see this as a problem, since web devs today can already do this, but
 without the help of the parser.

 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'.


I think this should probably throw if you inherit from the wrong thing.

- E


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 
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 already laid to rest,
 but if subclassing native elements is a good compromise until we get to the
 underlying behaviors that make up native HTML elements, why should we limit
 registerElement to hyphenated custom element names?

 In other words, why not simplify by:
 1. Allow any localName to be used by registerElement. (This would imply
 the HTML namespace by default; we can later add registerElementNS if needed
 :)
 2.  Drop the 'extends' member from the ElementRegistrationOptions
 dictionary.

 With this simplification, serializing elements wouldn't include any sign
 that they are 'customized' in any way (as is done with 'is' today). I don't
 see this as a problem, since web devs today can already do this, but
 without the help of the parser.

 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'.

 If we drop support for 'is' in v1, then we can consider later bringing
 back subclassing in v2 without introducing 'extends' in the
 ElementRegistrationOptions or the 'is' attribute.

 If we opt to keep the feature, I'd like to see it simplified as described
 above.

 (In general: I'd also like to see a 'constructor' property added
 automatically to the prototype so that you can always get to the native
 constructor function from script even if you don't save the return value of
 registerElement.)


  On May 6, 2015, at 6:25 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
  Open issues are kept track of here:
 
   https://wiki.whatwg.org/wiki/Custom_Elements
 
  I think we reached rough consensus at the Extensible Web Summit that
  is= does not do much, even for accessibility. Accessibility is
  something we need to tackle low-level by figuring out how builtin
  elements work:
 
   https://github.com/domenic/html-as-custom-elements
 
  And we need to tackle it high-level by making it easier to style
  builtin elements:
 
   http://dev.w3.org/csswg/css-forms/
 
  And if the parser functionality provided by is= is of great value,
  we should consider parsing elements with a hyphen in them differently.
  Similar to how script and template are allowed pretty much
  everywhere.
 
  Therefore, I propose that we move subclassing of builtin elements to
  v2, remove is= from the specification, and potentially open an issue
  on HTML parser changes.

 We (Apple) support this proposal.

 - R. Niwa






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 [mailto:justinfagn...@google.com]
Sent: Friday, May 8, 2015 1:06 PM
To: Travis Leithead
Cc: Ryosuke Niwa; Anne van Kesteren; WebApps WG
Subject: 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:

button is=my-fancy-buttonMe/button
button is=your-fancy-buttonYou/button

-Justin

On Fri, May 8, 2015 at 12:56 PM, Travis Leithead 
travis.leith...@microsoft.commailto: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 already laid to rest, but 
if subclassing native elements is a good compromise until we get to the 
underlying behaviors that make up native HTML elements, why should we limit 
registerElement to hyphenated custom element names?

In other words, why not simplify by:
1. Allow any localName to be used by registerElement. (This would imply the 
HTML namespace by default; we can later add registerElementNS if needed :)
2.  Drop the 'extends' member from the ElementRegistrationOptions dictionary.

With this simplification, serializing elements wouldn't include any sign that 
they are 'customized' in any way (as is done with 'is' today). I don't see this 
as a problem, since web devs today can already do this, but without the help of 
the parser.

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'.

If we drop support for 'is' in v1, then we can consider later bringing back 
subclassing in v2 without introducing 'extends' in the 
ElementRegistrationOptions or the 'is' attribute.

If we opt to keep the feature, I'd like to see it simplified as described above.

(In general: I'd also like to see a 'constructor' property added automatically 
to the prototype so that you can always get to the native constructor function 
from script even if you don't save the return value of registerElement.)


 On May 6, 2015, at 6:25 AM, Anne van Kesteren 
 ann...@annevk.nlmailto:ann...@annevk.nl wrote:

 Open issues are kept track of here:

  https://wiki.whatwg.org/wiki/Custom_Elements

 I think we reached rough consensus at the Extensible Web Summit that
 is= does not do much, even for accessibility. Accessibility is
 something we need to tackle low-level by figuring out how builtin
 elements work:

  https://github.com/domenic/html-as-custom-elements

 And we need to tackle it high-level by making it easier to style
 builtin elements:

  http://dev.w3.org/csswg/css-forms/

 And if the parser functionality provided by is= is of great value,
 we should consider parsing elements with a hyphen in them differently.
 Similar to how script and template are allowed pretty much
 everywhere.

 Therefore, I propose that we move subclassing of builtin elements to
 v2, remove is= from the specification, and potentially open an issue
 on HTML parser changes.

We (Apple) support this proposal.

- R. Niwa





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

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:

[[
http://www.w3.org/ns/widgets-digsig/

Implementers should be aware that this document is not stable.
]]

Any objections from you or anyone else to remove this statement?

-Thanks, ArtB

On 5/7/15 5:55 AM, Andrew Twigger wrote:


ATSC and CEA are developing standards that include the ability to download 
digital signed applications. Their current specifications reference the W3C 
Recommendation for XML Digital Signature for Widgets (18 April 2013).  However, 
the associated Widgets Digital Signature Namespace 
(http://www.w3.org/ns/widgets-digsig/) contains a statement that “Implementers 
should be aware that this document is not stable.” which has raised questions 
as to the stability and suitability of referencing Widget DigSig.  The 
alternative would be to reference XAdES with the C and T forms to allow for the 
inclusion of timestamp and certificate revocation information which are not 
included in Widget DigSig.

I would be pleased to receive any information regarding the stability of Widget 
DigSig and whether referencing XAdES would provide a better alternative.

Thank-you,

Andrew Twigger











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:

https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/widget


FYI, the usage of widget in widgets-digsig is not at all related to 
the use of widget in the MDN resource reference above.


-AB





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 arguments.  I just 
described the conceptual information that one can typically get based on 
what all those arguments are.  It also happens that in Gecko the 
Bind/Unbind functions aren't pure notification; they are also 
responsible for doing things like setting the parent pointer as needed.


But yes, the upshot is that the two cases are pretty similar.  Gecko 
doesn't have on hand the exact node that the insertion/removal happened 
at, but adding that would not be a big deal.


-Boris



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:

https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/widget


FYI, the usage of widget in widgets-digsig is not at all related to
the use of widget in the MDN resource reference above.


Just for my understanding, is the W3C Widget TR generally supported then?

Anders




-AB







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 ]

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:


[[
http://www.w3.org/ns/widgets-digsig/

Implementers should be aware that this document is not stable.
]]

Any objections from you or anyone else to remove this statement?

-Thanks, ArtB

On 5/7/15 5:55 AM, Andrew Twigger wrote:


ATSC and CEA are developing standards that include the ability to 
download digital signed applications. Their current specifications 
reference the W3C Recommendation for XML Digital Signature for 
Widgets (18 April 2013).  However, the associated Widgets Digital 
Signature Namespace (http://www.w3.org/ns/widgets-digsig/) contains a 
statement that “Implementers should be aware that this document is 
not stable.” which has raised questions as to the stability and 
suitability of referencing Widget DigSig.  The alternative would be 
to reference XAdES with the C and T forms to allow for the inclusion 
of timestamp and certificate revocation information which are not 
included in Widget DigSig.


I would be pleased to receive any information regarding the stability 
of Widget DigSig and whether referencing XAdES would provide a better 
alternative.


Thank-you,

Andrew Twigger








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?

 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


 FYI, the usage of widget in widgets-digsig is not at all related to
 the use of widget in the MDN resource reference above.


 Just for my understanding, is the W3C Widget TR generally supported then?


Yes. For example, PhoneGap/Cordova which is used to target every platform.



 Anders



 -AB






[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 to be a rather theoretical discussion:

https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/widget


FYI, the usage of widget in widgets-digsig is not at all related to
the use of widget in the MDN resource reference above.


Just for my understanding, is the W3C Widget TR generally supported then?


See http://dev.w3.org/2006/waf/widgets/imp-report/

-AB





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 attribute, and the current dir
attribute stands for direction and not directory, so I'm not sure
which clash you are worried about?

But I'm definitely fine with directories. I've used that in the
examples below.

 As for the behavior of setting the directories attribute on a file input, 
 we have the following options:

 1) Expose two buttons in a file input (choose files and choose directory) 
 (see Mozilla's proposal [1])
 - To activate the choose directory behavior of invoking the directory 
 picker there would need to be a method on the HTMLInputElement e.g. 
 chooseDirectory()
 - To activate the choose files behavior of invoking the files picker, we 
 continue to use click() on the file input

 2) Expose two buttons in file input for Windows/Linux (choose files and 
 choose directory) and one button for Mac OS X (choose files and 
 directories)
 - Allows users of Mac OS X to use its unified File/Directory picker
 - Allows users of Windows/Linux to specify if they want to pick files or a 
 directory
 - However, there would still need to be a method to activate the choose 
 directory button's behavior of invoking the directory picker (e.g. 
 chooseDirectory() on the HTMLInputElement)
 - This results in two different experiences depending on the OS

 3) Expose only one button; Windows/Linux (choose directory) and Mac OS X 
 (choose files and directories)
 - Allows users of Mac OS X to use its unified File/Directory picker
 - Windows/Linux users are only able to select a directory
 - click() is used to activate these default behaviors (no need for an extra 
 method such as chooseDirectory() on the HTMLInputElement interface)
 - For Windows/Linux, in order to have access to a file picker, app/site 
 developers would need to create another file input without setting the 
 directories attribute
 - Can have something like isFileAndDirectorySupported so that developers can 
 feature detect and decide if they need to have two different file inputs for 
 their app/site (on Windows/Linux) or if they just need one (on Mac OS X) that 
 can allow both files and directories

 4) Expose only one button (choose directory)
 - User must select a directory regardless of OS or browser (this normalizes 
 the user experience and the developer design paradigm)
 - To make users pick files rather than directories, the developer simply does 
 not set the directories attribute which would show the default file input
 - Developers that want to allow users the option to select directory or files 
 need to provide two different inputs regardless of OS or browser

Hi Ali,

I think the only really strong requirement that I have is that I'd
like to enable the platform widget on OSX which allows picking a file
or a directory. This might also be useful in the future on other
platforms if they grow such a widget.

I understand that this will mean extra work on the part of the
developer, especially in the case when the developer render their own
UI. However authors generally tend to prefer to optimize a good UI
experience over saving a few lines of code. This seems especially true
in this case given that the author has chosen to provide their own UI
rather than use the browser-provided one.

So that leaves us with options 2 and 3.

I think both of these are options that I can live with. And for
authors that render their own UI the difference is only one of syntax.
And most likely authors will wrap our API in a library since none of
the APIs here are particularly nice.

However I do think that 3 has some disadvantages for authors that *do*
use the browser provided UI.

The main one being that the UI gets kind of awkward when rendering one
input type=file (multiple) and one input type=file directories.
From a user point of view, it ends up being sort of half-way between a
UI where you select one thing, and a UI where you can add as many
files/directories as you want. Specifically the user can select no
more than 2 things, but require that one and only one is a directory.

So the double-input UI ends up neither being a good UI to allow the
user to select one thing, nor to allow the user to select an
arbitrary number of things.

The other downside with 3 when used with the browser-provided UI is
that the website will still have to use javascript to dynamically
generate one or two inputs. This is needed in order to avoid having
two exactly alike UI widgets on old browsers or browsers which doesn't
have a separate directory picker.

That said, 2 definitely has the disadvantage that it'll force us to
cram two buttons into the small layout size that is used by a input
type=file. But I think this is solvable. One simple solution is to
initially render two 

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 spec's namespace document includes the following
 statement:

 [[
 http://www.w3.org/ns/widgets-digsig/

 Implementers should be aware that this document is not stable.
 ]]

 Any objections from you or anyone else to remove this statement?


None. It's stable.





 -Thanks, ArtB

 On 5/7/15 5:55 AM, Andrew Twigger wrote:


 ATSC and CEA are developing standards that include the ability to
 download digital signed applications. Their current specifications
 reference the W3C Recommendation for XML Digital Signature for Widgets (18
 April 2013).  However, the associated Widgets Digital Signature Namespace (
 http://www.w3.org/ns/widgets-digsig/) contains a statement that
 “Implementers should be aware that this document is not stable.” which has
 raised questions as to the stability and suitability of referencing Widget
 DigSig.  The alternative would be to reference XAdES with the C and T forms
 to allow for the inclusion of timestamp and certificate revocation
 information which are not included in Widget DigSig.

 I would be pleased to receive any information regarding the stability of
 Widget DigSig and whether referencing XAdES would provide a better
 alternative.

 Thank-you,

 Andrew Twigger





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 ]
 
 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:
 
 [[
 http://www.w3.org/ns/widgets-digsig/
 
 Implementers should be aware that this document is not stable.
 ]]
 
 Any objections from you or anyone else to remove this statement?
 
 -Thanks, ArtB
 
 On 5/7/15 5:55 AM, Andrew Twigger wrote:
 
 ATSC and CEA are developing standards that include the ability to download 
 digital signed applications. Their current specifications reference the W3C 
 Recommendation for XML Digital Signature for Widgets (18 April 2013).  
 However, the associated Widgets Digital Signature Namespace 
 (http://www.w3.org/ns/widgets-digsig/) contains a statement that 
 “Implementers should be aware that this document is not stable.” which has 
 raised questions as to the stability and suitability of referencing Widget 
 DigSig.  The alternative would be to reference XAdES with the C and T forms 
 to allow for the inclusion of timestamp and certificate revocation 
 information which are not included in Widget DigSig.
 
 I would be pleased to receive any information regarding the stability of 
 Widget DigSig and whether referencing XAdES would provide a better 
 alternative.
 
 Thank-you,
 
 Andrew Twigger
 
 




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 both 
are pointing out is that event path isn't a style concept so node distribution 
can't be thought of as a style concept.

- R. Niwa




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 be larger.



 Do you think this will be a problem in practice?


Definitely.

Custom element names will hopefully fall into self-organized namespaces,
for instance the Polymer team is putting out element collections, like
iron-* and paper-* and we very well might have both iron-button and
paper-button. There would be no chance for that with native element
extensions without is=.




 *From:* Justin Fagnani [mailto:justinfagn...@google.com]
 *Sent:* Friday, May 8, 2015 1:06 PM
 *To:* Travis Leithead
 *Cc:* Ryosuke Niwa; Anne van Kesteren; WebApps WG
 *Subject:* 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:



 button is=my-fancy-buttonMe/button

 button is=your-fancy-buttonYou/button



 -Justin



 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 already laid to rest,
 but if subclassing native elements is a good compromise until we get to the
 underlying behaviors that make up native HTML elements, why should we limit
 registerElement to hyphenated custom element names?

 In other words, why not simplify by:
 1. Allow any localName to be used by registerElement. (This would imply
 the HTML namespace by default; we can later add registerElementNS if needed
 :)
 2.  Drop the 'extends' member from the ElementRegistrationOptions
 dictionary.

 With this simplification, serializing elements wouldn't include any sign
 that they are 'customized' in any way (as is done with 'is' today). I don't
 see this as a problem, since web devs today can already do this, but
 without the help of the parser.

 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'.

 If we drop support for 'is' in v1, then we can consider later bringing
 back subclassing in v2 without introducing 'extends' in the
 ElementRegistrationOptions or the 'is' attribute.

 If we opt to keep the feature, I'd like to see it simplified as described
 above.

 (In general: I'd also like to see a 'constructor' property added
 automatically to the prototype so that you can always get to the native
 constructor function from script even if you don't save the return value of
 registerElement.)



  On May 6, 2015, at 6:25 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
  Open issues are kept track of here:
 
   https://wiki.whatwg.org/wiki/Custom_Elements
 
  I think we reached rough consensus at the Extensible Web Summit that
  is= does not do much, even for accessibility. Accessibility is
  something we need to tackle low-level by figuring out how builtin
  elements work:
 
   https://github.com/domenic/html-as-custom-elements
 
  And we need to tackle it high-level by making it easier to style
  builtin elements:
 
   http://dev.w3.org/csswg/css-forms/
 
  And if the parser functionality provided by is= is of great value,
  we should consider parsing elements with a hyphen in them differently.
  Similar to how script and template are allowed pretty much
  everywhere.
 
  Therefore, I propose that we move subclassing of builtin elements to
  v2, remove is= from the specification, and potentially open an issue
  on HTML parser changes.

 We (Apple) support this proposal.

 - R. Niwa






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 borked when it comes to classes and how it 
just treats { prototype } as an options object. I think there is wide agreement 
to fix that.

The solution that maintains the least delta from the current spec is outlined 
in https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0230.html, 
coupled with the work at https://github.com/domenic/element-constructors (see 
especially the registry). You could imagine other solutions that allow 
author-supplied constructors (instead of just inheriting the default behavior 
from HTMLElement and delegating to this.createdCallback() or 
this[Element.create]()) but those require running such author-supplied 
constructors during parsing and during cloning, which has its own issues.