- From: Pedram Emrouznejad <notifications@github.com>
- Date: Sun, 14 Aug 2016 10:09:53 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/78/239684715@github.com>
> @TakayoshiKochi I think I agree with @rniwa that it's better to stay a bit conservative until the feature is really justified. What's the reason for needing to err on the side of caution here? Like what's the worst that might happen if developer's use this API? Since it's already been trialled, are there [any actual negative examples](https://github.com/w3c/webcomponents/wiki/Shadow-piercing-Combinators-in-the-Wild)? For open shadows, everybody agrees the API is fairly trivial (sugar) so it seems the default should be to keep it. On top of that, all the practical use cases raised here are pro-deep in static profile. 100% of @rniwa's comments are based on a conflation of open and closed shadows. Although I'm 100% agreed with experimenting and building something better for closed shadows, there's apparently no legitimate reason to block this for open shadows. A sharp distinction needs to be made between these two. I think the only thing that will happen by excluding this is that the usability of open shadows and adoption of Web Components will be hampered. The Web Component spec does not currently have a great story for applications. Until all the pieces are there for hard encapsulation, it would be nice to at least have the low-level primitives to allow wider usage of softer encapsulation in v1. Extrapolating reasoning only valid for closed shadows ("bypasses encapsulation") to open shadows would be purely ideological, especially without offering any alternative. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/78#issuecomment-239684715
Received on Sunday, 14 August 2016 17:10:30 UTC