This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Per spec createShadowRoot() is always supported, but in Blink it will throw an exception for HTMLCanvasElement, HTMLFieldSetElement, HTMLImageElement, HTMLKeygenElement, HTMLMediaElement, HTMLMeterElement, HTMLProgressElement, HTMLSelectElement, HTMLTextAreaElement, HTMLFrameElement and HTMLIFrameElement. Make this part of the spec so that the circumstances in which createShadowRoot() works is documented and consistent between implementations?
Or rather fix the implementation? Why would we need to have the special cases for those seemingly random elements? Or, should it be defined on which elements createShadowRoot() works. Like limit it to <div> and <span> (and some svg element) if implementations have issues with other elements? I'd prefer not having special cases, so making it work everywhere.
I'm not sure how much work it would be to make it work everywhere, it was tried for <img> but abandoned once: http://trac.webkit.org/changeset/122824 http://trac.webkit.org/changeset/140097 Having it just work everyone would be nice, but if that isn't going to be prioritized it seems preferable to at least document the interoperable subset, if not making it normative. Dimitri and Hayato are in a better position to say what's likely to happen in Blink, I just noticed this and wanted to raise it.
(In reply to Philip Jägenstedt from comment #0) > Per spec createShadowRoot() is always supported, but in Blink it will throw > an exception for HTMLCanvasElement, HTMLFieldSetElement, HTMLImageElement, > HTMLKeygenElement, HTMLMediaElement, HTMLMeterElement, HTMLProgressElement, > HTMLSelectElement, HTMLTextAreaElement, HTMLFrameElement and > HTMLIFrameElement. > > Make this part of the spec so that the circumstances in which > createShadowRoot() works is documented and consistent between > implementations? I always viewed these as our implementation limitations (http://crbug.com/234020), but I am open to the idea that the spec needs to change as well.
Yeah, they clearly are, but is it a lot of work to fix? I don't have a strong opinion really, but the next browser to implement and ship Shadow DOM should at least be made aware of the problem so that they can decide what to do. Maybe they'll even have similar limitations.
This should be considered as implementation issues, basically. We had spent some time on supporting some of these elements in WebKit/Blink, but things didn't went smoothly. The efforts were suspended by other higher-priority tasks. There is no reason for other UAs not to support these elements. Let me close this issue since we don't have to update the spec so that it throws Exceptions for these elements. If you have any idea how to update the specs other than that, please feel free to reopen this.
CC William Chen who seems to have done most of the implementation in Gecko. If Mozilla people are OK with supporting the current situation then I have nothing to add.
Let me reopen this because we are dropping multiple shadow roots.
It seems the easiest would be here to restrict this method (by throwing a "NotSupportedError" for the elements that have a 'binding' property applied to them per HTML's Rendering section. Probably by enumerating the specific list of elements this needs to happen for within the definition of createShadowRoot().
(In reply to Anne from comment #8) > It seems the easiest would be here to restrict this method (by throwing a > "NotSupportedError" for the elements that have a 'binding' property applied > to them per HTML's Rendering section. Probably by enumerating the specific > list of elements this needs to happen for within the definition of > createShadowRoot(). 'binding' property is https://html.spec.whatwg.org/#bindings, right? I'm a bit confused. Why do we need the list of elements in the shadow dom spec if 'binding' is enough to decide such an element which should throw NotSupportedError? Is that a tentative plan until we can upstream it to each element's definition?
The main problem is that HTML's Rendering section is not required (it's a should at best) whereas this needs to be requirement (a must). But we can link to HTML to indicate how the list was formed.
Moved to https://github.com/w3c/webcomponents/issues/102