Radio buttons do not appear checked

[Phil Powell]

<b>Agency 4</b>
<input type="radio" name="permission[4]" value="1" checked> Yes
<input type="radio" name="permission[4]" value="0" > No
<br>
<b>Agency 5</b>
<input type="radio" name="permission[5]" value="1" checked> Yes
<input type="radio" name="permission[5]" value="0" > No
<br>
I have it set up this way but upon viewing in the browser none of the
radio buttons appear checked.

By the way the radio button names MUST remain in the PHP array format
as they will be referenced EXACTLY like that by PHP on the server end.
Sorry can't change that.

What can I do?

Phil

[Mike]

I think what you want want is to change your input type to "checkbox"

Cheers,
Mike

"Phil Powell" <so*****@erols.com> wrote in message
news:1c**************************@posting.google.c om...

<b>Agency 4</b>
<input type="radio" name="permission[4]" value="1" checked> Yes
<input type="radio" name="permission[4]" value="0" > No
<br>
<b>Agency 5</b>
<input type="radio" name="permission[5]" value="1" checked> Yes
<input type="radio" name="permission[5]" value="0" > No
<br>
I have it set up this way but upon viewing in the browser none of the
radio buttons appear checked.

By the way the radio button names MUST remain in the PHP array format
as they will be referenced EXACTLY like that by PHP on the server end.
Sorry can't change that.

What can I do?

Phil

[Andy Hassall]

On 30 Sep 2003 13:41:13 -0700, so*****@erols.com (Phil Powell) wrote:

<b>Agency 4</b>
<input type="radio" name="permission[4]" value="1" checked> Yes
<input type="radio" name="permission[4]" value="0" > No
<br>
<b>Agency 5</b>
<input type="radio" name="permission[5]" value="1" checked> Yes
<input type="radio" name="permission[5]" value="0" > No
<br>
I have it set up this way but upon viewing in the browser none of the
radio buttons appear checked.

Works for me, on IE6 and Mozilla 1.4. What browser are you using?

