First off we should simply remove the line "All other HTML elements in the shadow trees must behave as if they were part of the document tree" as it's much too handwavy.

Does it mean that Document.getElementById(x) treats the element as in-document? Does Document.getElementsByTagName(x) treat the element as in-document? Does Node.firstChild treat the element as in-document?

And if the answer to any of those question is "yes", then what's the relative order between nodes in shadow DOM and nodes in the real document? I.e. if a node has shadow DOM with a particular id, and a real child with a particular id, which one does Document.getElementById(x) return?


Instead elements should by default behave normally. I.e. they should behave as they otherwise would if they have a particular document as .ownerDocument, but that they otherwise aren't inserted in the document.

In the cases where we want other behavior, we should enumerate that.

A large part of the shadow DOM spec describes how rendering is altered by Shadow DOM, so that part is covered.

We should further say that <script> elements execute. For inline scripts we need to define with order those script execute relative to <script> elements that are in the real document. I.e. if a out-of-document node is given <script> children as well as a Shadow DOM with <script> nodes, then which order do they execute in once the node is inserted into the document?

I suspect that the spec already describes how <style> elements behave differently when they are in Shadow DOM, though I haven't checked that personally. Again I think order here needs to be defined.

We should probably file a separate bug on form controls like <input> and fight out how they should behave (do they submit? Do they appear in form.controls? Do they affect validation?) I personally don't think that <input> in Shadow DOM should by default behave any differently than other not-in-document <input>s. I.e. they should not submit by default.

The spec seem to attempt to define that <title> elements inside Shadow DOM do affect the document's title. This seems somewhat weird to me. Remember that <title> can already be polyfilled by simply setting document.title. However if we do want <title>s inside Shadow DOM to affect the document title, then this should be explicitly defined. Again, ordering would need to be defined too.

Also, currently the spec calls out HTML elements specifically, but not SVG elements. Is there a reason <svg:title> should be treated differently from <html:title>? Right now it seems like they are.

Oh, and right now it seems like <style> is treated differently from <link rel="stylesheet">. Is that intentional? If so, why?

