jQuery Forum

I wonder how meaningless would be a get<b>Computed</b>Style for a node not in DOM neither rendered yet ... it's not clear in any case which browser does what.

What does W3C DOM spec says?
--DBJ

On Fri, Oct 23, 2009 at 11:11 AM, DBJDBJ <dbjdbj@gmail.com>

Thanks Scott, my reply was quite sarcastic ... if a node is removed or is not in the document nothing changes, "Computed" words speaks itself ... I mean, if not rendered or present, there's nothing computed for sure.
Regards

Oh, I certainly caught the sarcasm. DBJDBJ's question piqued my
curiosity. I wanted to see if the spec had something to say about how
getComputedStyle worked with elements not in the DOM.
It did.
I couldn't tell if DBJDBJ was intending some sarcasm as well or simply
was too lazy to Google it before posting...
:-)
-- Scott

What a waste of time ...I have posted the code which neither of you
have checked in her browsers ...
@Scot : where is the definition/explantaion of the CSS2 computed
values about the created but un-attached dom element ?
If this would be defined, FF and Chrome would most likely do it in the
same way. So spare us of "It did" , dramatically made prominent on the
separate line...
@Andrea : says " ... I wonder how meaningless would be a
get*Computed*Style for a node not in DOM neither rendered yet ... "
Well for the FF team this was not meaningless, since it is possible to
set/get css value on the non-attached newly created dom element in FF
and then get to it through getComputedStyle()
You just have to follow in the Firebug and Chrome console, what I have
posted initally. Instead of "wondering" ...
-- DBJ

@Andrea : thanks for normal tone, but again somehow you fundamentaly
misunderstood me ? If anything you (probably) followed my code
through ;o)
One of the strengths of jQuery is: It smooths the sharply uneven
surface of cross browser javascript.
If I post something that does not mean I want to do it that way and no
other way.
I simply stumbled upon this issue which , I thought, might be
interesting for the jQ team, because this is yet another "feature"
that works in some browsers and does not work in others.
99% of jQuery are much more concerned to have code that works and that
uses jQuery, than to engage in W3C spec minutiae...
My example/finding uses somewhat esoteric code, but the issue of
CHROME not allowing getComputedStyle() on non-attached new elements,
might break some other part of Sizzle or jQ core, so I thought I
report it...
--DBJ

Sizzle searches over nodes already present in the document.
If I create a div inside whatever function thanks gosh Sizzle won't return that div in a search $("div"), do you follow me?
I know you simply brought here yet another inconsistency in the browsers panorama, but to fix this doubtfully useful operation which logically does not make sense I would go for the other way .... if(!node.parentNode)return null;
To have a computed style for a not in DOM element you need to append it, retrieve the style, remove the node ... no way, since this is gonna be a performances killer and we all take care about performances, don't we?
Regards

P.S. for all ... the reason getComputedStyle does not make sense for a node is that styles are inherited and you'll never know in which position that style would be respected or not.
You append the div in a node with style color:red !important and your div had style color:black ... how can you predict a style if you don't know what kind of dependencies/inheritance that node is gonna have one appended somewhere?
If an engine does it by default it's silly cause lots of properties gonna be replaced, changed, modified, due to Cascade Style Sheet inheritance.
Regards

" ... If I create a div inside whatever function thanks gosh Sizzle
won't return
that div in a search $("div"), do you follow me? ..."
I "follow" this yes, I am just "wondering" if this FF "feature" might
break "something somewhere" in jQ,
because jQ users are allowed to create dom nodes "on fly"and use them
as a container (aka context), with Sizzle, without ever attaching them
to the curent dom tree:
// example 1
function faraway ( jq_ ){ return jq_.find(".a") ; }
//
$div = $("<div style='color:red!important' ><div><div><div class='a b
c'>ABC</div></div></div></div>") ;
// now pass and search inside this "un-attached" element
$a = faraway( $div ) ;
//
$a.css("color")
/* returns : red */
And , yes, for the above test
Returns is an empty string (aka "") in CHROME :
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.3
(KHTML, like Gecko) Chrome/4.0.223.11 Safari/532.3
Return is "red" in IE8 :
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0;
SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729;
Media Center PC 6.0)
And return is "rgb(255, 0, 0)" (aka "red") in FF :
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.3) Gecko/
20090824 Firefox/3.5.3
This example is not that esoteric jQ usage, and thus it is more likely
to happen. And fail in CHROME ...
Now I do not know is this only this Chrome . is it also the same in
Chromium, or in Opera 10, etc ... ?
For now I attach element to the head (temporarily) which seems to
work.
function example2(color) {
function faraway(jq_) { return jq_.find(".a"); }
var $div = $("<div style='color:" + color + "!important'
><div><div><div class='a b c'>ABC</div></div></div></div>");
// do this for browsers (like CHROME) who do not allow CSS2
properties on non-attached element
$div.appendTo($("head"));
// now pass and search inside this "un-attached" element
var $a = faraway($div);
var retval = $a.css("color")
$div.remove();
return retval;
}
example2("red") returns "red" in IE and "rgb(255,0,0)" in FF and
CHROME ...
AS I said, if jQ team thinks this is necessary to solve before people
start complaining (possibly) about jQ + Chrome, they are wellcome to
use these findings.
--DBJ

On Sat, Oct 24, 2009 at 9:49 AM, DBJDBJ <dbjdbj@gmail.com>

On Fri, Oct 23, 2009 at 7:22 PM, DBJDBJ <dbjdbj@gmail.com>