Re: [w3c/webcomponents] Shadow tree encapsulation and Element Timing (#816)

I've been thinking about this a lot over the last week and arrived at a point that I'd like some feedback on. Which is, perhaps open/closed shadow DOM is the right switch for this.

First, consider that with a scoped-to-the-shadow-DOM solution plus open shadow DOM, you could always do tree traversal to access the information, it would just be more awkward. In the past, we've decided to leave things like this awkward (e.g. finding the "real" activeElement requires tree traversal), but perhaps for monitoring-type performance APIs, we should allow the information to accumulate without the extra code.

Second, consider how we're seeing shadow DOM (and perhaps web components more generally) in use today. I see two main uses:

1. The original vision, of allowing encapsulated "leaf node" components like those already in the browser. See e.g. [Dimitri's early blog post](https://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/).
2. Usage as the foundation for a framework, where everything---including the app itself---becomes a web component. This is similar to how apps are structured using React, Ember, Angular, etc., but baesd on web components. One example of this in action is https://shop.polymer-project.org/; if you inspect, you can see that from `<shop-app>` on down, it's a bunch of shadow roots.

I claim that (1) benefits from strong encapsulation, even for performance monitoring APIs. If you're uing a neato date picker, and the month dropdown is slow, you (the app author) don't actually want to know about the month dropdown. You just want to know that the date pciker component you're using is slow. This is similar to browser built-ins: app developers don't care what implementation detail of `<textarea>` or `<select>` or whatever is slow; they just want a pointer to the element. So (1) should be using closed shadow DOM, and performance APIs should point at the shadow hosts.

Whereas (2) is more using encapsulation as a convenience, mostly for the style encapsulation. The boundaries are loser, and open shadow DOM is usually used, permitting them to be crossed if it's expedient or necessary for the app developer. In these cases, when you're using shadow DOM as an app-level component framework, it'd be nicer if performance monitoring APIs were able to peek into your app's shadow DOM, preferably without tree traversal + aggregation code.

I'm curious if this makes any sense to others. Although I've always been interested in web components for (1), I think we have to recognize that a lot of authors like using it for (2). Saying that you can't get performance data inside a shadow DOM, even an open shadow DOM, without extensive back and forth, seems like it would drive authors away from either performance APIs or from (2).

-- 
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/816#issuecomment-502203406