Re: [w3c/webcomponents] Generic programs can't reliably use/manipulate documents via the DOM (#640)

> A generic program (ie. a program that uses the DOM to interact with a document of which it has no prior knowledge) has no reliable interface with which it can interact with and/or monitor documents

What are examples of such a library / framework / program? The only concrete example people have presented so far is Google Feedback (it creates a screenshot of a Google property in JS). But any first-party feature like that could assume that everyone uses the same library or even a convention used on websites, e.g. shadowRoot is always exposed via `_shadowRoot()`, to implement such a feature. So the case in which components are written by the first party isn't the interesting case.

Now, let us consider the case where components are written by third party developers, or different teams within an organization with tens of thousands of developers. In this case, it's not trivial to write a code that walks across shadow trees of components written by different teams or third parties. However, this can also be a benefit. If one of those teams decide to change the internal DOM structures of a component, any JS code that relies on certain DOM structure in that component's shadow DOM would break.

In fact, this is a feature of Web Components API since the intent of Web Components API is to let developers write a custom HTML element that hides its internal structure in favor of providing a public API like any builtin HTML element. If it was so easy to travers and interact with each component's shadow tree, it would defeat the whole point of encapsulation. Instead, any generic code that walks across DOM to do some work should be treating each custom element instance like a regular builtin HTML element.

-- 
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-300046232