Re: [webcomponents] Closed flag proposal breaks ability to audit and automate tests of web pages (#354)

@annevk I have read through all the archives that I could find that reference the shadow DOM. Below is my summary of the prior discussion.

tl;dr

1. No use cases that were accepted by the group were ever presented.
1. Three serious problems were raised about closed shadow DOM and these were never addressed
1. The arguments in favor of closed shadow DOM are weak and basically come down to opinion
1. The single attempt at attempting to determine whether closed shadow DOM is a feature developers would want (a survey) surfaced closed shadow DOM as the single LEAST desired feature
1. The only serious discussion was about the default value and not about the need for closed shadow DOM at all and how that overrides the three serious issues raised.

In summary, if this issue does not get addressed, then my organization will lodge a formal complaint during CfC

**Begin of analysis**
Start of the discussion, summarizing current status https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0217.html

In this discussion, it is clear that there are arguments on both sides (you can see these by linking to the referenced threads).

The argument in favor at this point is essentially the following:

User of component embeds it in their page
User pierces ShadowDOM to achieve some goal
Component gets updated and changes the internals
User upgrades to new component which breaks functionality
User complains and goes back to old version (questionable assertion about what an intelligent user would do)
Conclusion: this is bad for the entire Web

A second argument can be summarized as:

Everybody else is doing this, so we must do it too

At this point the argument against the totally opaque encapsulation is that it will prevent certain types of functionality (specifically Google feedback)

Without any further documented discussion, a decision is recorded by Dimitri Glazkov to create a flag allowing closed shadow DOM https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0286.html

Almost immediately, the discussion switches to what the default should be https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0289.html

A third argument is introduced https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0323.html, which can be summarized as “I want it more than closed” and a question asked as to why closed is needed at all. The answer refers back to the post summarized above.

A further argument is introduced which summarizes to “Chrome has something like it that is not exposed, so everyone needs it” https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0681.html

Security as a requirement is explicitly excluded https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0333.html

The concern that closed will make test automation difficult or impossible, is raised  https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0335.html

Here the argument is raised that closed is for “encapsulation” and nothing else. There is no argument or evidence presented to why this encapsulation needs to be opaque. The argument claims that the criticism is because the feature is not well understood but then fails to explain it. There is a vague reference to built-in components and security that is not further substantiated. https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0336.html

Here the claim is made that the Google feedback use case is not useful because it states that all components could simply be implemented as open. This means that Google would never be able use third party components in order to achieve their use case. So the argument is basically a “don’t use our feature” argument  https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0359.html this argument is immediately refuted here https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0361.html and again here https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0364.html

Question is raised as to why shadowRoot is not a sufficient speed bump and the only argument provided here is an assertion that this is not enough https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0363.html no further evidence or use cases are given despite multiple requests

Statement by Ryosuke that “neither proponent of closed or open has convinced the other which is better” https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0368.html but very explicit restrictions on use cases for closed (testing and feedback) had been raised at this point.

Claim, contrary to prior claim, that there was consensus on the flag https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0377.html

Request for use cases for closed https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0367.html this request is never satisfied

A survey was performed to see whether web developers wanted closed shadow DOM, https://www.w3.org/2014/05/20-webapps-minutes.html response was “very low”. In fact it was lowest of all the features polled.

Document created with the “contentious bits” https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0542.html all discussion at this point is purely about the default. There is no further mention of the issues with closed at all (testing and feedback)

About this time an additional serious issue was raised with accessibility and closed shadow DOM https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c11

None of the issues with closed shadow DOM are addressed and no use cases were ever presented and accepted by the group.

Finally, this issue was marked as closed with reference to the prior discussion. As documented above, the prior discussion does not address these concerns and is not sufficient to dismiss them.


---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/354#issuecomment-177275078