firefox and innerHTML

B

bedhead

Why doesn't a SELECT element's innerHTML reflected which option was
selected? Works in IE. I need this functionality so that I can retain
what choices a user made in a tabbed interface.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://w3.org/1999/xhtml">
<head>

<script language="javascript">
function callAlert(){
var theHTML = document.getElementById('Radius').innerHTML;
//alert(theHTML);
}
</script>
<title>Untitled Document</title>
</head>

<body>
<form id="myForm">
<div id="myDiv">
<table border="0" width="430" cellpadding="3" cellspacing="0">
<tr>
<td font color="#ff0000">*</font>Radius:</td>
<td width="331" height="30" class="formData">
<select onChange="callAlert();" id="Radius" name="Radius">
<option value=".10" id="0">1/10 mile</option>
<option value=".20">1/5 mile</option>
<option value=".25">1/4 mile</option>
<option value=".5">1/2 mile</option>
<option value=".75">3/4 mile</option>
<option value="1">1 mile</option>
</select>
</td>
</tr>
</table>
</div>
</form>
</body>
</html>
 
M

Michael Winter

Why doesn't a SELECT element's innerHTML reflected which option was
selected?
Click to expand...

The selected attribute refers to pre-selection, not whether the element
is currently selected. Markup is static and doesn't change in response
to user actions.
I need this functionality so that I can retain what choices a user
made in a tabbed interface.
Click to expand...

Read the values from object properties and reassign them later.

[snip]

Mike
 
M

Mick White

bedhead said:
Why doesn't a SELECT element's innerHTML reflected which option was
selected? Works in IE. I need this functionality so that I can retain
what choices a user made in a tabbed interface.
Click to expand...

What are you looking for? The option's value, the option's text or the
option's selected index?
[...]
<script language="javascript">
function callAlert(){
var theHTML = document.getElementById('Radius').innerHTML;
//alert(theHTML);
}
</script>
Click to expand...

Why not pass the select object to the callAlert function?

<script type="text/javascript">
function callAlert(menu){
alert(menu.options[menu.selectedIndex].value);
alert(menu.options[menu.selectedIndex].text);
alert(menu.selectedIndex);
}
</script>

<select onChange="callAlert(this);" id="Radius" name="Radius">

Help?
[...]

Mick
 
S

Stephen Chalmers

bedhead said:
Why doesn't a SELECT element's innerHTML reflected which option was
selected? Works in IE. I need this functionality so that I can retain
what choices a user made in a tabbed interface.
Click to expand...

http://jibbering.com/FAQ/#FAQ4_13

Using the above technique, assign your form a NAME not an ID. Reading form elements does not involve
document.getElementById or .innerHTML. Please tell all your friends and ask them to tell all their friends etc.
 
L

Lasse Reichstein Nielsen

Stephen Chalmers said:
http://jibbering.com/FAQ/#FAQ4_13

Using the above technique, assign your form a NAME not an ID.
Click to expand...

I assume you refer to "id" and "name" attributes, but capitalizing
risks confuzing with HTML data types ID and NAME
<URL:http://www.w3.org/TR/html4/types.html>.

Anyway, give it an "id" attribute, not a name attribute, if you are
writing HTML 4 or later. The "name" attribute is not valid on form
elements at all. The only reason for using the "name" attribute is to
be compatible with Netscape 4 or its contemporaries, and in that case,
you should still use the valid "id" attribute with the same name.

The W3C DOM 2 HTML says that the forms collection (an
HTMLNodeCollection) can be indexed using the elements names or id's,
so using an "id" attribute still works.

/L
 
M

Matt Kruse

Lasse said:
The "name" attribute is not valid on form
elements at all. The only reason for using the "name" attribute is to
be compatible with Netscape 4 or its contemporaries, and in that case,
you should still use the valid "id" attribute with the same name.
Click to expand...

1) name attributes on form tags certainly is valid html 4.01.

2) Multiple forms can have the same name, but multiple forms may not have
the same id. In some cases, this might be an important fact.
 
M

Michael Winter