(In reply to Jonas Sicking from comment #1)
> First off we should simply remove the line "All other HTML elements in the
> shadow trees must behave as if they were part of the document tree" as it's
> much too handwavy.
> 
> Does it mean that Document.getElementById(x) treats the element as
> in-document? Does Document.getElementsByTagName(x) treat the element as
> in-document? Does Node.firstChild treat the element as in-document?

No to all these. Just like with any DocumentFragment, none of these become magically true with ShadowRoot. Maybe the wording isn't super-focused, but it is in the spec:

"Comparatively, a shadow tree can be seen as somewhere between just part of a document and itself being a document fragment. Since it is rendered, a shadow tree aims to retain the traits of a typical tree in a document. At the same time, it is an encapsulation abstraction, so it has to avoid affecting the document tree. Thus, the HTML elements must behave as specified [HTML] in the shadow trees, with a few exceptions."

> Instead elements should by default behave normally. I.e. they should behave
> as they otherwise would if they have a particular document as
> .ownerDocument, but that they otherwise aren't inserted in the document.

This might be a good wording.

> 
> In the cases where we want other behavior, we should enumerate that.
> 
> A large part of the shadow DOM spec describes how rendering is altered by
> Shadow DOM, so that part is covered.
> 
> We should further say that <script> elements execute. For inline scripts we
> need to define with order those script execute relative to <script> elements
> that are in the real document. I.e. if a out-of-document node is given
> <script> children as well as a Shadow DOM with <script> nodes, then which
> order do they execute in once the node is inserted into the document?

Filed bug 25563.

> 
> I suspect that the spec already describes how <style> elements behave
> differently when they are in Shadow DOM, though I haven't checked that
> personally. Again I think order here needs to be defined.

Yup, it's defined here: http://drafts.csswg.org/css-scoping/#cascading

> 
> We should probably file a separate bug on form controls like <input> and
> fight out how they should behave (do they submit? Do they appear in
> form.controls? Do they affect validation?) I personally don't think that
> <input> in Shadow DOM should by default behave any differently than other
> not-in-document <input>s. I.e. they should not submit by default.

Why not? This seems very limiting, considering we still don't have a way for developers to participate in form submission?

> 
> The spec seem to attempt to define that <title> elements inside Shadow DOM
> do affect the document's title. This seems somewhat weird to me. Remember
> that <title> can already be polyfilled by simply setting document.title.
> However if we do want <title>s inside Shadow DOM to affect the document
> title, then this should be explicitly defined. Again, ordering would need to
> be defined too.

This is bug 24870.

(In reply to Jonas Sicking from comment #3)
> Oh, and right now it seems like <style> is treated differently from <link
> rel="stylesheet">. Is that intentional? If so, why?

This is bug 22539.

(In reply to Dimitri Glazkov from comment #4)
> > We should probably file a separate bug on form controls like <input> and
> > fight out how they should behave (do they submit? Do they appear in
> > form.controls? Do they affect validation?) I personally don't think that
> > <input> in Shadow DOM should by default behave any differently than other
> > not-in-document <input>s. I.e. they should not submit by default.
> 
> Why not? This seems very limiting, considering we still don't have a way for
> developers to participate in form submission?

It breaks the standard behavior where you can just interact with elements like normal, independently of if they have Shadow DOM or not.

If <input>s inside Shadow DOM submit, that now means that if you add an element to the DOM, you now have to reach in to that elements Shadow DOM in order to affect what is submitted.

I definitely agree that we should enable hooking in to form submission. However the thread started here seems like a better design:

http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0448.html

We could even add sugar for implementing a .formData() function by traversing a DocumentFragment (or all shadow DOMs) and adding the form fields to the submission.

With that design the outside world would interact with the shadow host as a real form control, rather than having to reach into its shadow DOM.

(In reply to Jonas Sicking from comment #6)
> (In reply to Dimitri Glazkov from comment #4)
> > > We should probably file a separate bug on form controls like <input> and
> > > fight out how they should behave (do they submit? Do they appear in
> > > form.controls? Do they affect validation?) I personally don't think that
> > > <input> in Shadow DOM should by default behave any differently than other
> > > not-in-document <input>s. I.e. they should not submit by default.
> > 
> > Why not? This seems very limiting, considering we still don't have a way for
> > developers to participate in form submission?
> 
> It breaks the standard behavior where you can just interact with elements
> like normal, independently of if they have Shadow DOM or not.
> 
> If <input>s inside Shadow DOM submit, that now means that if you add an
> element to the DOM, you now have to reach in to that elements Shadow DOM in
> order to affect what is submitted.
> 
> I definitely agree that we should enable hooking in to form submission.
> However the thread started here seems like a better design:
> 
> http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0448.html
> 
> We could even add sugar for implementing a .formData() function by
> traversing a DocumentFragment (or all shadow DOMs) and adding the form
> fields to the submission.
> 
> With that design the outside world would interact with the shadow host as a
> real form control, rather than having to reach into its shadow DOM.

Okay. I guess the idea is that we don't make implicit assumptions about what the author might want and instead give them better controls. BTW, this is bug 22443.

I think the way you want to do this is by making sure that when the HTML Standard says that a particular does something, those conditions either apply in for the shadow DOM or are modified so that they do.

So either get Ian to change the HTML Standard, or monkeypatch it for now and then get Ian to change it in due course.

(In reply to Anne from comment #8)
> I think the way you want to do this is by making sure that when the HTML
> Standard says that a particular does something, those conditions either
> apply in for the shadow DOM or are modified so that they do.
> 
> So either get Ian to change the HTML Standard, or monkeypatch it for now and
> then get Ian to change it in due course.

I was just thinking of this last night! I think we should lean on "form owner" and "form-associated elements" concepts in HTML.

The meat is here: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html

Quickly reading this section, it seems fairly clear that inputs in shadow trees shouldn't be part of the form submission of the document, since they are not in the same home tree. WDYT?

I agree.

Though I think we should start looking at the .formData() feature ASAP as curstom form elements is a pretty important use case for custom elements.

Oh. I just realized that http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html does not prevent form submission of forms that are wholly inside of a shadow tree. Does this seem like a problem?

*** This bug has been marked as a duplicate of bug 26365 ***