Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

2015-03-26 Thread Hayato Ito
getElement* functions have been removed, [1], [2], from the ShadowRoot.

[1]:
https://github.com/w3c/webcomponents/commit/3d5f147812edaf74cc4f07d294836cafdf48534f
[2]:
https://github.com/w3c/webcomponents/commit/6416fdfe7fc87e47aa89aac8ce5430389b9ad653

See also the relevant discussions:
- https://www.w3.org/Bugs/Public/show_bug.cgi?id=23620
- https://www.w3.org/Bugs/Public/show_bug.cgi?id=27569

I think it's coincidence, but I added the following note to the spec
yesterday to make the spec reader-friendly.
-
https://github.com/w3c/webcomponents/commit/b43d98149c4c4a401fe35e115afc548031bdbc6d

It might be also worth mentioning that you can use
ShadowRoot.getElementById in a non-normative way there. Strictly speaking,
we don't have to mention it in the spec because it's implied.


On Fri, Mar 27, 2015 at 5:44 AM Elliott Sprehn espr...@chromium.org wrote:

 On Thu, Mar 26, 2015 at 1:38 PM, Ryosuke Niwa rn...@apple.com wrote:


 On Mar 26, 2015, at 1:23 PM, Travis Leithead 
 travis.leith...@microsoft.com wrote:

  You make a series of excellent points.



 In the sense that you have a new set of nodes to manage holistically,
 then having some sort of “document” container does makes sense for that (a
 ShadowRoot) in order to place all your search/navigation APIs.



 You got me thinking though—getElementById is currently not available on
 ShadowRoot right? Does that API in the host’s document find IDs in the
 shadow? I presume not given the guidelines you mentioned. I wonder what
 other APIs from Document are desired?


 I thought getElementById existed in ShadowRoot at some point but the
 latest Blink code doesn't have it.  It looks like Blink has
 querySelector/querySelectorAll via ParentNode:


 https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/shadow/ShadowRoot.idl

 https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/ParentNode.idl


 The spec changed,
 https://dom.spec.whatwg.org/#interface-nonelementparentnode

 ShadowRoot is a DocumentFragment and DocumentFragment implements
 NonElementParentNode.

 - E



Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

2015-03-26 Thread Dominic Cooney
On Fri, Mar 27, 2015 at 2:53 AM, Travis Leithead 
travis.leith...@microsoft.com wrote:

  Hi folks,



 Today’s ShadowDOM model is designed around only adding shadow roots to
 element in the ‘light side’. I assume this is intentional, but was hoping
 someone could describe why this design was chosen? Or said another way, if
 there was an imperative API to _*remove*_ a shadow DOM, would that
 symmetry be bad?



 In full transparency, I’m thinking about potential solutions for a
 simplified shadow dom,


