[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