getElementById('x').value vs. x.value

[Pseudoquazi]

getElementById('x').value vs. x.value


Both versions of this javascript work equally well from what I can tell, though intuition tells me that using the full document.getElementById().value is more "proper." I'd like to use the shorter version as it just looks cleaner on the page, but before I go nuts shortening everything, I'd like to know a couple things:
1.) What is the theoretical/computational/something-to-that-effect difference?
2.) What are the disadvantages/advantages of each version?

y = parseFloat(document.getElementById('x').value);
document.getElementById('x').value = y.toFixed(2);

y = parseFloat(x.value);
x.value = y.toFixed(2);

Assume that "x" is the id of a textbox and that its value is a number. Also, the code above is generalized. My actual code is the same thing with different variables and repeated several times.
(Another note: I want "y" stored for later computation, so it's not completely frivolous.)
Browsers tested: IE 6 and Firefox 2.0 and Opera 9.26.

[rangana]

With these two snippets of code, I can tell that the second one is erroneous, not unless I'll see the whole of the code

y = parseFloat(document.getElementById('x').value);
document.getElementById('x').value = y.toFixed(2);

...This one is good

y = parseFloat(x.value);
x.value = y.toFixed(2);

...This one is erroneous, not unless you had declared the x variable already having that document id:

var x = document.getElementById('x');

...If it was declared already, then there is nothing wrong
...Both has the same function, and I would tell that the second one looks more elegant and flexible, because you'll just use the x variable instead of typing out [b]document.getElementById('x')...

I'm not more of a theorist, I'm more of a problem solver, but anyway I hope that helps

[Pseudoquazi]

Yeah, I was assuming that x was declared already. I should have noted that. My bad.

Hm. Interesting. I wonder if the need for the full document.getElementById() is like the need </p> tag or </li> tag or ectcetera. It works without just fine without. Or maybe it exists to contrast getElementByClass() and the like. It's all speculation on my part, though.

[rangana]

There is no getElementByClass()

...It should be document.getElementById('id').className

...or a number of ways to do it. For further reading

[codeexploiter]

In Firefox 3 they've incorporated a getElementsByClassName function which can be invoked from any elements that has children this will return a node list which contains the elements whose class name matches with the provided one.

Natively JavaScript/DOM doesn't support any such function now but you can find lot of such custom functions which can be used for your purpose without much difficulty. If you don't use these kind of function it would be difficult to access all those elements that uses a common CSS class.

You can refer the following URL in which you can find an exclusive discussion about this method, its performance, efficiency, etc.

http://ejohn.org/blog/getelementsbyc...ed-comparison/

[Pseudoquazi]

Well, let's just dump the theory of contrasting getElementByClass and the like, then, since it's a newer development.

...This one is erroneous, not unless you had declared the x variable already having that document id:
Code: var x = document.getElementById('x');

Wow. I completely missed what you were trying to tell me, Rangana. I see what you're saying completely now. Yeah, if "x" is declared as "document.getElementById('x')", then it should be exactly the same thing, sort of. (I was thinking that "x" was declared as just the name of a input style="text", but that's not really a declaration, now is it?)

The mystery is that even undeclared in that fashion, the code works the same on the surface. Anyway, here's what I found, now that I took to heart your wisdom: When I specifically don't declare x and use the shorter version, it still works, but only conditionally. After messing with it, I found that the shorthand only worked with input type="text". It also seems to only work for .value (not .cols, anyway).

So the disadvantage would be it must be .value and must be in a input type="text", it seems. I'm starting to question if I'm even right about that. Hm.... More on this as it develops.