[Bug 28353] New: [Shadow]: Use a parent/child relationship in the composed tree for some elements, i.e. /

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28353 Bug ID: 28353 Summary: [Shadow]: Use a parent/child relationship in the composed tree for some elements, i.e. / Product: WebAppsWG Version: unspecified Hardware: PC

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

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

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

On Thu, Mar 26, 2015 at 1:38 PM, Ryosuke Niwa 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 “doc

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

> On Mar 26, 2015, at 1:23 PM, Travis Leithead > 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

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(), > ins

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 To: public-webapps As previously mentioned on [p-w], the test result

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 cur

Re: [websockets] Test results available

On 3/26/15 1:02 PM, Boris Zbarsky wrote: On 3/26/15 10:51 AM, Arthur Barstow wrote: * All results * <2 passes Overall these results are pretty good: 97% of the 495 tests ha

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(), > ins

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

> On Mar 26, 2015, at 10:53 AM, Travis Leithead > 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 wa

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 shadow

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”

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

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

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 We

[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

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-connec

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.

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: [websockets] Test results available

On 3/26/15 10:51 AM, Arthur Barstow wrote: * All results * <2 passes Overall these results are pretty good: 97% of the 495 tests have two or more passes. Arthur, It looks l

Re: [Shadow] URL-based shadows?

On Fri, Mar 20, 2015 at 10:23 PM, Travis Leithead 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

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 * <2 passes

[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 * <2 passes