- From: Ryosuke Niwa <notifications@github.com>
- Date: Tue, 31 May 2016 20:39:34 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc:
- Message-ID: <w3c/webcomponents/issues/78/222884679@github.com>
> [B]eing able to easily walk shadows is a more generally common use case, like the testing issue in the original thread, hence why it makes sense to favor the more generic solution. The whole point of shadow DOM API is to provide encapsulation. If your app needs to constantly break that encapsulation, then it's probably better not to use shadow DOM API in the first place. In terms of testing, I don't think reaching into shadow trees of a component while testing a web page that uses a given component is a common scenario. You'd typically unit-test each component separately, and the integration test would be testing the page using public API of each component. In fact, I'd argue it's an anti-pattern. For example, if a library author published a component and various websites that use that component started poking into its shadow tree in websites' tests then the library author may no longer be able to change its shadow tree structure at his/her will because those changes may break those websites. --- 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-222884679
Received on Wednesday, 1 June 2016 03:40:01 UTC