- From: <bugzilla@jessica.w3.org>
- Date: Mon, 05 May 2014 22:08:02 +0000
- To: public-webapps-bugzilla@w3.org
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