- From: Ryosuke Niwa <notifications@github.com>
- Date: Mon, 15 May 2017 14:39:52 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/640/301612850@github.com>
>>> I think the same point as for C++ and Java applies. It's not a 'thing' as far is the user is concerned. Go wild. >> >> Well, then that same argument holds for closed shadow trees. > >Hardly. The DOM is always meaningful, since it represents the user interface/user-facing content in a standardised way. If you give me a DOM (and the relevant styles, admittedly), I can tell you what it represents and do useful things with it. Not so with arbitrary internal private states -- their representation is only meaningful in the context of that specific program. That is patently false. > 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. Web components provide powers to both library/component authors as well as page authors. The primary benefits of closed shadow trees is the "guarantee" or a strong implication that the components are free to change its implementation without having to worry about its details. This is extremely important for a popular component intended to be upgraded and maintained for a long period of time. We have quite a bit of experience dealing with such a problem in UIKit and AppKit here at Apple. We frequently encounter binary compatibility issues whereby which a third party app was relying on the implementation details of UIKit, AppKit, and other system frameworks. They are not supposed to do that (clearly stated in the policy and what not) but in the practice, many apps do because they can. In those cases, we must either can't make a change (e.g. maintaining same view / CA layer hierarchy), or break the app and notify the authors to have them fix them before those changes take effect. With AppStore and once a year release cycle, this is all possible. However, in the world of the Web, where developers would like to move faster and innovate in a rapid pace, and there is no repository of all Web apps which use a given framework or a library, this will become an impossible issue to resolve. Just as another example, Microsoft once upon a time (not sure if they still do) decided to make it possible for any given Windows system to have multiple versions of the same DLL so that each app that links against a particular version of DLL will continue to work to combat the infamous [DLL hell](https://en.wikipedia.org/wiki/DLL_Hell). -- 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-301612850
Received on Monday, 15 May 2017 21:40:28 UTC