[Javascript] Apply padding via javascript

Paul Novitski paul at juniperwebcraft.com
Sun Aug 20 01:15:30 CDT 2006


At 03:56 PM 8/19/2006, Paul Novitski wrote:
>         var oDiv = document.getElementById("MyBlock");
>         oDiv.style.padding = ...

At 07:16 PM 8/19/2006, Troy III Ajnej wrote:
>Yes, that would be my preferred way also.
>
>Although I think this is the same bull differently packed and 
>"borrowed" from first release of IE 4.0.
>This is a call of element extracted from document members, the same 
>mistake IE4.0 did.
>
>The argument:
>Now why do I like your approach more, than:
>              document.getElementById("MyBlock").style.padding = ...;
>of course, only if:
>              var oDiv = document.getElementById("MyBlock");
>is declared as global variable. Otherwise there is no benefit!


No benefit?  I disagree.  For me a major advantage of breaking the 
expression into two statements is that, if the element "MyBlock" is 
not found, the single-statement version crashes javascript, whereas 
breaking it into two statements allows the script to walk around the 
fault or gracefully bail:

         var oDiv = document.getElementById("MyBlock");
                 if (oDiv) oDiv.style.padding = ...
or:
                 if (!oDiv) return;

Another related advantage is that it's easier to debug and trace a 
script that executes fewer operations per statement.


>That's because every time the script calls the object, the browser 
>has to iterate through all document objects once again.

Are you sure?  Because getElementById returns a single result, an 
intelligently-written engine would stop searching at the first 
find.  Also, I strongly suspect that when most browsers parse the DOM 
they creates a sorted index of ids and classes, so "searching the 
DOM" really amounts to walking an index of much smaller size and 
greater organization.

I don't really think it matters what syntax is used.  If you're 
referring to a uniquely identified element on a page, a browser is 
probably going to use the same internal methods to point to it.

         document.getElementById("MyBlock").
         document.MyBlock.
         MyBlock.

Regardless of the syntax provided to the human user, under the hood 
the javascript interpreter is still having to request the named 
object from the DOM.  Taking the id out of its quotation marks and 
placing it right in the syntax might look like it's being compiled 
before execution, but in fact the javascript interpreter has to 
compile the code before it knows what elements are in the DOM -- and 
of course we can always add and subtract elements, so searching the 
DOM or its indices is unavoidable in any syntax.

But I think this is largely academic.  Being geeky programmers who 
see beauty in elegant code, we prefer to eliminate unnecessary steps 
such as extra DOM searches.  Still, unless you've got an enormous 
page or you're cycling a zillion iterations, the chances are that 
your script will execute in a tiny fraction of a second and the 
difference between one and ten repetitions of getElementById will be 
unnoticeable by a human being.

This is all speculative, of course, since I don't know exactly how 
various browsers are coded; I'm just guessing based on common sense 
and my own work in parsing HTML.


>But seeing that this is now inefficient for coders, they've 
>immediately introduced
>the direct object reference.
>              MyBlock.style.something...;
>Something W3C never did! -I wonder why?!

Good question!

Personally I prefer the getElementById() approach because I have to 
hard-code the element Id into the script only once -- after that I 
simply refer to it with a variable.  This makes it easier to write 
software in abstract modules.

Regards,
Paul 




More information about the Javascript mailing list