Could you share some background on how we should gauge simplicity? What you
have sketched here is less expressive than Shadow DOM (for example, it
can't do what the content element does.) That's not necessarily good or
bad, but it depends on what you're aiming for.


 and it occurs to me that it can’t get much simpler than the following:

 ·Elements only [ever] have one “shadow side” which is essentially
 a secondary child node list. Whenever anything’s in this list the Element
 renders that content instead of its “light” children. (Or maybe there’s a
 switch to tell the element which side to render: light or dark?)

 ·Elements expose this “shadow node list” via APIs that are very
 similar to existing node list management, e.g., appendShadowChild(),
 insertShadowBefore(), removeShadowChild(), replaceShadowChild(),
 shadowChildren[], shadowChildNodes[].

 ·No special Event swizzling, no security boundary, no alternate
 script engine, no intermediate shadow root object,  etc. This minimalist
 approach only provides node ‘hiding’ and potentially an alternate rendering
 path.

Along these lines, an ancient debate was whether the boundary of the
component was just inside the host element or just outside it (so,
imagine a 1:1 swap of element for its shadow twin element.) But whether
this is simplified or not is a very complex question.

  ·Another feature could then provide the stronger “component”
 boundary, specifically the javascript global scope isolation. This
 delineation may more closely match the division we are seeing between the
 “React-like” scenarios and more robust component-kitchen-style custom
 element deployments.







Re: [websockets] Test results available

2015-03-26 Thread Boris Zbarsky

On 3/26/15 10:51 AM, Arthur Barstow wrote:

If anyone is willing to help with the failure analysis, that would be
very much appreciated.


Taking a brief look at some of the failures in Firefox, in addition to 
the ones Olli already posted about:


http://www.w3c-test.org/websockets/keeping-connection-open/001.html -- 
the test is wrong.  Passing undefined means the argument is not present 
per Web IDL, so this should not throw.


http://www.w3c-test.org/websockets/cookies/001.html seems racy to me: it 
kicks off an async test and then immediately removes the cookie, so it's 
not obvious to me why it expects that cookie to be present in the 
websocket connection; the cookie may well be removed before the 
connection is set up.


http://www.w3c-test.org/websockets/interfaces/WebSocket/readyState/003.html 
looks wrong to me: the value it should get is in fact undefined, since 
the property got deleted from the prototype.


-Boris



[Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

2015-03-26 Thread Travis Leithead
Hi folks,

Today's ShadowDOM model is designed around only adding shadow roots to element 
in the 'light side'. I assume this is intentional, but was hoping someone could 
describe why this design was chosen? Or said another way, if there was an 
imperative API to _remove_ a shadow DOM, would that symmetry be bad?

In full transparency, I'm thinking about potential solutions for a simplified 
shadow dom, and it occurs to me that it can't get much simpler than the 
following:

*Elements only [ever] have one shadow side which is essentially a 
secondary child node list. Whenever anything's in this list the Element renders 
that content instead of its light children. (Or maybe there's a switch to 
tell the element which side to render: light or dark?)

*Elements expose this shadow node list via APIs that are very similar 
to existing node list management, e.g., appendShadowChild(), 
insertShadowBefore(), removeShadowChild(), replaceShadowChild(), 
shadowChildren[], shadowChildNodes[].

*No special Event swizzling, no security boundary, no alternate script 
engine, no intermediate shadow root object,  etc. This minimalist approach only 
provides node 'hiding' and potentially an alternate rendering path.

*Another feature could then provide the stronger component boundary, 
specifically the javascript global scope isolation. This delineation may more 
closely match the division we are seeing between the React-like scenarios and 
more robust component-kitchen-style custom element deployments.




Re: [websockets] Test results available

2015-03-26 Thread James Graham
On 26/03/15 15:37, Olli Pettay wrote:

 websockets/interfaces.html  the test itself has bugs (uses old
 idlharness.js?).
 
 Also websockets/interfaces/WebSocket/events/013.html is buggy. Seems to
 rely on blink/presto's EventHandler behavior, which is not
 what the specs says should happen.

If you are inclined to fix these you can either do it in GitHub or in
mozilla-inbound, from where the changes will get upstreamed.




Re: [websockets] Test results available

2015-03-26 Thread Boris Zbarsky

On 3/26/15 10:51 AM, Arthur Barstow wrote:

* All results http://w3c.github.io/test-results/websockets/all.html

* 2 passes http://w3c.github.io/test-results/websockets/less-than-2.html

Overall these results are pretty good: 97% of the 495 tests have two or
more passes.


Arthur,

It looks like the tests that are failed with an Error as opposed to a 
Fail are not being counted in the 2 passes list?  For example, 
http://www.w3c-test.org/websockets/Create-Secure-valid-url-array-protocols.htm 
is not in that list even though everyone fails it.


Is that an accident, or a purposeful decision?

-Boris



RE: [Shadow] URL-based shadows?

2015-03-26 Thread Travis Leithead
From: Anne van Kesteren [mailto:ann...@annevk.nl] 

Depending on the changes we make based on
  https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits

this might already be the case. Also, I believe currently the Web
Components polyfill makes some assumptions about all of Web Components
being supported if you support one of them. So you can't e.g. ship
Custom Elements without HTML Imports... So API changes might already
be necessary just to avoid breaking the web.

I'm looking forward to the meet-up! 


RE: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

2015-03-26 Thread Travis Leithead
From: Daniel Freedman [mailto:dfre...@google.com] 
How would you style these shadow children? Would the main document CSS 
styles affect these children?

I don’t know :-)

Let's assume that main document CSS styles wouldn't affect them, as that seems 
to be a fundamental requirement for shadowDOM.

So, then how to style them? Here's a few thoughts--but what do you think?

* Require scoped style elements. This is today's model. I don't like it much 
because of the developer ergonomics--it's not as natural as the way styles are 
applied to documents today with link rel=stylesheet

* provide new APIs to manage stylesheets for the shadow content. Maybe: 
element.importShadowStyleSheet(url), and then a corresponding 
element.shadowStyleSheets[] collection. This seems vaguely reminiscent of an 
imperative @import. Might be better to just add this capability [generally] to 
the styleSheets collection [1] come to think of it...

* other ideas?

[1] http://dev.w3.org/csswg/cssom/#stylesheetlist
 


Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

2015-03-26 Thread Elliott Sprehn
On Thu, Mar 26, 2015 at 11:36 AM, Travis Leithead 
travis.leith...@microsoft.com wrote:

  From: Justin Fagnani [mailto:justinfagn...@google.com]
  Elements expose this “shadow node list” via APIs that are very similar
 to
  existing node list management, e.g., appendShadowChild(),
 insertShadowBefore(),
  removeShadowChild(), replaceShadowChild(), shadowChildren[],
 shadowChildNodes[].
 
 This part seems like a big step back to me. Shadow roots being actual
 nodes means
 that existing code and knowledge work against them.

 existing code and knowledge work against them -- I'm not sure you
 understood correctly.
 Nodes in the shadow child list wouldn't show up in the childNodes list,
 nor in any of the
 node traversal APIs (e.g., not visible to qSA, nextSibling,
 previousSibling, children, childNodes,
 ect.

 Trivially speaking, if you wanted to hide two divs that implement a stack
 panel and have some
 element render it, you'd just do:
 element.appendShadowChild(document.createElement('div'))
 element.appendShadowChild(document.createElement('div'))

 Those divs would not be discoverable by any traditional DOM APIs (they
 would now be on the
 shadow side), and the only way to see/use them would be to use the new
 element.shadowChildren
 collection.

 But perhaps I'm misunderstanding your point.

 The API surface that you'd have to duplicate with shadow*() methods would
 be quite large.

 That's true. Actually, I think the list above is probably about it.


So if I want to query down into those children I need to do
element.shadowFirstChild.querySelectorAll or
shadowFirstChild.getElementById? That requires looking at all siblings in
the shadowChildList, so I suppose you'd want shadowQuerySelector,
shadowGetElementById, etc? You also need to duplicate elementFromPoint
(FromRect, etc.) down to Element/Text or add special shadow* versions since
right now they only exist on Document and ShadowRoot.

I have to admit I have an allergic reaction to having an element like div
id=foo and then doing element.parentNode.querySelector(#foo) != div.

Another fundamental requirement of Shadow DOM is that you never
accidentally fall out or fall into a shadow and must always take an
explicit step to get there. Having shadow node's parentNode be the host
breaks that.

We could make the parentNode be null like ShadowRoot of today, but you're
still stuck adding API duplication or writing code to iterate the
shadowChildren list.

- E


Re: [websockets] Test results available

2015-03-26 Thread Arthur Barstow

On 3/26/15 1:02 PM, Boris Zbarsky wrote:

On 3/26/15 10:51 AM, Arthur Barstow wrote:

* All results http://w3c.github.io/test-results/websockets/all.html

* 2 passes 
http://w3c.github.io/test-results/websockets/less-than-2.html


Overall these results are pretty good: 97% of the 495 tests have two or
more passes.


Arthur,

It looks like the tests that are failed with an Error as opposed to 
a Fail are not being counted in the 2 passes list?  For example, 
http://www.w3c-test.org/websockets/Create-Secure-valid-url-array-protocols.htm 
is not in that list even though everyone fails it.


Is that an accident, or a purposeful decision?


I'm glad you reported this Boris! Indeed the less-than-2 table is 
missing several tests that have 4 Errors + 1 Timeout. I don't know why 
they aren't included. Such tests are also missing from the other 
automatically generated file complete-fails [cf] (which is a proper 
subset of the 2 table).


I'm not sure of the reason(s) to omit such errors from the less-than-2 
table or the complete-fail table. It could be a bug in the tool 
[wptreport] and perhaps there is a switch that would include the missing 
errors. I also vaguely recall a discussion about pervasive errors being 
a relatively strong indicator of a test case bug. Perhaps Robin can help 
here; Robin?


Regardless, we will also need to investigate all of these other failures 
missing from 2.


-Thanks, AB

[cf] http://w3c.github.io/test-results/websockets/complete-fails.html
[wptreport] https://github.com/darobin/wptreport




RE: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28

2015-03-26 Thread Travis Leithead
Microsoft supports publishing this. Thanks to all involved!

-
Subject:CfC: publish Proposed Recommendation of Web Messaging; 
deadline March 28
Date:   Sat, 21 Mar 2015 08:51:45 -0400
From:   Arthur Barstow art.bars...@gmail.com
To: public-webapps public-webapps@w3.org

As previously mentioned on [p-w], the test results for Web Messaging 
[All] indicate significant interoperability with only two tests that 
have less than two passes [2]. The two tests, including a short 
analysis of the failure, are:

1. http://www.w3c-test.org/webmessaging/with-ports/026.html; this test 
failure (which passes on Firefox) can be considered more of a Web IDL 
implementation issue and thus not a significant interop issue.

2. http://www.w3c-test.org/webmessaging/without-ports/025.html; this 
test failure (which passes on IE) is considered an implementation bug 
(MessageChannel and MessagePort are supposed to be exposed to Worker) 
that is expected to be fixed.

Cindy created a Draft PR [PR] that includes Hixie's updates since the 
[CR] was published (but not the PortCollection interface [PC] which is 
not broadly implemented). Overall, we consider the changes since the CR 
as non-substantive bug fixes and clarifications that align the spec with 
current implementations, and that the test suite tests the updated spec. 
See [Diff] for all of changes between the CR and the draft PR and note 
the draft PR's status section includes a short summary of the changes.

As such, this is a Call for Consensus to publish a Proposed 
Recommendation of Web Messaging using the [PR] as the basis. Agreement 
with this CfC means you consider the test results shows interoperability 
and the changes since CR are not substantive.

If you have any comments or concerns about this CfC, please reply to 
this e-mail by March 28 at the latest. Positive response is preferred 
and encouraged, and silence will be considered as agreement with the 
proposal. If there are no non-resolvable objections to this proposal, 
the motion will carry and we will request the PR be published.

-Thanks, ArtB

[p-w] 
https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0627.html
[All] http://w3c.github.io/test-results/webmessaging/all.html
[2] http://w3c.github.io/test-results/webmessaging/less-than-2.html
[PR] http://www.w3.org/TR/2015/PR-webmessaging-20150407/
[CR] http://www.w3.org/TR/2012/CR-webmessaging-20120501/
[PC] http://dev.w3.org/html5/postmsg/#broadcasting-to-many-ports
[Diff] https://www.diffchecker.com/qswiibb5







Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

2015-03-26 Thread Justin Fagnani
On Thu, Mar 26, 2015 at 11:36 AM, Travis Leithead 
travis.leith...@microsoft.com wrote:

  From: Justin Fagnani [mailto:justinfagn...@google.com]
  Elements expose this “shadow node list” via APIs that are very similar
 to
  existing node list management, e.g., appendShadowChild(),
 insertShadowBefore(),
  removeShadowChild(), replaceShadowChild(), shadowChildren[],
 shadowChildNodes[].
 
 This part seems like a big step back to me. Shadow roots being actual
 nodes means
 that existing code and knowledge work against them.

 existing code and knowledge work against them -- I'm not sure you
 understood correctly.


No, I think I understood :)

ShadorRoot extends DocumentFragment, and thus Node and has all the API yo
would expect like querySelector(), qsA(), childNodes(), textContent,
appendChild(), cloneNode(), insertBefore(), etc... You can pass a
ShadowRoot to any API expecting a node. For instance, deep traversal though
shadow trees only requires updating normal traversal to crawl into shadows,
it doesn't require teaching it a multitude of shadow*() methods.


 Nodes in the shadow child list wouldn't show up in the childNodes list,
 nor in any of the
 node traversal APIs (e.g., not visible to qSA, nextSibling,
 previousSibling, children, childNodes,
 ect.

 Trivially speaking, if you wanted to hide two divs that implement a stack
 panel and have some
 element render it, you'd just do:
 element.appendShadowChild(document.createElement('div'))
 element.appendShadowChild(document.createElement('div'))

 Those divs would not be discoverable by any traditional DOM APIs (they
 would now be on the
 shadow side), and the only way to see/use them would be to use the new
 element.shadowChildren
 collection.


As in the current API where the only way to see shadow children is by
accessing a shadow root. Your examples become:
element.shadowRoot.appendChild(document.createElement('div'))
element.shadowRoot.appendChild(document.createElement('div'))

Or things like: function writeDivSoup(container){...}, which will work as
writeDivSoup(element.shadowRoot)


 But perhaps I'm misunderstanding your point.

 The API surface that you'd have to duplicate with shadow*() methods would
 be quite large.

 That's true. Actually, I think the list above is probably about it.


querySelector(), find() and friends are important. Plus, speaking of find()
what about additions to Node and DocumentFragment in the future? Do you
keep just adding things like queryShadowSelector() and shadowFind()?


Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

2015-03-26 Thread Ryosuke Niwa

 On Mar 26, 2015, at 10:53 AM, Travis Leithead travis.leith...@microsoft.com 
 wrote:
 Today’s ShadowDOM model is designed around only adding shadow roots to 
 element in the ‘light side’. I assume this is intentional, but was hoping 
 someone could describe why this design was chosen? Or said another way, if 
 there was an imperative API to _remove_ a shadow DOM, would that symmetry be 
 bad?
  
 In full transparency, I’m thinking about potential solutions for a simplified 
 shadow dom, and it occurs to me that it can’t get much simpler than the 
 following:
 ·Elements only [ever] have one “shadow side” which is essentially a 
 secondary child node list. Whenever anything’s in this list the Element 
 renders that content instead of its “light” children. (Or maybe there’s a 
 switch to tell the element which side to render: light or dark?)
 ·Elements expose this “shadow node list” via APIs that are very 
 similar to existing node list management, e.g., appendShadowChild(), 
 insertShadowBefore(), removeShadowChild(), replaceShadowChild(), 
 shadowChildren[], shadowChildNodes[].
 ·No special Event swizzling, no security boundary, no alternate 
 script engine, no intermediate shadow root object,  etc. This minimalist 
 approach only provides node ‘hiding’ and potentially an alternate rendering 
 path.
 ·Another feature could then provide the stronger “component” 
 boundary, specifically the javascript global scope isolation. This 
 delineation may more closely match the division we are seeing between the 
 “React-like” scenarios and more robust component-kitchen-style custom element 
 deployments.

Am I right in understanding that those shadow child node can have direct 
children?  If that were the case, then this model is functionally equivalent to 
a model with shadow root.  Those shadow children we add in this model is 
essentially new shadow root because we can have a tree of nodes in shadow 
under them.

- R. Niwa



Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

2015-03-26 Thread Daniel Freedman
How would you style these shadow children? Would the main document CSS
styles affect these children?

On Thu, Mar 26, 2015 at 11:36 AM, Travis Leithead 
travis.leith...@microsoft.com wrote:

  From: Justin Fagnani [mailto:justinfagn...@google.com]
  Elements expose this “shadow node list” via APIs that are very similar
 to
  existing node list management, e.g., appendShadowChild(),
 insertShadowBefore(),
  removeShadowChild(), replaceShadowChild(), shadowChildren[],
 shadowChildNodes[].
 
 This part seems like a big step back to me. Shadow roots being actual
 nodes means
 that existing code and knowledge work against them.

 existing code and knowledge work against them -- I'm not sure you
 understood correctly.
 Nodes in the shadow child list wouldn't show up in the childNodes list,
 nor in any of the
 node traversal APIs (e.g., not visible to qSA, nextSibling,
 previousSibling, children, childNodes,
 ect.

 Trivially speaking, if you wanted to hide two divs that implement a stack
 panel and have some
 element render it, you'd just do:
 element.appendShadowChild(document.createElement('div'))
 element.appendShadowChild(document.createElement('div'))

 Those divs would not be discoverable by any traditional DOM APIs (they
 would now be on the
 shadow side), and the only way to see/use them would be to use the new
 element.shadowChildren
 collection.

 But perhaps I'm misunderstanding your point.

 The API surface that you'd have to duplicate with shadow*() methods would
 be quite large.

 That's true. Actually, I think the list above is probably about it.




Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

2015-03-26 Thread Ryosuke Niwa

 On Mar 26, 2015, at 1:23 PM, Travis Leithead travis.leith...@microsoft.com 
 wrote:
 
 You make a series of excellent points.
  
 In the sense that you have a new set of nodes to manage holistically, then 
 having some sort of “document” container does makes sense for that (a 
 ShadowRoot) in order to place all your search/navigation APIs.
  
 You got me thinking though—getElementById is currently not available on 
 ShadowRoot right? Does that API in the host’s document find IDs in the 
 shadow? I presume not given the guidelines you mentioned. I wonder what other 
 APIs from Document are desired?

I thought getElementById existed in ShadowRoot at some point but the latest 
Blink code doesn't have it.  It looks like Blink has 
querySelector/querySelectorAll via ParentNode:

https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/shadow/ShadowRoot.idl
 
https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/shadow/ShadowRoot.idl
https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/ParentNode.idl

- R. Niwa



Re: [Shadow] URL-based shadows?

2015-03-26 Thread Anne van Kesteren
On Fri, Mar 20, 2015 at 10:23 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
 Are we OK with a non-URL-based creation model (as used today) being fairly 
 different from a URL-based creation model?

I think so.


 [A] breaking change for existing implementations.

Depending on the changes we make based on

  https://github.com/w3c/webcomponents/wiki/Shadow-DOM:-Contentious-Bits

this might already be the case. Also, I believe currently the Web
Components polyfill makes some assumptions about all of Web Components
being supported if you support one of them. So you can't e.g. ship
Custom Elements without HTML Imports... So API changes might already
be necessary just to avoid breaking the web.


-- 
https://annevankesteren.nl/



Re: [websockets] Test results available

2015-03-26 Thread Boris Zbarsky

On 3/26/15 1:02 PM, Boris Zbarsky wrote:

It looks like the tests that are failed with an Error as opposed to a
Fail are not being counted in the 2 passes list?


And the for 
http://www.w3c-test.org/websockets/keeping-connection-open/001.html 
which is all-Timeout.


-Boris



Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

2015-03-26 Thread Justin Fagnani
On Thu, Mar 26, 2015 at 10:53 AM, Travis Leithead 
travis.leith...@microsoft.com wrote:

  Hi folks,



 Today’s ShadowDOM model is designed around only adding shadow roots to
 element in the ‘light side’. I assume this is intentional, but was hoping
 someone could describe why this design was chosen? Or said another way, if
 there was an imperative API to _*remove*_ a shadow DOM, would that
 symmetry be bad?



 In full transparency, I’m thinking about potential solutions for a
 simplified shadow dom, and it occurs to me that it can’t get much simpler
 than the following:

 ·Elements only [ever] have one “shadow side” which is essentially
 a secondary child node list. Whenever anything’s in this list the Element
 renders that content instead of its “light” children. (Or maybe there’s a
 switch to tell the element which side to render: light or dark?)

 ·Elements expose this “shadow node list” via APIs that are very
 similar to existing node list management, e.g., appendShadowChild(),
 insertShadowBefore(), removeShadowChild(), replaceShadowChild(),
 shadowChildren[], shadowChildNodes[].

This part seems like a big step back to me. Shadow roots being actual nodes
means that existing code and knowledge work against them. The API surface
that you'd have to duplicate with shadow*() methods would be quite large.

 ·No special Event swizzling, no security boundary, no alternate
 script engine, no intermediate shadow root object,  etc. This minimalist
 approach only provides node ‘hiding’ and potentially an alternate rendering
 path.

 ·Another feature could then provide the stronger “component”
 boundary, specifically the javascript global scope isolation. This
 delineation may more closely match the division we are seeing between the
 “React-like” scenarios and more robust component-kitchen-style custom
 element deployments.







RE: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

2015-03-26 Thread Travis Leithead
 From: Justin Fagnani [mailto:justinfagn...@google.com] 
 Elements expose this “shadow node list” via APIs that are very similar to 
 existing node list management, e.g., appendShadowChild(), 
 insertShadowBefore(), 
 removeShadowChild(), replaceShadowChild(), shadowChildren[], 
 shadowChildNodes[].

This part seems like a big step back to me. Shadow roots being actual nodes 
means 
that existing code and knowledge work against them. 

existing code and knowledge work against them -- I'm not sure you understood 
correctly. 
Nodes in the shadow child list wouldn't show up in the childNodes list, nor 
in any of the 
node traversal APIs (e.g., not visible to qSA, nextSibling, previousSibling, 
children, childNodes,
ect.

Trivially speaking, if you wanted to hide two divs that implement a stack 
panel and have some
element render it, you'd just do:
element.appendShadowChild(document.createElement('div'))
element.appendShadowChild(document.createElement('div'))

Those divs would not be discoverable by any traditional DOM APIs (they would 
now be on the
shadow side), and the only way to see/use them would be to use the new 
element.shadowChildren 
collection.

But perhaps I'm misunderstanding your point.

The API surface that you'd have to duplicate with shadow*() methods would be 
quite large.

That's true. Actually, I think the list above is probably about it.



RE: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

2015-03-26 Thread Travis Leithead
You make a series of excellent points.

In the sense that you have a new set of nodes to manage holistically, then 
having some sort of “document” container does makes sense for that (a 
ShadowRoot) in order to place all your search/navigation APIs.

You got me thinking though—getElementById is currently not available on 
ShadowRoot right? Does that API in the host’s document find IDs in the shadow? 
I presume not given the guidelines you mentioned. I wonder what other APIs from 
Document are desired?

Back to the original question though… is removal of previously-created shadow 
roots something that makes sense?

From: Elliott Sprehn [mailto:espr...@chromium.org]
Sent: Thursday, March 26, 2015 12:59 PM
To: Travis Leithead
Cc: Justin Fagnani; Dimitri Glazkov (dglaz...@google.com); Arron Eicholz; Anne 
van Kesteren (ann...@annevk.nl); Ryosuke Niwa; WebApps WG
Subject: Re: [Shadow] Q: Removable shadows (and an idea for lightweight 
shadows)?



On Thu, Mar 26, 2015 at 11:36 AM, Travis Leithead 
travis.leith...@microsoft.commailto:travis.leith...@microsoft.com wrote:
 From: Justin Fagnani 
 [mailto:justinfagn...@google.commailto:justinfagn...@google.com]
 Elements expose this “shadow node list” via APIs that are very similar to
 existing node list management, e.g., appendShadowChild(), 
 insertShadowBefore(),
 removeShadowChild(), replaceShadowChild(), shadowChildren[], 
 shadowChildNodes[].

This part seems like a big step back to me. Shadow roots being actual nodes 
means
that existing code and knowledge work against them.

existing code and knowledge work against them -- I'm not sure you understood 
correctly.
Nodes in the shadow child list wouldn't show up in the childNodes list, nor 
in any of the
node traversal APIs (e.g., not visible to qSA, nextSibling, previousSibling, 
children, childNodes,
ect.

Trivially speaking, if you wanted to hide two divs that implement a stack 
panel and have some
element render it, you'd just do:
element.appendShadowChild(document.createElement('div'))
element.appendShadowChild(document.createElement('div'))

Those divs would not be discoverable by any traditional DOM APIs (they would 
now be on the
shadow side), and the only way to see/use them would be to use the new 
element.shadowChildren
collection.

But perhaps I'm misunderstanding your point.

The API surface that you'd have to duplicate with shadow*() methods would be 
quite large.

That's true. Actually, I think the list above is probably about it.

So if I want to query down into those children I need to do 
element.shadowFirstChild.querySelectorAll or shadowFirstChild.getElementById? 
That requires looking at all siblings in the shadowChildList, so I suppose 
you'd want shadowQuerySelector, shadowGetElementById, etc? You also need to 
duplicate elementFromPoint (FromRect, etc.) down to Element/Text or add special 
shadow* versions since right now they only exist on Document and ShadowRoot.

I have to admit I have an allergic reaction to having an element like div 
id=foo and then doing element.parentNode.querySelector(#foo) != div.

Another fundamental requirement of Shadow DOM is that you never accidentally 
fall out or fall into a shadow and must always take an explicit step to get 
there. Having shadow node's parentNode be the host breaks that.

We could make the parentNode be null like ShadowRoot of today, but you're still 
stuck adding API duplication or writing code to iterate the shadowChildren list.

- E


Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

2015-03-26 Thread Elliott Sprehn
On Thu, Mar 26, 2015 at 1:38 PM, Ryosuke Niwa rn...@apple.com wrote:


 On Mar 26, 2015, at 1:23 PM, Travis Leithead 
 travis.leith...@microsoft.com wrote:

  You make a series of excellent points.



 In the sense that you have a new set of nodes to manage holistically, then
 having some sort of “document” container does makes sense for that (a
 ShadowRoot) in order to place all your search/navigation APIs.



 You got me thinking though—getElementById is currently not available on
 ShadowRoot right? Does that API in the host’s document find IDs in the
 shadow? I presume not given the guidelines you mentioned. I wonder what
 other APIs from Document are desired?


 I thought getElementById existed in ShadowRoot at some point but the
 latest Blink code doesn't have it.  It looks like Blink has
 querySelector/querySelectorAll via ParentNode:


 https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/shadow/ShadowRoot.idl

 https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/ParentNode.idl


The spec changed,
https://dom.spec.whatwg.org/#interface-nonelementparentnode

ShadowRoot is a DocumentFragment and DocumentFragment implements
NonElementParentNode.

- E


[websockets] Test results available

2015-03-26 Thread Arthur Barstow
Earlier today I ran the Web Sockets tests on Chrome 41, Chrome/Canary 
43, FF Nightly 39, IE 11, and Opera 12 and pushed the results to the 
test-results repo:


* All results http://w3c.github.io/test-results/websockets/all.html

* 2 passes http://w3c.github.io/test-results/websockets/less-than-2.html

Overall these results are pretty good: 97% of the 495 tests have two or 
more passes.


If anyone is willing to help with the failure analysis, that would be 
very much appreciated.


Odin, Simon - for the purposes of evaluating these results and the 
Candidate Recommendation (exit criteria), should the Opera data be included?


-Thanks, ArtB





Re: [websockets] Test results available

2015-03-26 Thread Olli Pettay

On 03/26/2015 04:51 PM, Arthur Barstow wrote:

Earlier today I ran the Web Sockets tests on Chrome 41, Chrome/Canary 43, FF 
Nightly 39, IE 11, and Opera 12 and pushed the results to the
test-results repo:

* All results http://w3c.github.io/test-results/websockets/all.html

* 2 passes http://w3c.github.io/test-results/websockets/less-than-2.html

Overall these results are pretty good: 97% of the 495 tests have two or more 
passes.

If anyone is willing to help with the failure analysis, that would be very much 
appreciated.

Odin, Simon - for the purposes of evaluating these results and the Candidate 
Recommendation (exit criteria), should the Opera data be included?

-Thanks, ArtB






websockets/interfaces.html  the test itself has bugs (uses old idlharness.js?).

Also websockets/interfaces/WebSocket/events/013.html is buggy. Seems to rely on 
blink/presto's EventHandler behavior, which is not
what the specs says should happen.


-Olli