- From: npm1 <notifications@github.com>
- Date: Mon, 10 Jun 2019 10:32:21 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/816/500506492@github.com>
> 2. Add a boolean argument to `attachShadow`'s options to specify whether element timing would be exposed or not > > I objected to (2) since it breaks the encapsulation of shadow roots. Can you explain why it breaks encapsulation? If the flag is passed, the component author has agreed to expose the performance information. > Another alternative I suggested would be making `PerformanceObserver` and other functions on `Performance` take a list of shadow roots as an argument as we're planning to do for selection (see issue #79). As @diervo mentioned this is not a scalable solution for the Element Timing case. > Could someone explain what the problems are with taking the same approach as with form-associated custom elements? I suggested that and since then folks have mentioned alternatives, but not provided rationale for why those alternatives are better. If folks are fine declaring that shadow DOM should never be used without custom elements, then that seems fine to me. However, given opt in from the custom element, can't we expose the information to the PerformanceObservers of the window? That is, both the component author and the component user should be able to look at the information with the opt in from the component author. -- 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-500506492
Received on Monday, 10 June 2019 17:32:43 UTC