1) name attributes on form tags certainly is valid html 4.01.
Click to expand...

Correct. They're also valid in XHTML 1.0 Transitional (but not Strict).
2) Multiple forms can have the same name [...]
Click to expand...

No. The name and id attributes share the same namespace for most
elements. The uniqueness constraint applies equally when using either
attribute with a FORM element, as well as A, APPLET, FRAME, IFRAME, IMG
and MAP elements. See a few paragraphs into section 12.2.3 - Anchors
with the id attribute.

Mike
 
B

bedhead

Thanks for all the replies. Sorry for the confusion. This is just a
small example. I am getting the innerHTML of a DIV tag which
encompasses a very large form. I didn't want to get all the selected
indexes, checked, etc... of all elements in the form and restore them
later.

IE actually changes the innerHTML of the DIV to reflect what the user
selected. So, if you save the innerHTML you have their choices. I
would like to do a similar thing in FireFox if available.

Does innerHTML have similar functionality in FireFox? If not, is
saving all the current choices the only way to accomplish this?

Thanks
 
L

Lasse Reichstein Nielsen

Matt Kruse said:
1) name attributes on form tags certainly is valid html 4.01.
Click to expand...

So it is! It was just HTML 4.0 where it wasn't. It's not incorrect that
it's for compatability with old browsers though, as they say:
---
name = cdata [CI]
This attribute names the element so that it may be referred to from
style sheets or scripts. Note. This attribute has been included for
backwards compatibility. Applications should use the id attribute to
identify elements.
---
For style sheets, they have to mean using the [name="something"]
selector which IE still doesn't support (like most CSS2).
2) Multiple forms can have the same name, but multiple forms may not have
the same id. In some cases, this might be an important fact.
Click to expand...

And whenever a form has both an id and a name, it must be the same :)

I fail to see an application where multiple forms with the same
element is the best way to do anything, but it is allowed.

/L 'just use "id"!'
 
R

RobG

bedhead said:
Thanks for all the replies. Sorry for the confusion. This is just a
small example. I am getting the innerHTML of a DIV tag which
encompasses a very large form. I didn't want to get all the selected
indexes, checked, etc... of all elements in the form and restore them
later.

IE actually changes the innerHTML of the DIV to reflect what the user
selected. So, if you save the innerHTML you have their choices. I
would like to do a similar thing in FireFox if available.

Does innerHTML have similar functionality in FireFox?
Click to expand...

No. Given that 'innerHTML' is not a public standard nor fully
documented anywhere, whatever behaviour it has is what it has. As it is
a Microsoft invention, you could argue that any browser that doesn't do
what IE does has a faulty implementation.

But IE's version has its own problems: if you serialise the select
element with the user's currently selected options as 'selected', you
will need to code your own reset button as the original defaults are gone.

If you restore the page with the previously selected options being set
as 'selected' in the HTML, you will have the same problem however you
implement it - you will have to provide your own reset button.
If not, is
saving all the current choices the only way to accomplish this?
Click to expand...

Why not use display: none for non-selected tabs? The content stays in
the page and there are no issues with restoring forms. If you do the
layout right, with JavaScript disabled the tabs should just appear one
above the other and have anchors to navigate between them. With JS
enabled, they behave like tabs - hiding and showing the relevant bits.
 
V

VK

I assume you refer to "id" and "name" attributes, but capitalizing
risks confuzing with HTML data types ID and NAME
<URL:http://www.w3.org/TR/html4/types.html>.
Click to expand...
Anyway, give it an "id" attribute, not a name attribute, if you are
writing HTML 4 or later.
Click to expand...

