On Feb 27, 12:42 am, John Resig <jere...@gmail.com> wrote:
> > The benchmark is getElementById().getElementsByTagName() - why not
> > inlcude that in the test?
>
> But it's not that simple (it never is). That code doesn't take into
> account browsers, like IE, returning element that have a name equal to
> the ID,
There is a simple solution for that: don't create elements with a name
equal to some other element's id.
> not does it take into account the element (with the ID) not
> existing,
Of course production code would test the return from getElementById if
there is any doubt that the element exists, this is a benchmarking
exercise and the extra test is irrelevant for that.
> nor does it return a static list of elements - it returns a
> live NodeSet (which is a constant source of misconceptions for
> developers).
I don't think a method that's hugely faster should be ignored because
some programmers don't understand NodeLists. It's a speed benchmark.
> If you want to play the cross-browser roulette, make sure you go all the way
> in.
There is one cross-browser issue here and that is easily dealt with,
there is no need to saddle everyone with slow logic because of the
idiosyncrasies of two browsers, particularly when other solutions are
available.
In any case, the additional code to resolve the name/id issue would
not affect its use as a benchmark as it is a one-of bit of code to get
a single element (and the name/id resolution path should never be
taken on browsers that don't have the issue), the real effort is
getting the collection of child nodes.
--
Rob
