Intent to Ship: ElementInternals.shadowRoot attribute

[Mason Freed]

Contact emails

mason...@chromium.org

Explainer

None

Specification

https://html.spec.whatwg.org/multipage/custom-elements.html#shadow-root-access

API spec

Yes

Summary

A new attribute on ElementInternals, 'shadowRoot', allows custom elements to access their own ShadowRoot, regardless of open/closed status. Additionally, further restrictions are added to the attachInternals() API to ensure that custom elements get the first chance to attach the ElementInternals interface. With this change, the attachInternals() function will throw an exception if called prior to the custom element constructor being run.

Blink component

Blink

Search tags

ElementInternals, shadowRoot

TAG review

This is a very small API change, which has spec landed.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

There is a very small potential compat issue, specifically with the change to attachInternals() not being allowed prior to the custom element constructor. However, use counters indicate almost no usage that would be broken by this change: The overall usage of the attachInternals() API is quite low by itself, around 0.001%: https://chromestatus.com/metrics/feature/timeline/popularity/3435 The to-be-disallowed usage of attachInternals() *prior* to the constructor shows no measurable usage (0%): https://chromestatus.com/metrics/feature/timeline/popularity/3470 Based on these use counters, the risk here is quite low. As for interoperability risk, there is multi-implementer support, and the spec has been approved and landed. So the interop risk should be low also.

Gecko: No signal

WebKit: Positive (https://github.com/w3c/webcomponents/issues/871#issuecomment-692383222) The landed spec was reviewed and assisted by rniwa@ from WebKit.

Web developers: No signals

Ergonomics

This feature will likely be used more often by components taking advantage of the declarative Shadow DOM feature. However, this feature is also useful on its own. There should be no ergonomic risks to adding this API.

Activation

Polyfills could be developed for ElementInternals.shadowRoot, by patching attachShadow. It is unclear whether development of a polyfill will take place. It is likely not worth significant documentation or outreach for this feature.

Security

The only real security concern that was taken into account was the change to attachInternals() to prevent access prior to the custom element constructor running. This change should protect closed shadow roots references from being accessed prior to custom element upgrades.

Debuggability

This is a JS only change/feature, and should be supported by the DevTools console.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Tracking bug

https://crbug.com/1140609

Measurement

No specific counter added.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5721288276443136

This intent message was generated by Chrome Platform Status.

[Alex Russell]

LGTM1

Excited to see this moving forward!

[Manuel Rego Casasnovas]

On 20/10/2020 21:50, Mason Freed wrote:
> Gecko: No signal

Have we asked for a signal in Mozilla standards positions? [*]

> WebKit: Positive
> (https://github.com/w3c/webcomponents/issues/871#issuecomment-692383222)
> The landed spec was reviewed and assisted by rniwa@ from WebKit.

This is not an official signal [*] and the comment ends with "There is
still a pending question of whether we support the declarative Shadow
DOM at conceptual level. I need to get back to you on that.". Is that
question resolved?
Maybe we should ask for an official signal in webkit-dev too.

[*]
https://docs.google.com/document/d/1xkHRXnFS8GDqZi7E0SSbR3a7CZsGScdxPUWBsNgo-oo/edit#heading=h.tgzhprxcmw4u

Thanks,
Rego

[Mason Freed]

On Thu, Oct 22, 2020 at 12:18 PM Alex Russell <sligh...@chromium.org> wrote:

LGTM1

Excited to see this moving forward!

Thanks!

To add a bit more context to this feature, please see this section of the declarative Shadow DOM explainer, which goes into more detail about the motivation and use case for the `ElementInternals.shadowRoot` feature. The overall declarative Shadow DOM feature also had a TAG review, in case that's relevant.

Thanks,

Mason

[TAMURA, Kent]

LGTM2.  The risk looks very low.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDg65viABDrApHa9JugfiGuut7qwuQ8O1s1bGWE-3bPh-g%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[mason...@google.com]

On Wednesday, October 28, 2020 at 7:29:20 PM UTC-7, Kent Tamura wrote:

LGTM2.  The risk looks very low.

Thanks!

On Thursday, October 22, 2020 at 12:53:38 PM UTC-7, Manuel Rego wrote:

Have we asked for a signal in Mozilla standards positions? [*]

I have not, because I thought this change was too small. I can do that, though, if you think it is warranted here.

 

> WebKit: Positive
> (https://github.com/w3c/webcomponents/issues/871#issuecomment-692383222)
> The landed spec was reviewed and assisted by rniwa@ from WebKit.

This is not an official signal [*] and the comment ends with "There is
still a pending question of whether we support the declarative Shadow
DOM at conceptual level. I need to get back to you on that.". Is that
question resolved?
Maybe we should ask for an official signal in webkit-dev too.

Sorry that I missed this comment originally! You are correct that this doesn't constitute an official signal. I've changed the chromestatus entry to list all implementers as "No Signal". That question, whether *declarative shadow dom* is supported by WebKit, is very much still pending. But that should be independent of this ElementInternals.shadowRoot change, I hope.

Thanks,

Mason

 

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDg65viABDrApHa9JugfiGuut7qwuQ8O1s1bGWE-3bPh-g%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b8cc96c2-1e53-4644-91ce-a4ffaffdbddfo%40chromium.org.