Re: computedStyle of cloneNode

I'm not sure it makes sense to match rules on out-of-document elements at
all. Some rules (like nth-child) are conditional and may match once the
element is inserted (plus there's inheritance), so any computed style is
not guaranteed to be correct. I'd rather specify that elements must be in
the tree to match rules, and either provide no style or provide initial
values only for out-of-document elements.

I don't think there are any compatibility issues for open web content as
our behavior here is quite divergent.

Cheers,
    -Shane

On Tue, May 3, 2016 at 7:22 PM Rune Lillesveen <rune@opera.com> wrote:

> On Tue, May 3, 2016 at 6:20 AM, L. David Baron <dbaron@dbaron.org> wrote:
> > On Tuesday 2016-05-03 01:39 +0000, Shane Stephens wrote:
> >> What should
> >> getComputedStyle(foo.cloneNode(true)).opacity;
> >> be?
> >>
> >> Gecko returns the same value as getComputedStyle(foo).opacity, while
> WebKit
> >> and Blink return empty strings. Edge returns "1" regardless of foo's
> >> opacity.
> >>
> >> It seems to me that returning the computed style of the cloned node is
> >> wrong as the clone isn't in the document and therefore doesn't match the
> >> same rules as the original. However, I can't find any specification text
> >> that confirms this.
> >
> > The Gecko code currently falls largely into the same codepath for
> > the content not being in a document, and the content being in a
> > display:none subtree (and thus not having a box/frame/rendering
> > object with current style), which is to run selector matching on the
> > element (and its ancestors) until it finds an element with a
> > box/frame/rendering object.  (Though I suppose the handling of not
> > in a document is more similar to being in a document not currently
> > being presented (e.g., in a display:none iframe), in that in those
> > cases we won't even try looking for a rendering object.)
> >
> > The Gecko behavior there for content not in a document isn't
> > particularly sensible, and I'd be happy to get rid of it if it's not
> > Web-compatible.  (I didn't realize that other implementations didn't
> > do the same.)
> >
> > One question is whether there are Web-compatibility constraints as
> > to what getComputedStyle should do on elements in a display:none
> > iframe (either with the getComputedStyle being from the window of
> > the iframe's parent or the iframe's window).  (Gecko may have other
> > bugs in handling win1.getComputedStyle(element in win2) relative to
> > what the spec says.)
>
> The Gecko behavior looks sane from what I've tested:
>
> https://jsfiddle.net/csujdtsn/
>
> If the root element in [1] can be the root of a detached subtree, it
> means we'll just inherit the initial values for such roots as well.
> Since elements not in the document do not generate boxes, it follows
> that they behave as if they were descendants of display:none elements
> in the document for resolved values [2].
>
> Based on the comment in [3], it seems it's not implemented in
> Blink/WebKit due to lack of machinery, but I don't think it would be
> particularly hard to implement.
>
> [1] https://www.w3.org/TR/css-cascade-3/#inheriting
> [2] https://drafts.csswg.org/cssom/#resolved-values
> [3] http://bit.ly/1SIEqfz
>
> --
> Rune Lillesveen
>