Forum: Rails Spinoffs (closed, excessive spam) Observing Element.style.height change

Could anybody give me any suggestions for observing
Element.style.height change ?

Hmm this is an interesting idea, so many different ways to access that
property, and with no native property change model it seems
impossible.  My first thought was using a timer but that is going to
gum up resources.  If in your app you were savvy and used a setter
method you could implement an event that would get this done.  Using
prototype's setStyle, and ele being a valid dom reference you could do
something like this

ele.setStyle = ele.setStyle.wrap(function(prc, style){
  if(style.height && this.getHeight() != style.height.match(/^[0-9]+/
g).first()){
    prc(style);
    this.fire("derka:heightChange");
  }
  else
    prc(style);
});

Which would work fine for a single element, if you wanted to observe
multiple elements height change I'd suggest iterating over a
collection of objects that needed this functionality and wrap their
setStyle methods.

Here is a basic working demo of this in action, be sure to have
firebug working as the debug comes across in the console.
http://positionabsolute.net/projects/javascript/pr...


--
Matt Foster
Ajax Engineer
Nth Penguin, LLC
http://www.nthpenguin.com

Matt,
I think he meant an "actual" height change, not just intercepting
#setStyle call. Timer seems like an only option in that case, and
you're right about performance hog. On a side note, I wouldn't
recommend "wrapping" an already "methodized" #setStyle - it's very
inefficient. It's also a good idea to see what "style" is, as it could
be either an object or a string. Moreover, "style.height" could be 0,
so "if (style.height && ... )" would not work as expected.

- kangax

Kangax,

         True, my example method isn't rock solid, I wasn't about to
submit a ticket for it heh.  It would help to accommodate a string
value being passed, but the documentation states that it only accepts
a hash, this was more for proof of concept than the next big thing.  I
am curious about the "methodized" inefficiencies, would it be more
appropriate to set it as such...

ele.setStyle = Element.Methods.setStyle.wrap...


--
Matt Foster
Ajax Engineer
Nth Penguin, LLC
http://www.nthpenguin.com

It absolutely would. IE happens to be very sensitive to
"methodized" (and "wrapped" to some extent) methods. The problem is $
(as well as concat and $A) which does some heavy lifting in IE. Take a
look at this benchmark 
http://yura.thinkweb2.com/bench/test/performance/dom.html
There's a 10%-40% speed increase by simply replacing
"element.<method>" with "Element.<method>(element)" : )

- kangax

Thanks for discussion. The main goal is to set scrollbars (not native)
instantly when div height goes bigger than document viewport height. I
got an idea to fire an "custom" event every time when something added
into this div.

I just rant your test in FF3 & IE7 - the difference is significant,
especially in IE.
Do you know what accounts for that?
Is there any drawback to using Element.<method> instead of
element.<method> (beyond extra typing)?

What accounts for it is the fact that methodizing a function requires an
additional layer of indirection, an additional function call, and a 
bunch of
argument processing, each time the method is invoked.  In other words, 
every
call to element.method(...) has to push element onto the front of the
parameter list, and call Element.Methods.method(element, ...). 
Depending on
the browser, this array processing and calling a re-bound function 
really
adds up.

-Fred

On Tue, Jul 8, 2008 at 1:00 PM, andy.kriger@gmail.com 
<andy.kriger@gmail.com>
wrote:

>
> I just rant your test in FF3 & IE7 - the difference is significant,
> especially in IE.
> Do you know what accounts for that?
> Is there any drawback to using Element.<method> instead of
> element.<method> (beyond extra typing)?


--
Science answers questions; philosophy questions answers.