- From: npm1 <notifications@github.com>
- Date: Fri, 17 May 2019 13:29:53 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/816@github.com>
We're incubating the [ElementTiming](https://github.com/WICG/element-timing) API which exposes rendering timings of elements of a website (namely, image and text content). I filed internally https://github.com/WICG/element-timing/issues/3 to attempt to clarify what the interaction with shadow elements should be (in particular regarding what we can expose from the shadow tree). I realize that an issue there will not be noticed by relevant folks so I figure I can get more attention by filing an issue here. I understand that there is a desire to have some encapsulation principles. Where are those principles stated? I'd be interested to understand the motivations of them. In this particular case, I'm interested in understanding if/why it would be desirable to hide important performance information from developers when they use shadow trees. I stated some options on how to handle in the other issue, restating here: * Do no special handling: expose entries, with all the attributes set. * Expose PerformanceElementTiming entries but with some attributes such as `element` set to null. * Expose PerformanceElementTiming entries, but setting the `element` attribute value to the shadow host / shadow root. * Do not expose entries at all. * Make it opt-in so that a developer must set a bit in order to get entries from shadow DOM. CC people on the other issue @hayatoito @annevk -- 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
Received on Friday, 17 May 2019 20:30:16 UTC