--
Andy Hassall (an**@andyh.co.uk) icq(5747695) (http://www.andyh.co.uk)
Space: disk usage analysis tool (http://www.andyhsoftware.co.uk/space)

[Hywel Jenkins]

In article <1c**************************@posting.google.com >,
so*****@erols.com says...

<b>Agency 4</b>
<input type="radio" name="permission[4]" value="1" checked> Yes
<input type="radio" name="permission[4]" value="0" > No
<br>
<b>Agency 5</b>
<input type="radio" name="permission[5]" value="1" checked> Yes
<input type="radio" name="permission[5]" value="0" > No
<br>

I have it set up this way but upon viewing in the browser none of the
radio buttons appear checked.

By the way the radio button names MUST remain in the PHP array format
as they will be referenced EXACTLY like that by PHP on the server end.
Sorry can't change that.
Works for me in IE6 and Firebird 0.6.1

What can I do?

Find a more appropriate group. This is neither a PHP nor JavaScript
issue.

--
Hywel I do not eat quiche
http://hyweljenkins.co.uk/
http://hyweljenkins.co.uk/mfaq.php

[Andy Hassall]

On Tue, 30 Sep 2003 23:48:57 +0300, "Mike" <no*****@noemail.com> wrote:

"Phil Powell" <so*****@erols.com> wrote in message
news:1c**************************@posting.google. com...

<b>Agency 4</b>
<input type="radio" name="permission[4]" value="1" checked> Yes
<input type="radio" name="permission[4]" value="0" > No

I think what you want want is to change your input type to "checkbox"

Why? How can the reply be 'Yes' and 'No' at the same time? Radio looks the
sensible choice here.

--
Andy Hassall (an**@andyh.co.uk) icq(5747695) (http://www.andyh.co.uk)
Space: disk usage analysis tool (http://www.andyhsoftware.co.uk/space)

[VK]

Any name has to start with a letter and consist of any combination of
letters, numbers and underscores to the total length of 255 characters.
(Where the "letter" means any character from the a-z, A-Z range)
This is a vary basic of any programming language including JavaScript.
Otherwise you are on the merci of a particular system (browser) - will it
eat your wrong names or not.

Phil Powell <so*****@erols.com> wrote in message
news:1c**************************@posting.google.c om...

<b>Agency 4</b>
<input type="radio" name="permission[4]" value="1" checked> Yes
<input type="radio" name="permission[4]" value="0" > No
<br>
<b>Agency 5</b>
<input type="radio" name="permission[5]" value="1" checked> Yes
<input type="radio" name="permission[5]" value="0" > No
<br>
I have it set up this way but upon viewing in the browser none of the
radio buttons appear checked.

By the way the radio button names MUST remain in the PHP array format
as they will be referenced EXACTLY like that by PHP on the server end.
Sorry can't change that.

What can I do?

Phil

[Andy Hassall]

On Wed, 1 Oct 2003 01:02:33 +0200, "VK" <sc**********@yahoo.com> wrote:

Phil Powell <so*****@erols.com> wrote in message
news:1c**************************@posting.google. com...

<b>Agency 4</b>
<input type="radio" name="permission[4]" value="1" checked> Yes
<input type="radio" name="permission[4]" value="0" > No
<br>
<b>Agency 5</b>
<input type="radio" name="permission[5]" value="1" checked> Yes
<input type="radio" name="permission[5]" value="0" > No
<br>

I have it set up this way but upon viewing in the browser none of the
radio buttons appear checked.

By the way the radio button names MUST remain in the PHP array format
as they will be referenced EXACTLY like that by PHP on the server end.
Sorry can't change that.
Any name has to start with a letter and consist of any combination of
letters, numbers and underscores to the total length of 255 characters.
(Where the "letter" means any character from the a-z, A-Z range)

Not true, see below.
This is a vary basic of any programming language including JavaScript.
Otherwise you are on the merci of a particular system (browser) - will it
eat your wrong names or not.

permission[4] is a valid value for the name attribute of the <input> element,
as described in the HTML specification.

The input element's name attribute is of type CDATA with no further
restrictions defined by the specification.

The last discussion I remember of this ended up with these messages:
(very long URL - your newsreader may wrap it)

http://groups.google.co.uk/groups?hl...r%3D%26hl%3Den

The message linked says [] in an input name is invalid, the replies disprove
this.

Individual languages may have trouble with non-alphabetic characters as part
of a name attribute, but it's valid HTML and so should really be possible to
deal with it in any language working with HTML.

(BTW I'm not sure why this is posted to either of the PHP or JavaScript
newsgroups, since the only posted content is in valid HTML)

--
Andy Hassall (an**@andyh.co.uk) icq(5747695) (http://www.andyh.co.uk)
Space: disk usage analysis tool (http://www.andyhsoftware.co.uk/space)

[Geoff Berrow]

I noticed that Message-ID: <3f***********************@news.freenet.de>
from VK contained the following:

Any name has to start with a letter and consist of any combination of
letters, numbers and underscores to the total length of 255 characters.
(Where the "letter" means any character from the a-z, A-Z range)
This is a vary basic of any programming language including JavaScript.
Otherwise you are on the merci of a particular system (browser) - will it
eat your wrong names or not.

Wish I'd read that earlier. I spent three hours today trying to figure
out a simple javascript problem until I figured out I could not call my
checkboxes 1,2,3, etc

--
Geoff Berrow
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

[Richard Cornford]

"Andy Hassall" <an**@andyh.co.uk> wrote in message
news:n6********************************@4ax.com...

On Wed, 1 Oct 2003 01:02:33 +0200, "VK" <sc**********@yahoo.com> wrote:
<snip>

Any name has to start with a letter and consist of any
combination of letters, numbers and underscores to the
total length of 255 characters. (Where the "letter" means
any character from the a-z, A-Z range)

Not true, see below.

<snip>
The message linked says [] in an input name is invalid, the
replies disprove this.
I don't think that the discussion that you referenced does prove the
general suggestion that [ and ] are invalid in HTML 4 name attribute
strings is incorrect. If I look at the HTM versions of the DTDs I find
that the Name attributes are described as CDATA and the term CDATA is
linked to:-

<quote cite="http://www.w3.org/TR/html4/types.html#type-cdata">
....
For some HTML 4 attributes with CDATA attribute values, the
specification imposes further constraints on the set of legal values for
the attribute that may not be expressed by the DTD.
....

ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
followed by any number of letters, digits ([0-9]), hyphens ("-"),
underscores ("_"), colons (":"), and periods (".").
....
</quote>

- which is part of the HTML 4 specification and "imposes further
constraints" on the contents of name attribute strings beyond the normal
definition of CDATA.
Individual languages may have trouble with non-alphabetic
characters as part of a name attribute, but it's valid HTML
and so should really be possible to deal with it in any
language working with HTML.

Valid HTML or not, JavaScript can access properties with names that do
not represent valid identifiers in JavaScript by using square bracket
notation instead of dot notation:-

<URL: http://jibbering.com/faq/#FAQ4_25 >
-and-
<URL: http://jibbering.com/faq/#FAQ4_39 >

Richard.

[Andy Hassall]

On Wed, 1 Oct 2003 01:35:37 +0100, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote:

"Andy Hassall" <an**@andyh.co.uk> wrote in message
news:n6********************************@4ax.com.. .

On Wed, 1 Oct 2003 01:02:33 +0200, "VK" <sc**********@yahoo.com>wrote:
<snip>

Any name has to start with a letter and consist of any
combination of letters, numbers and underscores to the
total length of 255 characters. (Where the "letter" means
any character from the a-z, A-Z range)

Not true, see below.

<snip>

The message linked says [] in an input name is invalid, the
replies disprove this.

I don't think that the discussion that you referenced does prove the
general suggestion that [ and ] are invalid in HTML 4 name attribute
strings is incorrect. If I look at the HTM versions of the DTDs I find
that the Name attributes are described as CDATA and the term CDATA is
linked to:-

<quote cite="http://www.w3.org/TR/html4/types.html#type-cdata">
...
For some HTML 4 attributes with CDATA attribute values, the
specification imposes further constraints on the set of legal values for
the attribute that may not be expressed by the DTD.
...

ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
followed by any number of letters, digits ([0-9]), hyphens ("-"),
underscores ("_"), colons (":"), and periods (".").

The name attribute of input is not one of the ID or NAME types, so that
restriction doesn't apply.

There are attributes that are declared as ID or NAME; input's name attribute
is not one of them.
...
</quote>

- which is part of the HTML 4 specification and "imposes further
constraints" on the contents of name attribute strings beyond the normal
definition of CDATA.

No, the restriction on the NAME and ID types don't apply to the CDATA type.

Quoting the whole lot:

"
* CDATA is a sequence of characters from the document character set and may
include character entities. User agents should interpret attribute values as
follows:
Replace character entities with characters,
Ignore line feeds,
Replace each carriage return or tab with a single space.
User agents may ignore leading and trailing white space in CDATA attribute
values (e.g., " myval " may be interpreted as "myval"). Authors should not
declare attribute values with leading or trailing white space.

For some HTML 4 attributes with CDATA attribute values, the specification
imposes further constraints on the set of legal values for the attribute that
may not be expressed by the DTD.

Although the STYLE and SCRIPT elements use CDATA for their data model, for
these elements, CDATA must be handled differently by user agents. Markup and
entities must be treated as raw text and passed to the application as is. The
first occurrence of the character sequence "</" (end-tag open delimiter) is
treated as terminating the end of the element's content. In valid documents,
this would be the end tag for the element.

* ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by
any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons
(":"), and periods (".").

* IDREF and IDREFS are references to ID tokens defined by other attributes.
IDREF is a single token and IDREFS is a space-separated list of tokens.

* NUMBER tokens must contain at least one digit ([0-9]).
"

So, it's saying that if you look through the specification on some of the
attributes that are of CDATA type, there are then further notes on restrictions
not expressed by it being of type CDATA.

There are no further restrictions listed for input's name attribute that I can
find - if you can see one please post it!

There then follows descriptions of the ID, NAME, IDREF, IDREFS and NUMBER
types; none of which are CDATA, they're separate types.

For example:

http://www.w3.org/TR/html4/struct/li...ml#adef-name-A

The name attribute of the <a> tag is of type CDATA, but it says here that it
is restricted to the namespace of the id attribute, which is of type 'name'.

That's a "further constraint on the set of legal values for the attribute that
may not be expressed by the DTD"

Individual languages may have trouble with non-alphabetic
characters as part of a name attribute, but it's valid HTML
and so should really be possible to deal with it in any
language working with HTML.

Valid HTML or not, JavaScript can access properties with names that do
not represent valid identifiers in JavaScript by using square bracket
notation instead of dot notation:-

<URL: http://jibbering.com/faq/#FAQ4_25 >
-and-
<URL: http://jibbering.com/faq/#FAQ4_39 >

Sounds good.

--
Andy Hassall (an**@andyh.co.uk) icq(5747695) (http://www.andyh.co.uk)
Space: disk usage analysis tool (http://www.andyhsoftware.co.uk/space)

[Richard Cornford]

"Andy Hassall" <an**@andyh.co.uk> wrote in message
news:od********************************@4ax.com...
<snip>

No, the restriction on the NAME and ID types don't apply to
the CDATA type.

<snip>

Looking at it again I think you are right. Looking at the HTML source of
types.html made it clear that CDATA (and notes related to it) is/are
separate from NAME and ID (separate LI elements) and the additional
restrictions on NAME and ID do not apply. Interesting to see semantic
mark-up actually providing additional clarity.

Richard.

[Geoff Berrow]

I noticed that Message-ID: <od********************************@4ax.com>
from Andy Hassall contained the following:

ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
followed by any number of letters, digits ([0-9]), hyphens ("-"),
underscores ("_"), colons (":"), and periods (".").

The name attribute of input is not one of the ID or NAME types, so that
restriction doesn't apply.

There are attributes that are declared as ID or NAME; input's name attribute
is not one of them.

You lost me with most of this, but I thought I'd show you the little
problem I had today

This doesn't work

<SCRIPT LANGUAGE="JavaScript" type="text/javascript">
function checkOne(j) {
box = eval("document.form1." + j);
if (box.checked == false) box.checked = true;
}
</SCRIPT>

<td><select name=\"select".$i."\" onChange=\"checkOne(".$i.")\">

(where $i is a number)

But this does:

<SCRIPT LANGUAGE="JavaScript" type="text/javascript">
function checkOne(j) {
box = eval("document.form1.C" + j);
if (box.checked == false) box.checked = true;
}
</SCRIPT>

where I preface the checkbox name with a C

--
Geoff Berrow
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

[HikksNotAtHome]

In article <aa********************************@4ax.com>, Geoff Berrow
<[e-mail]> writes:

<SCRIPT LANGUAGE="JavaScript" type="text/javascript">
function checkOne(j) {
box = eval("document.form1.C" + j);

box = document.form1.elements["C" + j];

No need for eval, as the link Richard provided explains:

http://jibbering.com/faq/#FAQ4_39

and

http://jibbering.com/faq/#FAQ4_40

with regards to eval itself.

--
Randy

[Lasse Reichstein Nielsen]

Andy Hassall <an**@andyh.co.uk> writes:

The name attribute of input is not one of the ID or NAME types, so that
restriction doesn't apply.

There are attributes that are declared as ID or NAME; input's name attribute
is not one of them.
You seem to be correct.

Checking the DTD of HTML 4.01, only the id attribute is ID, and only
two attributes of the meta tag and the type %Lanuagecode are NAME.

The only thing that bothers me a bit is this:
<URL:http://www.w3.org/TR/html4/struct/global.html#adef-id>
where the id attribute is declared as a (lowercase) "name", which linkes
to <URL:http://www.w3.org/TR/html4/types.html#type-name> (the paragraph on
ID and NAME tokens). According to the DTD, the id should be an ID.
Hmm, I also stubmled over this paragraph:

--- <URL:http://www.w3.org/TR/html4/struct/links.html#anchors-with-id> ---
The id and name attributes share the same name space. This means that
they cannot both define an anchor with the same name in the same
document. It is permissible to use both attributes to specify an
element's unique identifier for the following elements: A, APPLET,
FORM, FRAME, IFRAME, IMG, and MAP. When both attributes are used on a
single element, their values must be identical.
---

I can't read with absolute certainty whether this restriction is only
on the mentioned elements, and id and name can be distinct on other
elements, but I believe it is only for those mentioned. These elements
are the ones that are represented in Javascript in global collections,
(document.{links,anchors,applets,forms,images}, and window.frames),
so they should be globally unique. Comments?
http://www.w3.org/TR/html4/struct/li...ml#adef-name-A

The name attribute of the <a> tag is of type CDATA, but it says here that it
is restricted to the namespace of the id attribute, which is of type 'name'.

I don't read it as saying the CDATA is *restricted* to the name space
of the id attribute. It says
"Note that this attribute shares the same name space as the id attribute."
Sharing a name space just means that an id attribute and a name attribute
with the same value will conflict, and it isn't allowed.

I can't see anything that prevents the name attribute from containing
characters not possible in an id attribute In fact, in the same
section as the above quote, they explicitly mentions "D&uuml;rst" as a
legal name attribute value for an anchor.
Thanks for pointing this out. I always like to get smarter :)
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

[De.Snor]

On 30 Sep 2003 13:41:13 -0700, so*****@erols.com (Phil Powell) wrote:

<b>Agency 4</b>
<input type="radio" name="permission[4]" value="1" checked> Yes
<input type="radio" name="permission[4]" value="0" > No
<br>
<b>Agency 5</b>
<input type="radio" name="permission[5]" value="1" checked> Yes
<input type="radio" name="permission[5]" value="0" > No
<br>
I have it set up this way but upon viewing in the browser none of the
radio buttons appear checked.

By the way the radio button names MUST remain in the PHP array format
as they will be referenced EXACTLY like that by PHP on the server end.
Sorry can't change that.

What can I do?

If jou'r using XHTML1 jou have to change
checked
into
checked="checked"

--
Greetz,
De Snor

[VK]

The naming confusion stays on the fact that smart guys in 3W have forgotten
of the dual nature of named page elements (forms, form elements, divs etc.)
If browser supports JavaScript, each named element is being AUTOMATICALLY
added to the corresponding JavaScript array (document.forms[],
document.forms[x].elements[] etc.) on page load.
So each name is not just a name, but a potential JavaScript variable. So it
has to follow the JavaScript naming scheme. Otherwise JavaScript fails to
register the element in an array, which invalidates the element for
scripting.

I have no time for further research, but I bet my coffee against your sugar:
If you disallow JavaScript in your browser, it will eat CDATA names with no
problem.
De.Snor <de*****@xs4all.nl> wrote in message
news:0g********************************@4ax.com...

On 30 Sep 2003 13:41:13 -0700, so*****@erols.com (Phil Powell) wrote:

<b>Agency 4</b>
<input type="radio" name="permission[4]" value="1" checked> Yes
<input type="radio" name="permission[4]" value="0" > No
<br>
<b>Agency 5</b>
<input type="radio" name="permission[5]" value="1" checked> Yes
<input type="radio" name="permission[5]" value="0" > No
<br>
I have it set up this way but upon viewing in the browser none of the
radio buttons appear checked.

By the way the radio button names MUST remain in the PHP array format
as they will be referenced EXACTLY like that by PHP on the server end.
Sorry can't change that.

What can I do?

If jou'r using XHTML1 jou have to change
checked
into
checked="checked"

--
Greetz,
De Snor

[Lasse Reichstein Nielsen]

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

The naming confusion stays on the fact that smart guys in 3W have forgotten
of the dual nature of named page elements (forms, form elements, divs etc.)
If browser supports JavaScript, each named element is being AUTOMATICALLY
added to the corresponding JavaScript array (document.forms[],
document.forms[x].elements[] etc.) on page load.
Maybe they haven't forgotten it. Maybe they never considered it.
Javascript, or other script languages (and there are plenty that *can*
be embedded in a web page), are separate from HTML. They need not, and
should not, affect the specification of HTML (IMNSHO).
So each name is not just a name, but a potential JavaScript variable.
Not a variable. A property. That is a *big* difference, since any
string can be used as a property name.
So it has to follow the JavaScript naming scheme. Otherwise
JavaScript fails to register the element in an array, which
invalidates the element for scripting.
Not at all.

This works in Mozilla and Opera (and fails in IE6 even if the name is
as simple as "aa").
---
<a name="DX &uuml;t" href="test.html">FooM</a>
<script type="text/javascript">
alert(document.links["DX üt"].href);
</script>
---
The W3C-DOM method version works in both of these and in IE6:
---
<a name="DX &uuml;t" href="test.html">FooM</a>
<script type="text/javascript">
alert(document.links.namedItem("DX üt").href);
</script>
---
IE apparently doesn't follow the W3C DOM 2 HTML recommendation (but we
knew that).
I have no time for further research, but I bet my coffee against your sugar:
If you disallow JavaScript in your browser, it will eat CDATA names with no
problem.

It will with Javascript too.

(And yes, until eariler today, I though "foo[2]" was an illegal name
attribute value in HTML, but it seems it is not.)
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

[VK]

Sometimes you are doing things right w/o analyzing why it's right, you just
feel that. All these years I followed the naming rule I spelled in the
original posting, no matter what language I was working with. And as a
reward I never had any problems with identifiers' names. (I had a bunch of
other problems of course :-)
This discussion got me so exited that I took some books from the dustiest
corner of my shelve.
So...

JavaScript and JScript are both built on ECMA-262 language specifications,
approved as international standard ISO/IEC 16262. The official name for both
languages is ECMAScript (in the standardization papers).
The latest ECMA-262 specs can be obtained at www.ecma.ch
ECMA-262, Version 3 Final, paragraph 7.6:

Identifiers are interpreted according to the grammar given in Section 5.16
of the upcoming version 3.0 of the Unicode standard, with some small
modifications. This grammar is based on both normative and informative
character categories specified by the Unicode standard. The characters in
the specified categories in version 2.1 of the Unicode standard must be
treated as in those categories by all conforming ECMAScript implementations;
however, conforming ECMAScript implementations may allow additional legal
identifier characters based on the category assignment from later versions
of Unicode.
This standard specifies one departure from the grammar given in the Unicode
standard: The dollar sign ($) and the underscore (_) are permitted anywhere
in an identifier. The dollar sign is intended for use only in mechanically
generated code.
Unicode escape sequences are also permitted in identifiers, where they
contribute a single character to the identifier, as computed by the CV of
the UnicodeEscapeSequence (see section 7.8.4). The \ preceding the
UnicodeEscapeSequence does not contribute a character to the identifier. A
UnicodeEscapeSequence cannot be used to put a character into an identifier
that would otherwise be illegal. In other words, if a \
UnicodeEscapeSequence sequence were replaced by its UnicodeEscapeSequence's
CV, the result must still be a valid Identifier that has the exact same
sequence of characters as the original Identifier.
Two identifiers that are canonically equivalent according to the Unicode
standard are not equal unless they are represented by the exact same
sequence of code points (in other words, conforming ECMAScript
implementations are only required to do bitwise comparison on identifiers).
The intent is that the incoming source text has been converted to normalised
form C before it reaches the compiler.
Conclusion:
"1", "something[0]" and similar are not valid identifiers and cannot be used
for naming of variables, objects, methods and properties within the script.

Even if a particular browser allows the use of such identifiers in violation
of the ISO standards, programmer should avoid them to keep his/her code
compatible with other platforms.

Lasse Reichstein Nielsen <lr*@hotpop.com> wrote in message
news:65**********@hotpop.com...

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

The naming confusion stays on the fact that smart guys in 3W have forgotten of the dual nature of named page elements (forms, form elements, divs etc.) If browser supports JavaScript, each named element is being AUTOMATICALLY added to the corresponding JavaScript array (document.forms[],
document.forms[x].elements[] etc.) on page load.

Maybe they haven't forgotten it. Maybe they never considered it.
Javascript, or other script languages (and there are plenty that *can*
be embedded in a web page), are separate from HTML. They need not, and
should not, affect the specification of HTML (IMNSHO).

So each name is not just a name, but a potential JavaScript variable.

Not a variable. A property. That is a *big* difference, since any
string can be used as a property name.

So it has to follow the JavaScript naming scheme. Otherwise
JavaScript fails to register the element in an array, which
invalidates the element for scripting.

Not at all.

This works in Mozilla and Opera (and fails in IE6 even if the name is
as simple as "aa").
---
<a name="DX &uuml;t" href="test.html">FooM</a>
<script type="text/javascript">
alert(document.links["DX üt"].href);
</script>
---
The W3C-DOM method version works in both of these and in IE6:
---
<a name="DX &uuml;t" href="test.html">FooM</a>
<script type="text/javascript">
alert(document.links.namedItem("DX üt").href);
</script>
---
IE apparently doesn't follow the W3C DOM 2 HTML recommendation (but we
knew that).

I have no time for further research, but I bet my coffee against your sugar: If you disallow JavaScript in your browser, it will eat CDATA names with no problem.

It will with Javascript too.

(And yes, until eariler today, I though "foo[2]" was an illegal name
attribute value in HTML, but it seems it is not.)
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

[Richard Cornford]

"VK" <sc**********@yahoo.com> wrote in message
news:3f***********************@news.freenet.de...
<snip>
and JScript are both built on ECMA-262 language

specifications, approved as international standard ISO/IEC 16262. ... <snip>ECMA-262, Version 3 Final, paragraph 7.6:

Identifiers are interpreted according to the grammar given in
Section 5.16 of the upcoming version 3.0 of the Unicode standard,
with some small modifications. ... <snip>This standard specifies one departure from the grammar given in
the Unicode standard: The dollar sign ($) and the underscore
(_) are permitted anywhere in an identifier. The dollar sign is
intended for use only in mechanically generated code.
... <snip>
Conclusion:
"1", "something[0]" and similar are not valid identifiers and
cannot be used for naming of variables, objects, methods and
properties within the script. Even if a particular browser allows the use of such identifiers
in violation of the ISO standards, programmer should avoid them
to keep his/her code compatible with other platforms.

ECMA 262 Section 7.6 describes the rules that apply whenever the
production - Identifier - is used. However, Section 11.2.1 (Property
Accessors) includes the productions (for bracket notation):-

MemeberExpression [ Expression ]
- and -
CallExpression [ Expression ]

- and the algorithm for resolving these property accessors is:-

<quote cite="ECMA 262 3rd Edition Section 11.2.1 Property Accessors">
....
The production MemberExpression : MemberExpression [ Expression ] is
evaluated as follows:

1. Evaluate MemberExpression.
2. Call GetValue(Result(1)).
3. Evaluate Expression.
4. Call GetValue(Result(3)).
5. Call ToObject(Result(2)).
6. Call ToString(Result(4)).
7. Return a value of type Reference whose base object is
Result(5) and whose property name is Result(6).

The production CallExpression : CallExpression [ Expression ] is
evaluated in exactly the same manner, except that the contained
CallExpression is evaluated in step 1.
</quote>

The result of the - Expression - is used as the property name and the
algorithm does not require that string to conform to the rules for -
Identifier - (it doesn't even check).

So, while production rules that resolve to - Identifier - should produce
errors if the character sequence used does not conform to the rules for
Identifier, ECMA Script does allow properties to be created and read
with _any_ name. If the name does not conform to the rules for
Identifier then it is necessary to use bracket notation to access the
property as that side steps the rules for Identifier.

Therefor a conforming ECMA Script implementation must allow properties
to be created and accessed by _any_ name.

And this is a good thing as even the erroneous interpretation of HTML
CDATA attribute values that attempted to place the NAME and ID
restrictions upon them still allowed character that would not be allowed
in an ECMA Script identifier.

The point at which HTML naming is restricted by the desire to script is
when the attribute values represent integer numbers, but that is more a
consequence of the DOM implementation than ECMA Script as HTML
collections make nodes available as both named properties and as integer
indexed members. So an attempt to read a property of a collection that
is named as an integer number stands a very good chance of returning the
wrong node (or just confusing the DOM implementation).

On the whole, it must be easier to side step the issue by assigning
values to HTML name and ID attributes that are also valid ECMA script
identifiers (indeed that would be the natural thing to do under most
circumstances) but when that is not possible ECMA script is quite
capable of coping with the results (at least under all realistic
circumstances).

Richard.

[Dr John Stockton]

JRS: In article <aa********************************@4ax.com>, seen in
news:comp.lang.javascript, Geoff Berrow <[e-mail]> posted
at Wed, 1 Oct 2003 03:24:10 :-

if (box.checked == false) box.checked = true;

Unless you feel that false might have been redefined, there is no need
to compare with false; there is a NOT operator.

if (!box.checked) box.checked = true;

There may be no need to test that it is not checked before checking it.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.

[Geoff Berrow]

I noticed that Message-ID: <72**************@merlyn.demon.co.uk> from Dr
John Stockton contained the following:

if (box.checked == false) box.checked = true;

Unless you feel that false might have been redefined, there is no need
to compare with false; there is a NOT operator.

if (!box.checked) box.checked = true;

There may be no need to test that it is not checked before checking it.

Well that's what you get for nicking bits of code. ;-)

Honestly John, that problem drove me up the wall - I was just happy to
get it working. I had my own code (probably equally as bad) but
scrapped it for something I found on the 'net to get it working. I
guess my own would have worked had I figured out the error.

--
Geoff Berrow
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

[VK]

We went deep to the jungles of the abstract programming.
I'm afraid only ECMA/ISO guys (or a 3rd-4th grade Computer Science student
who's forced to remember this stuff) would be capable to finalize the
discussion.

I personally don't see what you see in the 11.2.1 of ECMA specs.
IMHO it just says that the Object.Property construct can be presented
in two ways (or a combination of both):
by literals: ObjectName.PropertyName
by expressions: (ExpressionForObjectName)[ExpressionForPropertyName]

The same paragraph states that the final result of evaluation in both cases
is an Identifier (I read: "ECMA-compliant identifier"). No mentions anywhere
that such identifier would have more format freedom
than any other identifier.

I still think that 3W did a big boo-boo. Trying to satisfy the wildest
naming desires in their DOM/XML models, they neglected the fact that all
this data
will be inevitable treated by some programming language
(PHP, ASP-VScript, Perl, Java, JavaScript etc.)
based on the much more conservative ISO standards.

IMHO it didn't blow up yet just because of some healthy conservatism
of the programmers' community. If you did programming long enough,
it takes some guts and a good shoot of whisky to create an object
_$$_\u0410\u041E_
with a property \041F$$_$
But I'm expecting a lot of fun later when programmers will become more dare
and will try to fully use the given naming freedom.
Still would be interesting to know the Final Right Answer...

ECMA 262 Section 7.6 describes the rules that apply whenever the
production - Identifier - is used. However, Section 11.2.1 (Property
Accessors) includes the productions (for bracket notation):-

MemeberExpression [ Expression ]
- and -
CallExpression [ Expression ]

- and the algorithm for resolving these property accessors is:-

<quote cite="ECMA 262 3rd Edition Section 11.2.1 Property Accessors">
...
The production MemberExpression : MemberExpression [ Expression ] is
evaluated as follows:

1. Evaluate MemberExpression.
2. Call GetValue(Result(1)).
3. Evaluate Expression.
4. Call GetValue(Result(3)).
5. Call ToObject(Result(2)).
6. Call ToString(Result(4)).
7. Return a value of type Reference whose base object is
Result(5) and whose property name is Result(6).

The production CallExpression : CallExpression [ Expression ] is
evaluated in exactly the same manner, except that the contained
CallExpression is evaluated in step 1.
</quote>

The result of the - Expression - is used as the property name and the
algorithm does not require that string to conform to the rules for -
Identifier - (it doesn't even check).

So, while production rules that resolve to - Identifier - should produce
errors if the character sequence used does not conform to the rules for
Identifier, ECMA Script does allow properties to be created and read
with _any_ name. If the name does not conform to the rules for
Identifier then it is necessary to use bracket notation to access the
property as that side steps the rules for Identifier.

Therefor a conforming ECMA Script implementation must allow properties
to be created and accessed by _any_ name.

And this is a good thing as even the erroneous interpretation of HTML
CDATA attribute values that attempted to place the NAME and ID
restrictions upon them still allowed character that would not be allowed
in an ECMA Script identifier.

The point at which HTML naming is restricted by the desire to script is
when the attribute values represent integer numbers, but that is more a
consequence of the DOM implementation than ECMA Script as HTML
collections make nodes available as both named properties and as integer
indexed members. So an attempt to read a property of a collection that
is named as an integer number stands a very good chance of returning the
wrong node (or just confusing the DOM implementation).

On the whole, it must be easier to side step the issue by assigning
values to HTML name and ID attributes that are also valid ECMA script
identifiers (indeed that would be the natural thing to do under most
circumstances) but when that is not possible ECMA script is quite
capable of coping with the results (at least under all realistic
circumstances).

Richard.

[Richard Cornford]

"VK" <sc**********@yahoo.com> wrote in message
news:3f***********************@news.freenet.de...

We went deep to the jungles of the abstract programming.
I'm afraid only ECMA/ISO guys (or a 3rd-4th grade Computer
Science student who's forced to remember this stuff) would
be capable to finalize the discussion. I personally don't see what you see in the 11.2.1 of ECMA specs.
IMHO it just says that the Object.Property construct can be
presented in two ways (or a combination of both):
by literals: ObjectName.PropertyName
by expressions: (ExpressionForObjectName)[ExpressionForPropertyName] The same paragraph states that the final result of evaluation in
both cases is an Identifier (I read: "ECMA-compliant identifier").
The ECMA Script algorithm states that the final result of the Expression
used in bracket notation is a string representing a property name. I
suspect that you are being confused by the part of Section 11.2.1 that
reads:-

<quote cite="ECMA 262 3rd Edition Section 11.2.1 Property Accessors">
....
The dot notation is explained by the following syntactic conversion:

MemberExpression . Identifier

is identical in its behaviour to

MemberExpression [ <identifier-string> ]

and similarly

CallExpression . Identifier

is identical in its behaviour to

CallExpression [ <identifier-string> ]

where <identifier-string> is a string literal containing
the same sequence of characters as the Identifier.
....
</quote>

However, this does not mean that the Expression used in bracket notation
must follow the restrictions imposed on Identifier. It states that if
the Expression in a bracket notation property accessor resolves to the
same character sequence used for the Identifier in a dot notation
accessor then the behaviour of the two would be identical.

Because dot notation requires an Identifier to appear to the right of
the dot a property that can be accessed by dot notation must have a name
that satisfies the Identifier rules. That is a syntax rule imposed on
ECMA Script source code, but property access itself is governed by the
algorithm stated in Section 11.2.1 and that algorithm does not impose
any restrictions on the character sequence used.
No mentions anywhere that such identifier would have more
format freedom than any other identifier. <snip>

Section 11.2.1 defines Property Accessors not Identifiers, and places no
restrictions on the character sequence that can be used in a property
name. Dot notation is subject to the rules for Identifier because its
production directly employs the Identifier production, bracket notation
does not draw on the Identifier production so it is only subject to the
rules for Property Accessors; the Expression may result in _any_
character sequence.
Still would be interesting to know the Final Right Answer...

The Property Accessor algorithm is the correct and final answer to the
question of what character sequences may be used as property names in
ECMA Script. It is possible (even probable) that implementations place
some additional restrictions on property names, such as their maximum
length, but ECMA Script does not.

Richard.

[Lasse Reichstein Nielsen]

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

I'm afraid only ECMA/ISO guys (or a 3rd-4th grade Computer Science student
who's forced to remember this stuff) would be capable to finalize the
discussion.
I think I qualify. I'm might not be forced to remember it, but I'm way
past 4th grade computer science :)
I personally don't see what you see in the 11.2.1 of ECMA specs.
IMHO it just says that the Object.Property construct can be presented
in two ways (or a combination of both):
by literals: ObjectName.PropertyName
by expressions: (ExpressionForObjectName)[ExpressionForPropertyName]
It says the
memberExpression.Identifier
is evaluated just as
MemberExpression[<identifierString>]
where <identifierString> is a string literal containing the string
corresponding to the identifier. This only goes one way. That part makes
no statements about how MemberExpression[Expression] is in fact evaluated.
That comes right after.
The same paragraph states that the final result of evaluation in both cases
is an Identifier (I read: "ECMA-compliant identifier").
In ECMA 262, version 3 final (24. March 2000), section 11.2.1? I can't
see that. In fact, there seems to be no occurances of either
"ECMA-compliant" or "compliant identifier".

What I can see is the evaluation of MemberExpression[Expression]:
---
1. Evaluate MemberExpression.
2. Call GetValue(Result(1)).
3. Evaluate Expression.
4. Call GetValue(Result(3)).
5. Call ToObject(Result(2)).
6. Call ToString(Result(4)).
7. Return a value of type Reference whose base object is Result(5) and
whose property name is Result(6).
---

There is nothing in this definition that prevents Result(6) from being
any string. In fact, since Expression can be a string literal, any
string that has a literal represnetation (they all do) can be used
as a property name.

Looking through ECMA 262 (the one from 1999, not the final version, I
can't stand to read the sans-serif font!) I can't see any definition
of what a legal property name is. What I can see is, as above, that
any string will work, and that anything used as a property will be
converted to a string, so property names are probably strings.
It's not specified explicitly, though. I would call that an oversight,
considering how much detail they go into in other cases.
I still think that 3W did a big boo-boo. Trying to satisfy the wildest
naming desires in their DOM/XML models, they neglected the fact that all
this data will be inevitable treated by some programming language
(PHP, ASP-VScript, Perl, Java, JavaScript etc.)
based on the much more conservative ISO standards.

Not a problem. All collections will have a "namedItem" method that can
be used with a language level string as an argument.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'