getElementByID error...

[drew]

Hi all!

I have this annoying problem with netscape...
I'm trying to access a form value by using getElementByID and in NS i
end up with a null reference.

The following HTML is the form component that gives me headache:
<form name='task' ...>
....
<select name='prioritySelect' class='selectwidth'>
<option value=''>Choose one</option>
<option value='1'>Critical</option>
<option value='2'>High</option>
<option value='3'>Medium</option>
<option value='4'>Low</option>
</select>
....
</form>

And the related javascript code:
if(document.getElementById("prioritySelect").disabled == false)
{ ... }

When digging into this I can get the desired information by using
document.task.prioritySelect, but that should not be necessary, right?

I hope that anyone knows how to deal with this problem...

Regards,
Drew

 

[Richard Cornford]

I have this annoying problem with netscape...
I'm trying to access a form value by using getElementByID
and in NS i end up with a null reference.

The following HTML is the form component that gives me headache:
<form name='task' ...>
...
<select name='prioritySelect' class='selectwidth'>

This element has no ID attribute.

And the related javascript code:
if(document.getElementById("prioritySelect").disabled == false)
{ ... }

The above select element has no ID attribute so what makes you think
that a method with the name "getElementById" could retrieve a reference
to it?

When digging into this I can get the desired information
by using document.task.prioritySelect,

Better would be:-

document.forms['task'].elements['prioritySelect']

- as it conforms with the pertinent parts of the W3C HTML DOM
specification and is supported by every browser that understands what a
form is (for maximum back compatibility).

but that should not be necessary, right?

If you don't give an element an ID it is unrealistic to expect to be
able to refer to it by ID.

I hope that anyone knows how to deal with this problem...

Give the element an ID to refer to it by or use a property accessor
relative to the document.forms collection and the elements collection of
the form.

Richard.

 

[Mark Preston]

If you want to use getElementById() to access this element, then it needs an
id attribute:

<select id="..." ...>

That does seem the obvious comment...

 

[Jim Ley]

If you don't give an element an ID it is unrealistic to expect to be
able to refer to it by ID.

not in IE!

a=document.body.firstChild.uniqueID;
el=document.getElementById(a);
alert(el+','+el.id)

gEBI can get objects without ID's...

(this can actually be useful if you don't want to keep a reference to
the object to avoid DOM leaks, and are worried about people mutating
ID's on you...)

Jim.

 

[Richard Cornford]

not in IE!

a=document.body.firstChild.uniqueID;
el=document.getElementById(a);
alert(el+','+el.id)

Was uniqueID introduced in IE 5.5 or 6? I was a bit alarmed to find that
all DOM elements also appear in the document.all collection under a
property name that corresponds to its uniqueID on IE 6. Particularly as
IE's property accessor resolution is slower the more properties an
object has and that would nearly double the size of the document.all
collection.

gEBI can get objects without ID's...

<snip>

Yes I have noticed, and it looks like gEBI is optimised on IE to look up
the ID in the document.all collection (returning the first element of
collections found) and when it looks there it also finds, and returns,
named elements. But the method name and the W3C specs definitely suggest
that this is incorrect behaviour.

Richard.

 

[Jim Ley]

Yes I have noticed, and it looks like gEBI is optimised on IE to look up
the ID in the document.all collection (returning the first element of
collections found) and when it looks there it also finds, and returns,
named elements.

It's only incorrect behaviour if the doctype is an HTML one without an
internal subset, we know IE doesn't actually read the doctype or parse
it etc. it just has its own internal one. it's own internal one could
have NAME as type ID, and therefore all is fine if gEBI returns it.

Given that most people return invalid documents we definately can't
complain about DOM behaviour on those, if we return a valid HTML or
XHTML document that says NAME isn't an ID, then we can complain.

Jim.

 

[Richard Cornford]

Given that most people return invalid documents we definately
can't complain about DOM behaviour on those, if we return a
valid HTML or XHTML document that says NAME isn't an ID, then
we can complain.

I always forget that HTML can be valid and unusual if it has its own
custom DTD. Or more precisely, I don't forget I just disregard the
possibility as I see little reason for doing that, and it wouldn't alter
the scriptability of the resulting DOM in HTML browsers (because, as you
say, they aren’t interested in the DTD anyway).

OK, gEBI should be expected to have its W3C Core DOM specified behaviour
in a valid HTML 4 (with standard DTD) document, but should anything be
expected from an invalid document?

Richard

 

[Jim Ley]

but should anything be
expected from an invalid document?

All bets are off on invalid documents. Standards can only really talk
about what conforming user agents do to its own valid documents.

Invalid documents could simply be adhering to a different standard,
and text/html puts no limits on what can be served as it.

Jim.