Form elements without names will not be submited (even if they have
id's set) !
Form elements with names will be submited on form.submit() (with id or
without) !

It's kind of a pointless discussion because we are talking about a
legacy structure, W3 had to include into the new standards in the way
it was and will remain forever since Netscape 2.

As I mentioned before it's kind of "why one child but many children and
should we say many childs instead". In human language we have
historical traditions. In JavaScript/HTML we have legacy pressure,
which is sometimes more demanding than any traditions. If W3 had any
bolls and common sense, they would simply move HTML form standards in a
separate section (together with A, IMG, FRAME and IFRAME). But they
prefer to act as if all standards indeed being changed with each paper
W3 produces.
 
L

Lasse Reichstein Nielsen

VK said:
Form elements without names will not be submited (even if they have
id's set) !
Click to expand...

I think you are talking about form controls (with tag names, e.g.,
input, select, ...) and not form elements (with the tag name "form").

Apart from that, I agree. W3C has the unappreciated job of trying to
standardize already existing de-facto standards, with most users
either not knowing or not caring about anything but the existing
implementations.

/L
 
V

VK

Form elements without names will not be submited (even if they have
I think you are talking about form controls (with tag names, e.g.,
input, select, ...) and not form elements (with the tag name "form").
Click to expand...

Well, we have document.forms[0].elements[0]
So for the term consistency <input>, <button> etc. should be called
"form elements" (and they were for many years).

And <form> itself is "form object" or simply "form(s)" (Occam's razor).

Just a suggestion...
 
M

Michael Winter

On 11/07/2005 13:37, VK wrote:

[VK:]
[LRN:]
I think you are talking about form controls (with tag names, e.g.,
input, select, ...) and not form elements (with the tag name "form").
Click to expand...

Well, we have document.forms[0].elements[0]
Click to expand...

Property names used in the DOM are of no concern when you're discussing
HTML.
So for the term consistency <input>, <button> etc. should be called
"form elements" [...]
Click to expand...

<p>...</p>

is a P element,

<form action="...">...</form>

is a FORM element, and

<input>

is an INPUT element. So, it is correct to refer to a form as a FORM
element, but confusing to refer to the elements within it as form
elements as that could be construed as many FORMs.

The HTML Specification introduces the notion of 'controls' itself in
section 17.2, aptly titled "Controls", so it would seem to be a very
simple method of distinction.

[snip]

Mike
 
T

Thomas 'PointedEars' Lahn

Michael said:
2) Multiple forms can have the same name [...]
Click to expand...

No.
Click to expand...

Yes, they certainly can.

<form action="" name="foo"><p></p></form>
<form action="" name="foo"><p></p></form>

is perfectly Valid HTML 4.01 (Strict!).
The name and id attributes share the same namespace for most
elements.
Click to expand...

That is correct but does not matter here.
The uniqueness constraint applies equally when using either attribute
with a FORM element, as well as A, APPLET, FRAME, IFRAME, IMG and MAP
elements.
Click to expand...

No, it certainly does not at all.
See a few paragraphs into section 12.2.3 - Anchors with the id
attribute.
Click to expand...

You read the section, particularly the "ILLEGAL EXAMPLE" not in context
or not carefully enough. `id' (ID) is not `name' (here: CDATA).
Uniqueness in (X)HTML is only a matter when IDs are involved, i.e. two
different elements may not have the same ID, and when name _and_ ID are
the same, they must not be of different elements (to avoid ambiguity of
fragment identifiers).

Different `form' elements in one HTML document may of course have the
same value for the `name' attribute or short: the same name. In the
element of the `document.forms' collection and the value returned by
the HTMLDocument.getElementsByName() method, they then make up an
collection of their own.

And when you think about it: not allowing the same name for different
elements would render the getElementsByTagName() method of the W3C DOM's
HTMLDocument interface redundant.


PointedEars
 
L

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn said:
and when name _and_ ID are the same, they must not be of different
elements (to avoid ambiguity of fragment identifiers).
Click to expand...

Actually, it's the othe way around. When "id" and "name" attributes
are both on the same element, they must be identical (with certain
exceptions, including form controls). Otherwise, there is no
requirement that two elements in the same namespace cannot have the
same string as respectively name and id.

And when you think about it: not allowing the same name for different
elements would render the getElementsByTagName() method of the W3C DOM's
HTMLDocument interface redundant.
Click to expand...

Not necessarily. You can use gEBTN in different contexts, e.g., inside
a form, where there can be elements with the same name attriubute
(form controls). That does not preclude restricting names on form
elements to not be identical (there is no such restriction, but gEBTN
is not an argument against there being one :)

/L
 
T

Thomas 'PointedEars' Lahn

Lasse said:
Actually, it's the othe way around. When "id" and "name" attributes
are both on the same element, they must be identical (with certain
exceptions, including form controls).
Click to expand...

Please, that is just a matter of wording.
My wording is: if (x.A == y.B) x == y;
Your wording is: if (x.A && x.B && !exception) x.A == x.B;
Otherwise, there is no requirement that two elements in the same
namespace cannot have the same string as respectively name and id.
Click to expand...

No, _IDs_ MUST always be unique.
Not necessarily. You can use gEBTN in different contexts, e.g.,
inside a form, where there can be elements with the same name
attriubute (form controls). That does not preclude restricting names
on form elements to not be identical (there is no such restriction,
but gEBTN is not an argument against there being one :)
Click to expand...

I think you just blew up my logic module, but you are probably right :)
However, not all same-named elements can be referred to via
HTMLCollection objects, therefore getElementsByTagName() is necessary
as a means to refer to elements by name.


PointedEars
 
M

Michael Winter

Michael said:
[Multiple forms cannot have the same name attribute value.]
Click to expand...

Yes, they certainly can.

<form action="" name="foo"><p></p></form>
<form action="" name="foo"><p></p></form>

is perfectly Valid HTML 4.01 (Strict!).
Click to expand...

Based on what criteria? An SGML validator isn't an indicator either way
because the DTD cannot, in this instance, express the constraint because
name attributes (with one exception) are CDATA.
That is correct but does not matter here.
Click to expand...

Yes, I concede to an error here. The reference I made isn't appropriate,
but that doesn't end the matter. :)

[snip]
Different `form' elements in one HTML document may of course have the
same value for the `name' attribute or short: the same name. In the
element of the `document.forms' collection and the value returned by
the HTMLDocument.getElementsByName() method, they then make up an
collection of their own.
Click to expand...

In the latter, yes. In the former, no. Neither Mozilla (including recent
Firefox releases), Netscape, nor Opera versions prior to 7.11 (possibly
earlier, but definitely later than 7.03) return a collection from the
forms collection. I would assume that Opera only changed their behaviour
as they continued the trend to be a compromise between IE and the W3C.

As I see it, the name attribute was introduced into HTML for the IMG and
FORM elements (ignore the previous list) for the benefit of Netscape. It
missed proper support for the id attribute, but had implemented name, so
in a revision published 1999-12-04, HTML 4.0 added the name attribute
but immediately marked it as a compatibility feature.

The attribute, in these cases (it has actual uses with other elements),
was always meant as an identifier analogous to the id attribute:

"JavaScript can use the NAME attribute to differentiate different
forms if there are multiple forms on a page."
-- Netscape HTML Tag Reference[1]

One can hardly differentiate if the same name is used, and as such the
forms collection will return the first FORM element in source order in
the browsers I mentioned above (and probably others, too).

[snip]
And when you think about it: not allowing the same name for different
elements would render the getElementsByTagName() method of the W3C DOM's
HTMLDocument interface redundant.
Click to expand...

What's the getElementsByTagName method got to do with this? As for
getElementsByName, the answer there is actually quite simple: the
HTMLCollection interface is only meant to return single
Node-implementing objects via the item and namedItem methods (and the
property accessor equivalents). That browsers return a collection is a
product of DOM 0, not DOM 1 or 2. As such, the getElementsByName method
was meant to fill this void.

Of course, I'm not, nor have I been, a member of the HTML or DOM Working
Groups, so this is just my interpretation of events.

Mike


[1]
<URL:http://devedge-temp.mozilla.org/library/manuals/1998/htmlguide/tags10.html#1292308>
 
L

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn said:
Lasse Reichstein Nielsen schrieb:


Please, that is just a matter of wording.
My wording is: if (x.A == y.B) x == y;
Your wording is: if (x.A && x.B && !exception) x.A == x.B;
Click to expand...

I agree with the representation of the logic, and I don't think
it's a matter of the wording. What your wording states is not
correct. This is valid code:

<img id="foo" src="something.png">
<img name="foo" src="something.png">

but is not allowed by your wording.

You are correct in the context of anchors (<a> elements with a name
attribute), where the anchor name must be unique in a document, but
name attributes on other elements does not (necessarily) become
anchors (i.e., valid targets for fragment identifiers).

(This is all in section 12.2 of the HTML 4.01 specification)
No, _IDs_ MUST always be unique.
Click to expand...

Absolutely, but what I tried to say was that the example above is
allowed ("respectively" should rule out that both are "id"'s).
The word "namespace" doesn't really make sense, though. I was
thinking about the namespace defind by a form, but it's really
irrelevant.

I think you just blew up my logic module, but you are probably right :)
Click to expand...

I think we are both wrong, because getElementsByTagName uses the tag
name (duh :) and not the name attribute, so it's not really relevant.
We were probably both thinking of getElementsByName from HTMLDocument :).
However, not all same-named elements can be referred to via
HTMLCollection objects, therefore getElementsByTagName() is necessary
as a means to refer to elements by name.
Click to expand...

.... if one should be so inclined. In XHTML documents, only form
controls are returned by gEBN, and for most uses, the name attribute
is only retained for backwards compatability.

/L
 
T

Thomas 'PointedEars' Lahn

Lasse said:
Thomas 'PointedEars' Lahn said:
Lasse Reichstein Nielsen schrieb:
Please, that is just a matter of wording.
My wording is: if (x.A == y.B) x == y;
Your wording is: if (x.A && x.B && !exception) x.A == x.B;
Click to expand...

I agree with the representation of the logic, and I don't think
it's a matter of the wording. What your wording states is not
correct. This is valid code:

<img id="foo" src="something.png">
<img name="foo" src="something.png">

but is not allowed by your wording. [...]
Click to expand...

Yes, it is not Valid HTML since the `alt' attribute is missing ;-)

Seriously, you are probably right. Interestingly, the W3C Validator
does not care about that either.
Absolutely, but what I tried to say was that the example above is
allowed ("respectively" should rule out that both are "id"'s).
The word "namespace" doesn't really make sense, though. I was
thinking about the namespace defind by a form, but it's really
irrelevant.
ACK


I think we are both wrong, because getElementsByTagName uses the tag
name (duh :) and not the name attribute, so it's not really relevant.
We were probably both thinking of getElementsByName from
HTMLDocument :).
Click to expand...

Oh my, yes of course! :) Sorry for causing confusion.
... if one should be so inclined. In XHTML documents, only form
controls are returned by gEBN, and for most uses, the name
attribute is only retained for backwards compatability.
Click to expand...

No, in XHTML 1.0 _Strict_, the following elements do have the `name'
attribute:

meta, a, object, param, map, input, select, textarea, button.

Only four of them can be considered form elements.

In XHTML 1.1, the following elements do have the `name' attribute:

- in the Applet Module: param
- in the Basic Forms Module: input, select, textarea
- in the Forms Module: input, select, textarea, button
- in the Object Module: object, param
- in the Metainformation Module: meta

I don't care about XHTML 2.0, it is not a Recommendation (yet).


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Can someone tell me if this a real tracker? Or is it one designed to show you a different message at certain times, ie. acting like one? 0
Uncaught ReferenceError: item is not defined at HTMLButtonElement.onclick in the: <button onclick="item.inserir()">Inserir dados</button> 1
innerHTML with AJAX problem 12
Survey details won't go through using php, ajax, Mysql 0
Help needed with thank you message 5
How to create a JSON array with values from DOM(HTML TABLE) when I click a button using JQuery/Javascript? 0
Add Image and label dynamically inside the dropdown 2
action_page.php form 2

Members online

No members online now.
Total: 27 (members: 0, guests: 27)
Robots: 657

Forum statistics

Threads
473,769
Messages
2,569,581
Members
45,057
Latest member
KetoBeezACVGummies

Latest Threads

Top