firefox and innerHTML

On 10/07/2005 23:20, bedhead wrote:

Why doesn't a SELECT element's innerHTML reflected which option was
selected?
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.

Read the values from object properties and reassign them later.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Jul 23 '05 #2

Mick White

bedhead wrote:

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.
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>

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

Jul 23 '05 #3

Stephen Chalmers

bedhead <ms***@consultshaw.com> wrote in message news:11**********************@g43g2000cwa.googlegr oups.com...

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.

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.

--
Stephen Chalmers

Jul 23 '05 #4

"Stephen Chalmers" <ig******@lycos.co.uk> writes:

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

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

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
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Jul 23 '05 #5

Matt Kruse

Lasse Reichstein Nielsen wrote:

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.

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.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

Jul 23 '05 #6

On 11/07/2005 01:06, Matt Kruse wrote:

Lasse Reichstein Nielsen wrote:
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.
1) name attributes on form tags certainly is valid html 4.01.

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

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

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Jul 23 '05 #7

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

Jul 23 '05 #8

"Matt Kruse" <ne********@mattkruse.com> writes:

1) name attributes on form tags certainly is valid html 4.01.
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.

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"!'
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Jul 23 '05 #9

RobG

bedhead wrote:

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?
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?

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.
--
Rob

Jul 23 '05 #10

> 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.

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.

Jul 23 '05 #11

"VK" <sc**********@yahoo.com> writes:

Form elements without names will not be submited (even if they have
id's set) !

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
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Jul 23 '05 #12

>> Form elements without names will not be submited (even if they have

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

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...

Jul 23 '05 #13

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

[VK:]

Form elements without names will not be submited (even if they have
id's set) !

[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").
Well, we have document.forms[0].elements[0]

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" [...]

<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

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Jul 23 '05 #14

Michael Winter schrieb:

On 11/07/2005 01:06, Matt Kruse wrote:
2) Multiple forms can have the same name [...]
No.

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.
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.
No, it certainly does not at all.
See a few paragraphs into section 12.2.3 - Anchors with the id
attribute.

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

Jul 23 '05 #15

"Thomas 'PointedEars' Lahn" <Po*********@web.de> writes:

and when name _and_ ID are the same, they must not be of different
elements (to avoid ambiguity of fragment identifiers).
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.

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
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Jul 23 '05 #16

Lasse Reichstein Nielsen schrieb:

"Thomas 'PointedEars' Lahn" <Po*********@web.de> writes:
and when name _and_ ID are the same, they must not be of different
elements (to avoid ambiguity of fragment identifiers).
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).

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.

No, _IDs_ MUST always be unique.

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.

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 :)

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

Jul 23 '05 #17

On 12/07/2005 13:51, Thomas 'PointedEars' Lahn wrote:

Michael Winter schrieb:
[Multiple forms cannot have the same name attribute value.]
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!).

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.

The name and id attributes share the same namespace for most
elements.

That is correct but does not matter here.

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.
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.

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>

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Jul 23 '05 #18

"Thomas 'PointedEars' Lahn" <Po*********@web.de> writes:

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;
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)

Otherwise, there is no requirement that two elements in the same
namespace cannot have the same string as respectively name and id.

No, _IDs_ MUST always be unique.

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 :)
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.

.... 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
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Jul 23 '05 #19

Lasse Reichstein Nielsen schrieb:

"Thomas 'PointedEars' Lahn" <Po*********@web.de> writes:
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;

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. [...]

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.

Otherwise, there is no requirement that two elements in the same
namespace cannot have the same string as respectively name and id.

No, _IDs_ MUST always be unique.

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 you just blew up my logic module, but you are probably
right :)

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 :).

Oh my, yes of course! :) Sorry for causing confusion.

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.

... 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.

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

Jul 23 '05 #20

Michael Winter schrieb:

On 12/07/2005 13:51, Thomas 'PointedEars' Lahn wrote:
Michael Winter schrieb:
[Multiple forms cannot have the same name attribute value.]
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!).

Based on what criteria? [...]

The HTML 4.01 Specification.

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.

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.

Yes, indeed. And the namedItem() method of the HTMLCollection
interface does not require them to. D'oh.

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.

What's the getElementsByTagName method got to do with this?

Nothing, repeated typo.
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.

You're probably right.
PointedEars

Jul 23 '05 #21

On 13/07/2005 08:36, Thomas 'PointedEars' Lahn wrote:

[Referring to getElementsByTagName, not getElementsByName]

Oh my, yes of course! :) Sorry for causing confusion.
Given the poor state of mind I was in yesterday (I've had sleep now.
Yay! :D), you certainly did confuse me. You're forgiven, though. :p

[Retaining the name attribute in XHTML]
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.

Five, I believe. The OBJECT element can also participate in form
submissions, however the specification doesn't define how this
particular mechanism works which is verging on ridiculous. Still, it is
a form control and retains its name attribute for this purpose.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Jul 23 '05 #22

Michael Winter schrieb:

On 13/07/2005 08:36, Thomas 'PointedEars' Lahn wrote:
[Retaining the name attribute in XHTML]

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.
Five, I believe. The OBJECT element can also participate in form
submissions,

Yes, indeed!
however the specification doesn't define how this particular
mechanism works [...]

<http://www.w3.org/TR/html4/struct/objects.html#edef-OBJECT>
PointedEars

Jul 23 '05 #23

On 13/07/2005 11:11, Thomas 'PointedEars' Lahn wrote:

Michael Winter schrieb:

[Submitting an OBJECT]

however the specification doesn't define how this particular
mechanism works [...]

<http://www.w3.org/TR/html4/struct/objects.html#edef-OBJECT>

I meant regarding the value of that OBJECT element. In both 17.2 and
17.12.2, the specification says that the value "is determined by the
object's implementation".

The description in 17.2 goes on to say:

"... (i.e., it lies outside the scope of this specification)."

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Jul 23 '05 #24