Yes, that's what I'm getting at. Like I said, I noticed with my
jQuery coding and script optimization efforts that DOM access has
quite a significant overhead, and that jQuery animates by manipulating
the DOM style attribute for all elements being animated. If it were
possible to manipulate the stylesheet rules incrementally then you
could avoid that overhead. I have no idea if it's possible, but it
might be worth looking into.
On Jul 5, 4:52 pm, "Benjamin Sterling"
<[EMAIL PROTECTED]> wrote:
> Gordon,
> So you are saying that if you have a class:
>
> .theAnimateClass{
> position:absolute;
> left:0px;
>
> }
>
> That the class params should change, not the inline params to that
> particular element:
>
> ie, you want to move the element with the class name of theAnimateClass for
> current position (0px) to 100px left:
>
> This:
> .theAnimateClass{
> position:absolute;
> left:0px;
> }
>
> would change to:
> .theAnimateClass{
> position:absolute;
> left:100px;
> }
>
> But incrementally, stepping 1px at a time to 100px, depending on the speed.
>
> If that is what you are saying, that is an interesting idea, not sure how
> that would be achieved though.
>
> On 7/5/07, Gordon <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > That wasn't quite what I was getting at. While the ability to morph
> > between one class and another is quite nifty, as far as I can tell, it
> > stil works by modifying the style attribute of the target elements.
> > What I'm suggesting is a speed optimization, where animation is
> > achieved by modifying a rule in a stylesheet instead of modifying the
> > style attribute of the target elements.
>
> > On Jul 5, 4:19 pm, Karl Swedberg <[EMAIL PROTECTED]> wrote:
> > > Hi Gordon,
>
> > > There is an extension to the .animate() method in Interface that
> > > allows you to animate classes. Perhaps it's more in line with what
> > > you're looking for?
> > > See the demo here:
> > > http://interface.eyecon.ro/demos/animate.html
>
> > > --Karl
> > > _________________
> > > Karl Swedbergwww.englishrules.comwww.learningjquery.com
>
> > > On Jul 5, 2007, at 10:38 AM, Gordon wrote:
>
> > > > It has been my observation that, when animating a lot of elements,
> > > > jQuery does so by manipulating the style attribute of each element to
> > > > be animated directly. Accessign DOM attributes tends to be relitively
> > > > slow in most browsers, and if you're applying an effect to a large
> > > > number of elements, this can really tell as animations that were
> > > > smooth for small numbers of elements grow increasingly choppy.
>
> > > > An idea occured to me, maybe it would be possible to use stylesheet
> > > > rules for animating elements instead of manipulating the DOM style
> > > > attribute directly. Of course this wouldn't be practical in all
> > > > circumstances, but it could lead to dramatic speedups in the
> > > > circumstances where it could be applied.
>
> > > > Foe example: Consider $('.someclass').fadeOut ('slow') as an example.
> > > > In current versions of jQuery all elements that match the selector get
> > > > an opacity value attached to their style attribute, which is then
> > > > decremented down to 0 to produce the fadeout effect. This is fine
> > > > when dealign with 10 or 20 elements, but when you're dealing with more
> > > > than 100 the results are choppy enough that in some circumstances it
> > > > can appear as if no animation took place at all and the elements were
> > > > simply hidden.
>
> > > > now suppose that instead of doing that the jQuery library minipulated
> > > > the .someclass rule directly (or created one if it didn't exist), now
> > > > there would only be 1 value that would have to be decremented for the
> > > > fadeout to happen instead of (number of elements) values. This would
> > > > eliminate a lot of DOM access overhead, and would hopefully mitigate
> > > > the choppiness problem when working with a lot of elements. Of course
> > > > doing a lot of complex animation would cause choppiness no matter what
> > > > you did, but a stylesheet rules based approach might stave off the
> > > > threshold between an acceptible level and unacceptible level to a
> > > > considerably higher level.
>
> > > > What do you think? Can something like this be done in a future
> > > > version of jQuery? Would it be possible/practical? Would the
> > > > elimated DOM overhead be worth it?
>
> --
> Benjamin Sterlinghttp://www.KenzoMedia.comhttp://www.KenzoHosting.com
