Disallow attachShadow(...) for some elements.

[hayatoito]

See
9b65780#commitcomment-11603549 for the context.

[hayatoito]

I'm thinking that the white list might be better than the black list for v1, given that, in practical, there are a limited number of HTML Elements for which createShadowRoot() makes sense.

The white list would be:
div, body, p, span and so on.

[hayatoito]

Please ignore my previous comment. Though I'm still wondering what is the best for v1, I'm going to enumerate the elements as the black list, as we planned.

[wh0]

Would the white list's "and so on" include things like input? Would that blacklist include things like input? I'm interested in using shadow roots on those elements.

edit: oops, I didn't ignore that comment.

[hayatoito]

Yes, I'm going to include <input> in the blacklist.

FYI. Blink supported createdShadowRoot() for <input>, however, we found that it would be hard to deliver the meaningful behavior to the users in such a case.

As of now, it doesn't make much sense to add a shadow root to <input> elements, AFAIK.

[mitar]

Hm, doesn't such hard-coded lists prevent innovation? I thought that the whole idea of web components is that developers can come up with new ideas and implement them without having to get browsers to adopt/change anything. With a hard-coded list you are preventing this. One now cannot enable createdShadowRoot on any element they would want/need, or for example, on all DOM elements?

[hayatoito]

I agree, however, it would be better to disable the support for these elements until we have a clear idea how the behavior should be for these elements.

AFAIR, one of the original motivations of this restriction is to achieve the interoperability.

See also #102.

[mitar]

That is interesting, because one of popular Shadow DOM tutorials use createShadowRoot on a now blacklisted element:

var host = document.querySelector('button');
var root = host.createShadowRoot();
root.textContent = 'こんにちは、影の世界!';

[mitar]

And one more tutorial using input. I think there are already existing use cases shown.

[domenic]

@mitar yep. But those only work in Chrome. When trying to create a spec that works for multiple browsers, we realized that it's not possible to specify something interoperable (for now at least). Thus this change.

[annevk]

It's not about use cases, it's about not knowing what it means.

[travisleithead]

I'm not sure I follow what the behavioral problem is with supporting createShadowRoot on the black-listed elements. Care to enumerate? Don't you simply loose interactivity + rendering?

[mitar]

It's not about use cases, it's about not knowing what it means.

What it means in Chrome then? :-)

[annevk]

@travisleithead well for one it depends if user agents use shadow trees to implement those elements. And I think also currently it depends on inherited shadow trees, which we removed for v1. Do you have some kind of working prototype how this would work?

[travisleithead]

No prototype yet, but just thinking about what the user-expectation would be. Obviously native rendering would be hidden, but would event handlers still trigger behavior on the element? e.g., bubbling/capture of click event, would it trigger file-upload dialog? I think the expectations would be not to have those native behaviors get triggered.

[hayatoito]

FYI.

In blink, <input> uses an user-agent shadow tree and it supports createShadowRoot(), however, we found that it would be hard to deliver the meaningful result when the user adds an insertion point, <content> (or <shadow>), in the created author shadow root. As a result, we gave up distributing the contents of a user agent shadow tree into the insertion point.

That means createShadowRoot() works for <input>, but it wouldn't meet the user-expectation, as of now, unfortunately. :(

AFAIR, <img> or <iframe> would be more painful to have a well-defined behavior. We had tried to support these elements, but we decided to suspend the work in blink.

[annevk]

@travisleithead until you have defined that processing model, and patched these existing elements in the specification to be aware of shadow DOM and what it means for their processing model, I think supporting anything here is a non-starter.

[mitar]

Hm, what about then providing a blacklist of elements which cannot support insertion points?

[annevk]

This is what was committed here.

[nazar-pc]

What about extending and then styling input?
It is fine to extend it without Shadow DOM support, but this automatically means that styling also is not possible directly.

[annevk]

Styling of form controls is still a largely unsolved problem. We need someone capable with a sponsor of sorts to sort through that.

[rniwa]

I don't think we should have a fixed list of elements as the normative text as we might be adding more elements in the future. I think it's better for the normative text to refer to the binding property and then add a non-normative text enumerating the currently known list of elements with the binding property.

[annevk]

We should just revive the list once we add a new element like that. Alternatively we say in HTML that these elements set some kind of flag that this algorithm uses, but that seems more involved.

[domenic]

@annevk it turns out HTML kind of does set a flag, but it sets it in a strange way, by in the UA stylesheets section saying that elements have a binding CSS property (like binding: button;): https://html.spec.whatwg.org/#bindings

This is all done in terms of a not-implemented spec, http://www.w3.org/TR/becss/.

This seems pretty weird and maybe something that should be fixed in HTML to go with a more flag-like approach...

[hayatoito]

I'd like to move this issue forward.

As the first step, can we agree on having a white list? It seems the safest approach to me.
The initial white list might be:

• Any custom elements
• div
• span

We can expand this white list anytime if we can agree on adding an element to the list when such a request is coming. If we find that having a white list is hard to maintain, we can switch to a black list in the future.

[treshugart]

A whitelist is a safe approach, but from reading this thread it would seem the only elements that really need blacklisting are those that don't allow html / text content.

I've many times created custom buttons where I'm projecting content into them, even if it's only text-content. I've avoided using is="" in the past because of the contention. The only other option is to create a custom element that renders a button and project the content of the custom element into the button. Even so, there are compound components where extending a single element doesn't make sense like an input + button search component.

What about blacklisting void elements and allowing everything else?

[annevk]

@treshugart that does not work, e.g., <iframe> was already mentioned as something we cannot allow this on.

