DOM2 getComputedStyle support

[Dirk Mueller]

On Saturday 14 February 2004 09:08, Zack Rusin wrote:

> 1) I'm not sure if centralizing the toCSSProperties in RenderObject is
> such a good idea. Initially I thought that I might reuse it in
> getOverrideStyle, but I'm not sure about that.

thats quite some code coming up.. Also, I'm not sure if that is the right 
approach. I think the computed style has to update when the rendertree 
changes, even without the JS re-requesting the stylesheet. but I'm not 100% 
sure, would need to test that and reread the spec. 

in that case one would have to implement a RenderedStyleDeclarationImpl that 
maps each and every query dynamically to the actual rendertree. on the other 
side, we can maybe reduce the code impact this way. I'd hate to write the 
reverse of CSSStyleSelector::applyRule() :/. But of course for making some 
sites / testcases work a quick&dirty implementation is more than fine. 

btw, your patch leaks since there is a ->ref() without any deref(). 

> 2) It fixes 26311 but exposes the following problem:
> Element::setAttribute changes the attribute but doesn't change the
> actual rendering. Due to which the example on:
> http://www.mozilla.org/docs/dom/domref/examples7.html doesn't work
> (setAttribute calls change the value but the changes aren't visible)
> Ideas?

Well, thats by purpose, since editing the dom tree changes the default 
(initial) value, not the current one. so when you click "reset" you'd see the 
change. 

does this work in recent browsers? I think we implemented it this way exactly 
for the reason of being compatible with the other browsers.