Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?
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)?
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
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)?
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
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
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?
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)?
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)?
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: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28
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)?
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)?
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)?
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)?
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?
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
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)?
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)?
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)?
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)?
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
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
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
