- From: Matthew Ryan <notifications@github.com>
- Date: Sun, 14 May 2017 16:37:26 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/640/301347748@github.com>
> But it was discussed, for several years. And a lot of implementation details have been considered, there have always been opposition against /closed/ mode and their arguments were heard, but the decision have to be made and have been made. The argument is the other way around: we have the experience, it works, it works exactly as it should and it's pretty much always stressed to use encapsulation This *still* doesn't mean that the right decision has been made, either in this spec. or by other language implementers. In general, experience with a bad decision is still experience with a bad decision. Unfortunately I'm not at all persuaded that this isn't one. > Of course the decision on /open///closed /should not be on the whim, even usage of shadow dom of any kind should not be, it should not be used just because we have it. I only meant it shouldn't be used on a whim, only when it is useful and unavoidable. > This is not about changing, this is about getting the component and knowing immediately, it is about knowing, that it's pretty much always save to upgrade, knowing, that public is safe to mess around with, knowing that you can rely on that. I know it's not about changing: I was hoping for an example of a tangible benefit, and thought that might be a good way to demonstrate one. Still, if you aren't using code that touches the shadow DOM of a component, I can't see why you wouldn't be safe to upgrade it regardless. --------------------- If the closed shadow DOM is supposed to give the *document author* these assurances, why is it that the *component developer* is the one getting the say over open vs. closed? The document author is at the receiving end of the safety vs. power trade-off, so surely they should have control over the decision. -- 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/640#issuecomment-301347748
Received on Sunday, 14 May 2017 23:37:58 UTC