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

> What are examples of such a library / framework / program?

My classic examples are:
* browser extensions (specifically [WebExtensions](https://developer.mozilla.org/en-US/Add-ons/WebExtensions))
  - [Vimium](https://chrome.google.com/webstore/detail/vimium/dbepggeogbaibhgnhhndojpepiihcmeb?hl=en) for Chrome is a solid example that closed DOMs hurt
* bookmarklets (ie. bookmarks with `javascript:` URIs)
* in-browser testing frameworks
  - e.g. [Selenium](http://www.seleniumhq.org/) WebDriver
* generic libraries (e.g. for jQuery)
* programs using a spec.-compliant DOM API outside of a browser.
  - [PhantomJS](http://phantomjs.org/) programs will suffer from this if/when it is updated to use a newer WebKit
  - Programs using a node.js library (eg. [jsdom](https://www.npmjs.com/package/jsdom)) which meets the spec. will struggle similarly
* any other accessibility, testing or automation framework that uses the DOM as its interface to the document.

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

I thought this was the point of shadow DOM: to make it harder. If your (generic) program needs to support the increasing number of shadow DOM enabled documents, then it seems pretty manageable to me (unless I've missed anything):
* use `event.path[0]` instead of `event.target`
* recursively walk down shadow DOMs of `activeElement` from `document`, instead of `document.activeElement`
* any DOM traversal just needs to check for and walk into a `shadowRoot` when element an element has one, falling back to normal walking through children
* add a listener to `blur`/`focus`/etc. events on each `shadowRoot` in `event.path` (to capture changes of focus within a shadow DOM)

> any JS code that relies on certain DOM structure in that component's shadow DOM would break.

I agree that this is undesirable. But any JS code doesn't rely on (or even know about) components and their closed shadow DOMs, but need access to them, are broken by their use in the first place. I don't think the extra (circumventable) safety warrants the (often uncircumventable) breakage for this code.

> any generic code that walks across DOM to do some work should be treating each custom element instance like a regular builtin HTML element.

> The same we'd deal with video elements, input elements, etc... which can be modeled as builtin elements with UA shadow roots (WebKit and Blink DO use shadow roots to implement these elements).

We know what to do with regular builtin HTML elements. The only thing we can do with custom elements we don't know about is ignore them. This is a failure of the DOM.

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