[Bug 25562] [Shadow]: Inert HTML elements normative text is not focused enough

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25562

--- Comment #4 from Dimitri Glazkov <dglazkov@chromium.org> ---
(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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 5 May 2014 22:08:03 UTC