David Golightly said the following on 11/5/2006 3:55 PM:
First of all, thank you everyone for the helpful tutorial on life in
general, and on how to (not) be an ass on a message board.
I will refrain, for now, from commenting on that.
Best practices have changed considerably over the last 6-8 years in
JavaScript.
Nobody said anything about "Best Practices", but, since you mention
them, you may want to read this group FAQ and the Best Practices
document linked to in my signature. Both have been extensively reviewed
by the regulars in this group and - hands down - the consensus is that
you use the document.forms collection when working with forms.
Yes, using the forms collection works, even on modern
browsers. So does document.all.
Depending on your definition of "works" with regards to document.all. IE
doesn't know the difference between an ID and a NAME attribute so it
will return a reference to an element with this code:
<input name="myFreakingInput" value="my value">
alert(document.getElementById('myFreakingInput').value)
And that broken implementation is why so many regulars here tend to
steer clear of gEBI except when no other way remains to get a handle on it.
So does refering to id'd elements directly as JavaScript Objects.
Only in IE.
It may even be faster than gEBId.
That has too many variables to it other than just forms, Objects, and an
ID. The speed difference is directly related to how many objects are in
a page.
There is a thread here:
<URL:
http://groups-beta.google.com/group...49971ed?q=Randy+Webb+forms+gEBI+speed&lnk=nl&>
If GG wraps it and screws it up, this a tinyURL to the same thread:
<URL:
http://tinyurl.com/ydrqlo />
For some reason, the Lee in that thread has always set the no-archive
header so you can't see his posts. The only part of his posts you can
see are the parts that I and Dave Anderson were quoting. But, if you
follow the conversation between me and Dave, you can see that the
document.forms collection is faster - in IE - than gEBI is. The results
of that testing was the opposite in FF and Opera.
Fact of the matter is, I wouldn't recommend it because a) the W3 DOM
supercedes it and b) it's an idiosyncratic interface for an inline
function handler, when you can use gEBId for a general function to find
elements regardless of where they are in the document or whether they
belong to a <form> tag - it's a more general-purpose solution and
probably the best one for a newbie to learn.
Actually, the best one for a newbie to learn would be one that is 100%
fool-proof and when it comes to script forms, you can not beat the forms
collection for support. And, I wouldn't post the code I posted as a
one-for-all answer to the question. If you wanted a full blown answer to
the question, it would involve a form, and the form would get submitted
for non-script users, and onSubmit it would redirect to the page that
was wanted.
<script type="text/javascript">
function goThere(formRef){
window.location.href = '
http://www.myServer.com/' + formRef.inputName.value
return false
}
</script>
<form action="goSomeWhere.php"
onsubmit="return goThere(this)">
<input type="text" name="inputName">
<input type="submit">
</form>
The other problem with gEBI with forms is if you are giving your inputs
ID's, then they don't get submitted to the server.
I'm going to sit back and let this die now since this was a newbie
question, and this has ventured off-topic into an HTML discussion, but
for the record, it's still valid HTML 4.01 to close tags like <br />,
even though it's not necessary. In fact, all valid XHTML 1.0 is valid
HTML 4.01. Discouraging people from writing well-formed HTML will only
confuse them later when learning XHTML.
Before you leave, I would appreciate it if you would answer the
questions in my initial reply to you.
As an olive branch, I'm backing off the use of the <button> tag. Go
for it. But when you need document.getElementsByTagName('input'),
well, that's the tradeoff.
That's simple. You do a document.gEBTN('input') and .gEBTN('button') and
combine the two.
