Re: computedStyle of cloneNode

On May 3, 2016, at 2:49 PM, Shane Stephens <shans@google.com> wrote:

>> I didn't understand what you meant by :nth-child and the computed
>> style not being correct. :nth-child would never match detached
>> elements which do not have a parent element, the same way document
>> root elements never match :nth-child. Descendants would match as
>> usual.
> 
> Right, that's what I mean. The computed style of the detached element can't be "correct" in general as it might be modified by context when inserted into the document. Given that, what would a computed style on a detached element actually represent, and what use cases would there be to have one?

Wrong. What might or might not happen to a detached node is irrelevant. (If a bear decides to shit in the woods...) If the node is not in the defaultView, it has no computed style information. Or at least that used to be the case. Apparently AVK fixed it up in CSSOM, first moving getComputedStyle from defaultView to window, and then appeasing the rest. https://drafts.csswg.org/cssom/#extensions-to-the-window-interface

"All longhand properties that are supported CSS properties, in lexicographical order, with the value being the resolved value computed for obj using the style rules associated with doc."

Fantastic.

This was probably the result of JavaScript library developers and users complaining about not being able to get style info from detached nodes, probably even filing bugs about it.

The behavior defined by CSSOM seems unreasonable. Should it be removed entirely?

Thank you,