@hayatoito why can we not include more elements we know are not problematic as I suggested in #110 (comment)? I guess I don't feel particularly strongly though.

Also, we should use safelist/blocklist rather than whitelist/blacklist I think. See whatwg/html#265 for rationale.

[nazar-pc]

I was thinking about another approach. It is a bit tricky to explain, but more flexible.

What if we support Shadow Root creation on all elements, but with blocklist which contains elements that might not change their internal structure. What I mean is that for elements like input or progress we will be able to add Shadow Root and place some styling inside in order to create custom-looking input[is] or progress[is], but eventually it will not affect how they are constructed in terms of current internal pseudo-elements (I mean ::-webkit-progress-bar, ::-webkit-progress-value and others).

This is a bit tricky, but spec already contains similar tricks like self-closing HTML tags which are basically list of those special elements and everything else works by general rules. It would be really sad if styling postponed to v2 of this spec.

[hayatoito]

I've updated the spec, with a warning -"The list is possible to change", with a link to this issue.
ada4804

@annevk , yeah, I've added some elements to the white list.

To be honest, I can not explain the rationale for this list fully yet. Please consider this commit just as the first draft.

[annevk]

@nazar-pc if it doesn't affect how they are constructed, it will not affect rendering either. That is somewhat closely intertwined.

[annevk]

@hayatoito this seems good to me (modulo comments I made on the commit). We should probably just ask for new issues if folks want to expand the safelist.

[nazar-pc]

@annevk, then suggestion is something like:

Shadow Root in following elements list_of_elements_here MUST contain <shadow></shadow> (or whatever is currently in spec) in the root and MAY contain any number of <style>...</style> elements for styling purposes, any other elements are NOT allowed.

I'm really trying to find replacement for /deep/ that is used currently for this purpose.

[hayatoito]

We should probably just ask for new issues if folks want to expand the safelist.

I see. Let me close this issue. Please feel free to file a new issue if folks want to expand the safelist.
I will remove the warning message in the spec if I can feel the spec is stable enough.

[hayatoito]

Also, we should use safelist/blocklist rather than whitelist/blacklist I think. See whatwg/html#265 for rationale.

Ops. I forgot to use safelist/blocklist in the commit message. My bad. Let me use safelist/blocklist from the next.

[domenic]

Given that the list of HTML elements is finite, a safelist vs. a blocklist is equivalent except for future changes to HTML. I would assume any future changes to HTML would coordinate with the shadow DOM spec, especially if we take the approach in whatwg/html#131 (or the safelist equivalent). So I think debating safelist vs. blocklist is not interesting. You should just come up with the list, in either form :).

EDIT: I see I didn't quite read to the bottom, please ignore my last sentence.

[jarek-foksa]

If I understand correctly the specs, I won't be able to attach shadow root to any standard SVG element and if I attach it to a custom element in SVG namespace then it won't be rendered on the screen anyway?

How Web Components are supposed to be useful with SVG given those limitations? You should at least allow attachShadow() on <g> elements or you should make custom elements in SVG namespace renderable.

[rniwa]

As things stand, WebKit's implementation is not going to even define a custom SVG element in v1 (we'll only support direct inheritance from HTMLElement and other custom elements). We're taking baby steps and ensuring interoperable behavior across browsers instead of trying to address all uses cases in v1.

[prushforth]

I have created a customized built-in map element, and I am continuously working to improve it and make it productions ready. It would be a major setback, I think, if the map element was not allowed to have a shadow root.

[cyrilletuzi]

What about the main element ? It's an element similar to header, article... but it's missing in the current spec white list.

[annevk]

@cyrilletuzi could you file a new issue for that please?

[kleinfreund]

Is there by any chance a list with the disallowed elements and the reason for why they cannot hold a shadow tree? I understand that some elements already have browsers populate a shadow tree in them or they aren’t meant to have child content at all (e.g. input).

I’m particularly interested in why the details element is not allowed.

Edit: Just found this comment among the collapsed ones:

summary element also seems to create a user-agent shadow root in Blink and WebKit as well.

[rniwa]

details element has a user-agent shadow root in Blink and WebKit.

[ByteEater-pl]

Why should it matter if UAs implement some elements using shadow DOM internally? It seems that should be an implementation detail not exposed in specs.

[rniwa]

Why should it matter if UAs implement some elements using shadow DOM internally? It seems that should be an implementation detail not exposed in specs.

In theory, yes, in practice no. The fact these elements are implemented using shadow DOM would mean that we'd have to define exactly what happens when an author defined shadow root is attached, and we've never successfully done that. Furthermore, this poses a serious implementation challenge since having multiple shadow root isn't a thing in v1 API and its implementation. Supporting multiple generations of shadow roots in v0 had a huge implementation cost.

If and when a sensible proposal is made for defining what it means for these elements to have a shadow root, we can revisit this decision.

[ByteEater-pl]

The fact these elements are implemented using shadow DOM would mean that we'd have to define exactly what happens when an author defined shadow root is attached

I imagined those UAs would be required to behave the same way as those which chose a different implementation strategy, not involving shadow DOM. Or is it a future compatibility concern whereby the UA's shadow tree in v2 would be somewhat exposed for integration with author's shadow trees? (Then it makes sense what I've recently read in some draft I cannot find, that using shadow DOM for implementing some elements is the default and some slots must be exposed even if an UA doesn't use shadow DOM internally – it must behave as if it did.)

[annevk]

The problem is defining what way they would have to behave. These elements are poorly understood standards-wise to begin with.