search

mfreed7 / declarative-shadow-dom

Declarative Shadow DOM feature development
192 stars 9 forks source link

Interaction with disabledFeatures #5

Closed annevk closed 3 years ago

annevk commented 4 years ago

It seems this might interact poorly with disabledFeatures unless adjustments are made, see https://html.spec.whatwg.org/multipage/custom-elements.html#element-definition.

mfreed7 commented 4 years ago

Hmm, very interesting point, thanks. It seems like the spec just calls out that upon upgrade, if a shadowroot exists, throw a NotSupportedError and fail the upgrade. That check should continue to work as-is, I think, for declarative shadow roots. What do you think?

I don't see any references to disableShadow for non-upgrade definitions. What is supposed to happen if an element is defined with disableShadow and then the constructor calls attachShadow()? Does that throw? (And can you point me to the spec for that?)

For declarative Shadow DOM placed inside a pre-defined custom element that has disableShadow, it would seem that the declarative content should also get thrown away, possibly with an error fired. Would you agree?

annevk commented 4 years ago

Step 3.2 of https://dom.spec.whatwg.org/#dom-element-attachshadow.

I'm not entirely sure what the right model is, since you might want to safe guard yourself, but also allow "hydration".

mfreed7 commented 3 years ago

I believe this is taken care of in the PR at line 6751, because "attach a shadow root" was pulled out into an algorithm, and re-used for declarative shadow roots. So if an element is pre-defined and has disabledFeatures() returning ['shadow'], no declarative shadow root will be attached. Of course, if the declarative content comes first, then the shadow root will be attached prior to the custom element being defined.