Setting CSS props and timers from JavaScript

[Koos Vriezen]

On Sun, 3 Nov 2002, David Faure wrote:

> On Sunday 03 November 2002 16:47, Koos Vriezen wrote:
> > On Sun, 3 Nov 2002, David Faure wrote:
> > > > Another thing is that setting the top property. Now a property is first
> > > > removed and than added, marking it as changed trggering a recalcStyle.
> > > > Adding 'if (styleDecl.getPropertyValue(prop) == propvalue) return;'
> > > > in DOMCSSStyleDeclaration::tryPut does seem to prevent this (but may slow
> > > > down cases where propvalue != current value).
> > >
> > > Hmm, indeed. Which is why it might not be a good idea - in the common case
> > > it _is_ different. And if not, the recalc might be intentionnal. Websites which
> > > want to do this in a smarter way (for this case where the value is usually
> > > unchanged), can query the prop before setting it...
> >
> > Yes maybe, but how do you judge the programming skills of an average web
> > developer :). I rather protect my CPU for this...
>
> I don't understand. IMHO this solution makes the common case slower: all the
> cases that actually modify the value, will be slower. So this might make things worse,
> CPU-wise, on the whole.

No, the speed penalty of 'styleDecl.getPropertyValue(prop)' is much
smaller than that of a recalc imo. It's only one extra lookup (which could
be eliminated if we really want to, removeProperty also must find it).

> > If a developer wants to
> > trigger a recalc this way, it probably read the KHTML sources first :)
> > And what effect would a recalc have if nothing is changed?
>
> Something else could have been changed first, which didn't trigger a recalc
>  - see MS docu on StyleSheet::removeRule (which I implemented but didn't
> commit yet, due to my other CSS-related patch waiting for approval...)
> What they suggest is elem.innerText=elem.innerText :}

Which means that MS is even more lazier doing recalcs then? Btw, this
looks like a workaround that might be fixed in next release.

>
> > > [ The real problem IMHO is that there is no DOM event for "scrollbars moved",
> > > which such sites could use to move the static thingie, instead of polling :} ]
> >
> > IE has onScroll events, which are imo very suitable for this.
>
> Yup, sounds great. So
> 1) we need to implement it
> 2) we need to suggest it to the W3C DOM people
> 3) we can finally ask the "makeStatic" people to rewrite their stuff :)

That was not my point of course, could be said for all IE extension. I
only noted that it existed.

> I think CSS already has some 'static' stuff (as seen on some w3c page iirc),
> maybe this would be even better for this?

Not sure what you mean be 'static'. But if you talk about this
'makeStatic' menu bar, I don't think it would help much if they don't
include the animation effect of it.

Koos