name reference

This code does not working in Mozilla. Works fine in IE.
--------------
<input type=text value=100 name=textbox>
<script>
alert(textbox);
</script>
--------------
This perhaps, because of Microsoft policy to globalize all tag names.

Is there any method for cross-browser fix without using getelementbyid?
Is there any method to pass values from outside of <script>, inside?
(something like "global" in php functions)
Javascript must be kept inside <script> tag

re: name reference

Chameleon wrote:[color=blue]
> This code does not working in Mozilla. Works fine in IE....
> Is there any method for cross-browser fix without using getelementbyid?[/color]

You'll want to wrap the input in a form tag with a name, then access it
through the document object. Something like...

<form name=aform>
<input type=text value=100 name=textbox>
</form>
<script>
alert(document.aform.textbox);
</script>

re: name reference

Hi,

getElementById is really the preferred way, but for older browsers you
can use:

alert( document.forms[0].elements['textbox'].value );

but you need to wrap your input fields with <form></form>, and the code
above assumes you only have one <form></form> in the page.

There is a downside to having <form></form>, when user presses ENTER on
an input field (e.g. text box), the browser would try to submit the
form, so you'd need to handle this as well.

I won't discuss this here as I have no time, but have a look at
www.quirksmode.org, it has very good articles about cross-browsers
javascript event handling which will help in solving this problem
(e.g.: detect if ENTER key is pressed in an input field, and ignore it
so the browser doesn't try to submit the form).

I created a function for selecting input field that looks like (I don't
have it with me so this is just on top of my head):

function get_field_object(id)
{
// if browser supports getElementById
if( document.getElementById )
return document.getElementById(id);
else
return document.forms[0].elements[id];
}

then use it like:

<script>
var t = get_field_object("textbox");

// if object is valid
if( t )
alert( t.value );
else
alert('Couldnt find object.');
</script>

I hope that helps a bit.

Kind Regards,

Sid
http://www.onlinesid.com/blogs

re: name reference

Chameleon wrote :[color=blue]
> This code does not working in Mozilla. Works fine in IE.
> --------------
> <input type=text value=100 name=textbox>
> <script>
> alert(textbox);
> </script>
> --------------
> This perhaps, because of Microsoft policy to globalize all tag names.
>
> Is there any method for cross-browser fix without using getelementbyid?
> Is there any method to pass values from outside of <script>, inside?
> (something like "global" in php functions)
> Javascript must be kept inside <script> tag[/color]


Using Web Standards in Your Web Pages
Accessing Elements with the W3C DOM
http://www.mozilla.org/docs/web-deve...tml#dom_access

explains it all.

Ge'rard
--
remove blah to email me

re: name reference

Crazy Code Ninja wrote:[color=blue]
> getElementById is really the preferred way[/color]

Not really. Then you need to generate a unique ID for each input field and
add bloat to your page.
[color=blue]
> alert( document.forms[0].elements['textbox'].value );
> but you need to wrap your input fields with <form></form>[/color]

which you need to do anyway to create valid html.
[color=blue]
>, and the
> code above assumes you only have one <form></form> in the page.[/color]

Which is a bad practice. Use form names instead of indexes.

For more info, see http://www.JavascriptToolbox.com/bestpractices/

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

re: name reference

Matt Kruse said on 16/03/2006 11:07 AM AEST:[color=blue]
> Crazy Code Ninja wrote:[/color]
[...][color=blue]
>[color=green]
>>alert( document.forms[0].elements['textbox'].value );
>>but you need to wrap your input fields with <form></form>[/color]
>
>
> which you need to do anyway to create valid html.[/color]

Not at all - there is no requirement for input elements to be inside
form elements. They can appear anywhere in the body that an inline
element can appear.


--
Rob

re: name reference

Right, I should have said its my preferred way from my experience.

Having said that, I still think it's not good if you have several input
fields with the same ID. If you have that many input fields in one page
that you have difficulty in not having unique IDs for each of them,
then its a sure sign that you should have split your page.

IDs should be unique, unlike class names. It will make maintenance
easier, server side scripting wise, CSS wise, as well as Javascript
wise.
[color=blue][color=green]
> >, and the
> > code above assumes you only have one <form></form> in the page.[/color]
>
> Which is a bad practice. Use form names instead of indexes.[/color]

I was just warning him about my (quick crude simple) example, that it
assumes he has only one form.



Matt Kruse wrote:[color=blue]
> Crazy Code Ninja wrote:[color=green]
> > getElementById is really the preferred way[/color]
>
> Not really. Then you need to generate a unique ID for each input field and
> add bloat to your page.
>[color=green]
> > alert( document.forms[0].elements['textbox'].value );
> > but you need to wrap your input fields with <form></form>[/color]
>
> which you need to do anyway to create valid html.
>[color=green]
> >, and the
> > code above assumes you only have one <form></form> in the page.[/color]
>
> Which is a bad practice. Use form names instead of indexes.
>
> For more info, see http://www.JavascriptToolbox.com/bestpractices/
>
> --
> Matt Kruse[/color]

re: name reference

Matt Kruse wrote :[color=blue]
> Crazy Code Ninja wrote:[color=green]
>> getElementById is really the preferred way[/color]
>
> Not really. Then you need to generate a unique ID for each input field[/color]


This is exactly what the HTML 4.01 recommendation says, btw:
"Applications should use the id attribute to identify elements."
http://www.w3.org/TR/html401/interac...adef-name-FORM

and[color=blue]
> add bloat to your page.
>[color=green]
>> alert( document.forms[0].elements['textbox'].value );
>> but you need to wrap your input fields with <form></form>[/color]
>
> which you need to do anyway to create valid html.
>[/color]

Not at all, as pointed out Rob.
[color=blue][color=green]
>> , and the
>> code above assumes you only have one <form></form> in the page.[/color]
>
> Which is a bad practice. Use form names instead of indexes.[/color]


As I pointed to you before, name attribute has been formally deprecated
in XHTML 1.0.
"in XHTML 1.0, the name attribute of these elements (a, applet, form,
frame, iframe, img, and map) is formally deprecated"
http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.10
So, unless you're using lots of forms in a single page (why would you
need several forms in the same page is beyond my comprehension), using
indexes is not a big deal.
Matt, you propose *best* javascript practices that, in my humble
opinion, are not as portable as they can be.... at least, on this name
versus index issue. Best practices should always promote valid, safe,
sound practices which will work reliably across browser, across
different DTDs and across code context.
[color=blue]
>
> For more info, see http://www.JavascriptToolbox.com/bestpractices/
>[/color]

Gérard
--
remove blah to email me

re: name reference

> Crazy Code Ninja wrote:[color=blue][color=green]
>> getElementById is really the preferred way[/color][/color]
[color=blue]
> Not really. Then you need to generate a unique ID for each input field[/color]
[color=blue]
> This is exactly what the HTML 4.01 recommendation says, btw:
> "Applications should use the id attribute to identify elements."
> http://www.w3.org/TR/html401/interac...adef-name-FORM[/color]

I'd still put name tag for older browsers, this is just my preferrence,
for example:

<input type="text" id="text1" name="text1" />

ofcourse this is a good practice (IMO) if you generate your html code
using server side script, otherwise leave it out to avoid having
different id/name.

Regards,

Sid

re: name reference

Crazy Code Ninja said the following on 3/15/2006 11:06 PM:[color=blue][color=green]
>> Crazy Code Ninja wrote:[color=darkred]
>>> getElementById is really the preferred way[/color][/color]
>[color=green]
>> Not really. Then you need to generate a unique ID for each input field[/color]
>[color=green]
>> This is exactly what the HTML 4.01 recommendation says, btw:
>> "Applications should use the id attribute to identify elements."
>> http://www.w3.org/TR/html401/interac...adef-name-FORM[/color]
>
> I'd still put name tag for older browsers, this is just my preferrence,
> for example:
>
> <input type="text" id="text1" name="text1" />
>
> ofcourse this is a good practice (IMO) if you generate your html code
> using server side script, otherwise leave it out to avoid having
> different id/name.[/color]

Then you need to re-read what has been deprecated. Its name attributes
on FORM's, not on the elements of forms.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

re: name reference

Gérard Talbot said the following on 3/15/2006 10:53 PM:[color=blue]
> Matt Kruse wrote :[color=green]
>> Crazy Code Ninja wrote:[color=darkred]
>>> getElementById is really the preferred way[/color]
>>
>> Not really. Then you need to generate a unique ID for each input field[/color]
>
>
> This is exactly what the HTML 4.01 recommendation says, btw:
> "Applications should use the id attribute to identify elements."
> http://www.w3.org/TR/html401/interac...adef-name-FORM[/color]

I don't think my thoughts about the specs need to be repeated. But, for
curiosity sake, give all your form elements an id with no name, submit
it to the server, and let us know what you get?

Crippling form submission for the sake of complying with the specs isn't
a good idea.
[color=blue][color=green]
>> and add bloat to your page.
>>[color=darkred]
>>> alert( document.forms[0].elements['textbox'].value );
>>> but you need to wrap your input fields with <form></form>[/color]
>>
>> which you need to do anyway to create valid html.
>>[/color]
>
> Not at all, as pointed out Rob.[/color]

Agreed, but, I have never understood what an input element without a
form is good for in the absence of scripting.
[color=blue][color=green][color=darkred]
>>> , and the
>>> code above assumes you only have one <form></form> in the page.[/color]
>>
>> Which is a bad practice. Use form names instead of indexes.[/color]
>
>
> As I pointed to you before, name attribute has been formally deprecated
> in XHTML 1.0.
> "in XHTML 1.0, the name attribute of these elements (a, applet, form,
> frame, iframe, img, and map) is formally deprecated"
> http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.10[/color]

For a long time, I posted code that looked like this:

document.forms['formNAMEnotID'].elements['elementNAMEnotID'].property

And I changed it to the following:

document.forms['ID'].elements['elementNAMEnotID'].property

Because of what you quoted (It was pointed out to me by Lasse).

But, to use XHTML as a defense/reason to use the ID on a form instead of
the NAME isn't a good argument. Witness IE's behavior with XHTML. (I
know, people reply with "content negotiation").
[color=blue]
> So, unless you're using lots of forms in a single page (why would you
> need several forms in the same page is beyond my comprehension), using
> indexes is not a big deal.[/color]

Multiple forms on the same page have there uses. What if you wanted a
search engine portal for 10 different search engines? You would have 10
different forms so you could post them to 10 different search engines.
[color=blue]
> Matt, you propose *best* javascript practices that, in my humble
> opinion, are not as portable as they can be.... at least, on this name
> versus index issue.[/color]

And if someone comes along behind you and adds a form before this one,
it breaks your code. With a name/ID attribute, that doesn't happen.
Which one is the better practice? There is no ambiguity with
document.forms['formID'] when there is with document.forms[#]
[color=blue]
> Best practices should always promote valid, safe,
> sound practices which will work reliably across browser, across
> different DTDs and across code context.[/color]

That alone makes the forms['formID'] a better practice than forms[#].
But, if it is going to be "across different DTD's" then you have to do
something different. Does HTML3.2 allow ID's on forms?

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

re: name reference

Randy Webb wrote :[color=blue]
> Gérard Talbot said the following on 3/15/2006 10:53 PM:[color=green]
>> Matt Kruse wrote :[color=darkred]
>>> Crazy Code Ninja wrote:
>>>> getElementById is really the preferred way
>>>
>>> Not really. Then you need to generate a unique ID for each input field[/color]
>>
>>
>> This is exactly what the HTML 4.01 recommendation says, btw:
>> "Applications should use the id attribute to identify elements."
>> http://www.w3.org/TR/html401/interac...adef-name-FORM[/color]
>
> I don't think my thoughts about the specs need to be repeated.[/color]

I do not keep a log of what everyone says about this or that... so you
may have to repeat... and I'm getting old too :)


But, for[color=blue]
> curiosity sake, give all your form elements an id with no name, submit
> it to the server, and let us know what you get?[/color]

Of course, it does not make sense. Name/value pairs of form controls are
submitted to the server: that's why name was not deprecated for input,
select and form controls submitting data.
Maybe I may have totally misunderstood that quote from the spec. The
quote might refer only to the form element, not to its contained
elements. I don't know.
[color=blue]
>
> Crippling form submission for the sake of complying with the specs isn't
> a good idea.
>[color=green][color=darkred]
>>> and add bloat to your page.
>>>
>>>> alert( document.forms[0].elements['textbox'].value );
>>>> but you need to wrap your input fields with <form></form>
>>>
>>> which you need to do anyway to create valid html.
>>>[/color]
>>
>> Not at all, as pointed out Rob.[/color]
>
> Agreed, but, I have never understood what an input element without a
> form is good for in the absence of scripting.
>[color=green][color=darkred]
>>>> , and the
>>>> code above assumes you only have one <form></form> in the page.
>>>
>>> Which is a bad practice. Use form names instead of indexes.[/color]
>>
>>
>> As I pointed to you before, name attribute has been formally
>> deprecated in XHTML 1.0.
>> "in XHTML 1.0, the name attribute of these elements (a, applet, form,
>> frame, iframe, img, and map) is formally deprecated"
>> http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.10[/color]
>
> For a long time, I posted code that looked like this:
>
> document.forms['formNAMEnotID'].elements['elementNAMEnotID'].property
>
> And I changed it to the following:
>
> document.forms['ID'].elements['elementNAMEnotID'].property
>
> Because of what you quoted (It was pointed out to me by Lasse).
>
> But, to use XHTML as a defense/reason to use the ID on a form instead of
> the NAME isn't a good argument.[/color]

No, it's the other way. If you're using XHTML, then you can't "name"
your form. You have to access your form with the ordinal index. So,
using the ordinal index instead of the name attribute is more code
portable. That's all I'm saying. I don't necessarly want to promote
XHTML... but then again, there are people who (rightly or wrongly) use
XHTML.

Witness IE's behavior with XHTML. (I[color=blue]
> know, people reply with "content negotiation").
>[color=green]
>> So, unless you're using lots of forms in a single page (why would you
>> need several forms in the same page is beyond my comprehension), using
>> indexes is not a big deal.[/color]
>
> Multiple forms on the same page have there uses. What if you wanted a
> search engine portal for 10 different search engines? You would have 10
> different forms so you could post them to 10 different search engines.
>[/color]

It's rather rare webpage situation... don't you think?

E.g.:
http://www.javascripttoolbox.com/bestpractices/
http://www.javascripttoolbox.com/
http://www.javascripttoolbox.com/lib/
http://www.javascripttoolbox.com/lib/mktree/
http://www.javascripttoolbox.com/lib/objectposition/
all have only 1 form element.

http://www.javascripttoolbox.com/lib/dynamicoptionlist/
has 2 form elements, with the first one without the name attribute.

http://www.javascripttoolbox.com/lib/checkboxgroup/
and
http://www.javascripttoolbox.com/lib/dragiframe/
both have 2 form elements, with both ones without resorting to the name
attribute. Both pages have a google search form.
[color=blue][color=green]
>> Matt, you propose *best* javascript practices that, in my humble
>> opinion, are not as portable as they can be.... at least, on this name
>> versus index issue.[/color]
>
> And if someone comes along behind you and adds a form before this one,[/color]

This makes no sense to me. Unless several several people are developing
a same single website. Again, this is not common.
In a workplace, when coding practices are defined, this sort of issues
is explicited for all people adding code or removing code. Usually, only
1 person does make change and he documents these.
[color=blue]
> it breaks your code. With a name/ID attribute, that doesn't happen.
> Which one is the better practice? There is no ambiguity with
> document.forms['formID'] when there is with document.forms[#]
>[/color]

There is room for ambiguity *if* you have more than 1 form element, *if*
someone else is adding another form *before* without noticing the form
issue. I'd say right here that this is extraordinary rare.
[color=blue][color=green]
>> Best practices should always promote valid, safe, sound practices
>> which will work reliably across browser, across different DTDs and
>> across code context.[/color]
>
> That alone makes the forms['formID'] a better practice than forms[#].
> But, if it is going to be "across different DTD's" then you have to do
> something different. Does HTML3.2 allow ID's on forms?[/color]

I didn't propose id for forms.
One thing is for sure: best javascript practices - whatever they are -
should work in strict DTD (HTML 4.01 or XHTML). Coding for transitional
DTD is already not the best markup coding practice. Best javascript
practices has to be harmonized, coherent, consequent with (and based on)
best markup coding practices to begin with.

Gérard
--
remove blah to email me

re: name reference

Gérard Talbot said the following on 3/16/2006 12:07 AM:[color=blue]
> Randy Webb wrote :[color=green]
>> Gérard Talbot said the following on 3/15/2006 10:53 PM:[color=darkred]
>>> Matt Kruse wrote :
>>>> Crazy Code Ninja wrote:
>>>>> getElementById is really the preferred way
>>>>
>>>> Not really. Then you need to generate a unique ID for each input field
>>>
>>>
>>> This is exactly what the HTML 4.01 recommendation says, btw:
>>> "Applications should use the id attribute to identify elements."
>>> http://www.w3.org/TR/html401/interac...adef-name-FORM[/color]
>>
>> I don't think my thoughts about the specs need to be repeated.[/color]
>
> I do not keep a log of what everyone says about this or that... so you
> may have to repeat... and I'm getting old too :)[/color]

I have read the specs so many times that when I see people quote them I
almost know where to go find it before they tell me. But I still
wouldn't give you 10 cents American for all of them. They are a good
guideline but that is it. I prefer to know what the Browser's behavior
is compared to what it should be :)
[color=blue]
>
> But, for[color=green]
>> curiosity sake, give all your form elements an id with no name, submit
>> it to the server, and let us know what you get?[/color]
>
> Of course, it does not make sense. Name/value pairs of form controls are
> submitted to the server: that's why name was not deprecated for input,
> select and form controls submitting data.
> Maybe I may have totally misunderstood that quote from the spec. The
> quote might refer only to the form element, not to its contained
> elements. I don't know.[/color]

From reading that section, and then the section following it on inputs,
I would say it is definitely in relation to the FORM element itself and
not its elements.

<!ENTITY % InputType
"(TEXT | PASSWORD | CHECKBOX |
RADIO | SUBMIT | RESET |
FILE | HIDDEN | IMAGE | BUTTON)"[color=blue]
>[/color]

<!-- attribute name required for all but submit and reset -->

And then in the attlist there is no ID. But further below that it says
"Attributes defined elsewhere" and lists the ID.

So, since it says that form elements are required to have a name it
wouldn't make sense for them to be deprecated :)

<snipped things we appear to agree on>
[color=blue][color=green]
>> But, to use XHTML as a defense/reason to use the ID on a form instead
>> of the NAME isn't a good argument.[/color]
>
> No, it's the other way. If you're using XHTML, then you can't "name"
> your form. You have to access your form with the ordinal index.[/color]

Or it's ID :)
[color=blue]
> So, using the ordinal index instead of the name attribute is more code
> portable. That's all I'm saying. I don't necessarly want to promote
> XHTML... but then again, there are people who (rightly or wrongly) use
> XHTML.[/color]

I think both of our opinions are right and both are wrong. The solution
is what best fits the situation :)
[color=blue]
> Witness IE's behavior with XHTML. (I[color=green]
>> know, people reply with "content negotiation").
>>[color=darkred]
>>> So, unless you're using lots of forms in a single page (why would you
>>> need several forms in the same page is beyond my comprehension),
>>> using indexes is not a big deal.[/color]
>>
>> Multiple forms on the same page have there uses. What if you wanted a
>> search engine portal for 10 different search engines? You would have
>> 10 different forms so you could post them to 10 different search engines.
>>[/color]
>
> It's rather rare webpage situation... don't you think?[/color]

Probably so. When I wrote that I was thinking about a page I wrote for a
friend that orders parts. He has 11 vendors he uses and has to search
all 11 one at a time. I wrote him one that combines them all into one
page. But, it has 12 different forms it uses so he can search
individually and a "search them all" form. But for a web situation, the
most I have seen in practical use is 4 - my bank's website. It has one
for me to login, it has a Google search box (why I want to go to my
banks site to search Google is beyond me though), one for me to contact
the webmaster if I can't login and the fourth is a "I lost my password"
form.

[color=blue]
>[color=green][color=darkred]
>>> Matt, you propose *best* javascript practices that, in my humble
>>> opinion, are not as portable as they can be.... at least, on this
>>> name versus index issue.[/color]
>>
>> And if someone comes along behind you and adds a form before this one,[/color]
>
> This makes no sense to me. Unless several several people are developing
> a same single website. Again, this is not common.
> In a workplace, when coding practices are defined, this sort of issues
> is explicited for all people adding code or removing code. Usually, only
> 1 person does make change and he documents these.[/color]

I want your job then. I don't get assignments that say "Here is the
page, this is what I need". It's more along the lines of "I want a
snippet/widget that does this, here's your deadline, here's your money,
where's my damn code".

[color=blue][color=green]
>> it breaks your code. With a name/ID attribute, that doesn't happen.
>> Which one is the better practice? There is no ambiguity with
>> document.forms['formID'] when there is with document.forms[#]
>>[/color]
>
> There is room for ambiguity *if* you have more than 1 form element, *if*
> someone else is adding another form *before* without noticing the form
> issue. I'd say right here that this is extraordinary rare.[/color]

I don't. But it still goes back to "The best solution depends, directly,
on the situation". And if you want a "General Best Practice", you either
use the forms NAME or ID to access it. Then, it works in *all*
situations where the form has a NAME/ID.
[color=blue][color=green][color=darkred]
>>> Best practices should always promote valid, safe, sound practices
>>> which will work reliably across browser, across different DTDs and
>>> across code context.[/color]
>>
>> That alone makes the forms['formID'] a better practice than forms[#].
>> But, if it is going to be "across different DTD's" then you have to do
>> something different. Does HTML3.2 allow ID's on forms?[/color]
>
> I didn't propose id for forms.[/color]

Not directly. You said "Best practices should always promote valid,
safe, sound practices " and that makes forms['formID'] a better -
general - practice than forms[#] because it will work in more situations
than forms[#] will. That was my only point.
[color=blue]
> One thing is for sure: best javascript practices - whatever they are -
> should work in strict DTD (HTML 4.01 or XHTML). Coding for transitional
> DTD is already not the best markup coding practice. Best javascript
> practices has to be harmonized, coherent, consequent with (and based on)
> best markup coding practices to begin with.[/color]

I totally agree. But there still has to be a limit somewhere. Otherwise,
you lose the ability to keep a document "general" in scope. I had a
conversation with Richard a long time ago about this same thing. I wish
I could find the thread but I can't. But it was based on best practices
in general and the example that I used was changing the source of an
image. I can write for weeks on end about pre-loading, changing, and
loading images and would probably still miss some of the caveats and
problems with it. But to stay general, you have to limit yourself
somewhere and say "This is it". You change the source of an image by
using the images collection and changing it's src property. This is the
same principle. Somewhere, somehow, you have to limit yourself or you
end up making your guidelines so convoluted that you lose your general
audience by making it *too* complex by including all the caveats/problems.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?

Please quote what you are replying to.

If you want to post a followup via groups.google.com, don't use the
"Reply" link at the bottom of the article. Click on "show options" at
the top of the article, then click on the "Reply" at the bottom of the
article headers. <URL: http://www.safalra.com/special/googlegroupsreply/ >

re: name reference

Gérard Talbot wrote:[color=blue]
> Maybe I may have totally misunderstood that quote from the spec. The
> quote might refer only to the form element, not to its contained
> elements. I don't know.[/color]

As Randy pointed out, I think that is true.
[color=blue][color=green][color=darkred]
>>>>> but you need to wrap your input fields with <form></form>
>>>> which you need to do anyway to create valid html.
>>> Not at all, as pointed out Rob.[/color][/color][/color]

I stand corrected. I had always believed it was invalid, but after looking
at the DTD I see I am wrong.
[color=blue][color=green]
>> Agreed, but, I have never understood what an input element without a
>> form is good for in the absence of scripting.[/color][/color]

Agreed, which is why I guess I assumed they would need to be contained in a
form element.
[color=blue][color=green][color=darkred]
>>> As I pointed to you before, name attribute has been formally
>>> deprecated in XHTML 1.0.[/color][/color][/color]

Well first of all, I think XHTML is worthless. Second, few people are using
it and if they are then they probably already know how to reference a form.
Third, I think XHTML itself should be deprecated ;)
[color=blue]
> No, it's the other way. If you're using XHTML, then you can't "name"
> your form. You have to access your form with the ordinal index. So,
> using the ordinal index instead of the name attribute is more code
> portable.[/color]

In that case, though, I would recommend using the ID instead of the ordinal
index. I will make a note to update my best practices document with a
side-note for xhtml.
[color=blue][color=green][color=darkred]
>>> So, unless you're using lots of forms in a single page (why would
>>> you need several forms in the same page is beyond my
>>> comprehension), using indexes is not a big deal.[/color][/color][/color]

I use it regularly. Often a google search bar, for example, uses a separate
form. Also, I find it convenient to have multiple forms if a page shows
multiple logical groups of fields which can be edited for a big entity. Each
section can be updated separately (perhaps using "ajax") and each separate
form can have its own validation, etc. Also, in portals or other "mixed
content" applications, the designer of a section of the page may have his
own form and have no knowledge of what else may be on the page.
[color=blue]
> http://www.javascripttoolbox.com/lib/dynamicoptionlist/
> has 2 form elements, with the first one without the name attribute.[/color]

Name isn't required. It's only useful when you actually want to reference
the form object, which I don't do on the page.
[color=blue][color=green][color=darkred]
>>> Matt, you propose *best* javascript practices that, in my humble
>>> opinion, are not as portable as they can be.... at least, on this
>>> name versus index issue.[/color][/color][/color]

I think the best solution, as I said, is to make an exception for xhtml. For
regular html use, I think a form name is still the best practice. I do plan
to make a round of revisions to my best practices document, actually, to
make it more robust and to take into consideration the comments I've
received.

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

re: name reference

Matt Kruse wrote :[color=blue]
> Gérard Talbot wrote:[/color]
[color=blue][color=green][color=darkred]
>>>> As I pointed to you before, name attribute has been formally
>>>> deprecated in XHTML 1.0.[/color][/color]
>
> Well first of all, I think XHTML is worthless.[/color]

Matt, your appreciation or preference for XHTML is not the issue here.
If someone uses XHTML 1.0, then he can't safely use your best javascript
practices: that was my point.
[color=blue]
> Second, few people are using
> it[/color]

That could be debatable (few is how much? %tage) and, anyway, that's
irrelevant to the issue addressed.
[color=blue]
> and if they are then they probably already know how to reference a form.[/color]

I disagree with your assumption here. You'd be surprised to see how many
XHTML-based documents are generated by DreamWeaver or Nvu nowadays where
amateur web authors, even paid ones, don't know how to reference a form.

[color=blue]
> Third, I think XHTML itself should be deprecated ;)
>[/color]

[snipped]

I personally do not use XHTML. I personally do not recommend to use
XHTML. But that's not the issue here.

Gérard
--
remove blah to email me

re: name reference

<rant>

I try to use xhtml practices as I can (e.g.: follow xml closing tag
rule, use lowercase, accessibility, etc), but I don't pressure myself
to conform to xhtml standard, I don't even use doctype! (gasp! oh the
horror, the 'd' word) Ok, so I won't ever win any medal for www
standard conformance, but who cares!

I don't see quirks-mode being abandoned in the future coz there is no
way people are going to fix all those billions old pages on the net!
Abandoning backward compatibility is suicidal for any browser.

</rant>

re: name reference

Crazy Code Ninja wrote:

Please provide attribution of quoted material.
<URL:http://jibbering.com/faq/faq_notes/pots1.html#ps1Post>
<URL:http://www.safalra.com/special/googlegroupsreply/>
vvvvvvvvvvvvvvvvvvvvvvvvvv[color=blue][color=green]
>> Crazy Code Ninja wrote:[color=darkred]
>>> getElementById is really the preferred way[/color][/color]
>[color=green]
>> Not really. Then you need to generate a unique ID for each input field
>>
>> This is exactly what the HTML 4.01 recommendation says, btw:
>> "Applications should use the id attribute to identify elements."
>> http://www.w3.org/TR/html401/interac...adef-name-FORM[/color][/color]

"Applications" refers to HTML user agents of course, not "Web
applications" (with client-side scripting). Otherwise it would
be completely ignored that such a recommendation forced "Web
applications" (such as that of the OP) to use not backwards
compatible referencing.

Understand that the HTML Specification is primarily for HTML
implementors, not "Web application" developers:

<URL:http://www.alistapart.com/stories/readspec/>
[color=blue]
> I'd still put name tag for older browsers,
>
> this is just my preferrence, for example:
>
> <input type="text" id="text1" name="text1" />[/color]

That is a `name' attribute, within the start tag of an `input' element.
It is entirely redundant here. And the HTML 4.01 Specification makes it
clear what should be considered with IDs:

<URL:http://www.w3.org/TR/html401/struct/links.html#anchors-with-id>

Using a `name' attribute or not for those elements does not have anything
to do with "older browsers"; the forms-elements referencing defined by W3C
DOM 2 HTML is both standards compliant and backwards compatible. You are
required to name your form controls if you want their value to be
submitted. That is why there is still a `name' attribute for form controls
in HTML 4.01 Strict, XHTML 1.0 Strict and even in the Forms modules of
XHTML 1.1.


PointedEars

re: name reference

Crazy Code Ninja wrote:
[color=blue]
> <rant>
>
> I try to use xhtml practices as I can (e.g.: follow xml closing tag[/color]

"XHTML practices" is utter nonsense.
[color=blue]
> rule, use lowercase, accessibility, etc), but I don't pressure myself
> to conform to xhtml standard, I don't even use doctype![/color]

A DOCTYPE declaration is required for _all_ SGML-based markup languages,
not only XHTML.
[color=blue]
> (gasp! oh the horror, the 'd' word) Ok, so I won't ever win any medal
> for www standard conformance, but who cares![/color]

Obviously you do not care about your visitors as you do not care about
interoperability. But then, who cares about you.


PointedEars

re: name reference

Don't take my post out of context, I also said:
[color=blue]
>I don't see quirks-mode being abandoned in the future coz there is no
>way people are going to fix all those billions old pages on the net!
>Abandoning backward compatibility is suicidal for any browser.[/color]

If quirksmode almost certainly will always exist, why should I spend so
much time trying to "fix" my pages and be limited? Oh to adhere to
standards?

Besides, why do we have many different DTDs for? There should only be
one, the one that works! and to me that's the quirksmode. We spend so
much time trying to be compliant to these standards, but one tiny
mistake and the browser will switch back to quirksmode anyway.

For example: trademe.co.nz has a doctype, they probably tried to
comply, yet the w3c validator said it isn't valid
(http://validator.w3.org/check?uri=www.trademe.co.nz), and if you look,
its invalid for some tiny insignificant mistakes, not for missing
closing tag, or something like that. So I guess the browser will render
it in quirksmode afterall.Time wasted trying to comply to a doctype.
[color=blue]
> Obviously you do not care about your visitors as you do not care about
> interoperability. But then, who cares about you.[/color]

I care about my visitors and interoperability, I don't care about
standards.

I only put doctype if client especially ask for it, e.g.: government
agency. But even the government has wasted their money too, check this
out: http://validator.w3.org/check?uri=www.nzis.govt.nz

Thomas 'PointedEars' Lahn wrote:[color=blue]
> Crazy Code Ninja wrote:
>[color=green]
> > <rant>
> >
> > I try to use xhtml practices as I can (e.g.: follow xml closing tag[/color]
>
> "XHTML practices" is utter nonsense.
>[color=green]
> > rule, use lowercase, accessibility, etc), but I don't pressure myself
> > to conform to xhtml standard, I don't even use doctype![/color]
>
> A DOCTYPE declaration is required for _all_ SGML-based markup languages,
> not only XHTML.
>[color=green]
> > (gasp! oh the horror, the 'd' word) Ok, so I won't ever win any medal
> > for www standard conformance, but who cares![/color]
>
> Obviously you do not care about your visitors as you do not care about
> interoperability. But then, who cares about you.
>
>
> PointedEars[/color]

re: name reference

Crazy Code Ninja wrote:[color=blue]
> If quirksmode almost certainly will always exist, why should I spend
> so much time trying to "fix" my pages and be limited? Oh to adhere to
> standards?[/color]

You have a significant misunderstanding of quirks mode.

Quirks mode != valid HTML

The advantage of standards mode is that browsers like IE will behave more
closely to the standards and other browsers. So you can write your HTML
correctly once and have it work the same across more browsers. Having your
page in quirks mode retains fundamental differences which make it more
difficult to create cross-browser pages.

Just because a browser is in standards mode doesn't mean the HTML must
validate.
[color=blue]
> Besides, why do we have many different DTDs for?[/color]

Read up on the history of HTML.
[color=blue]
> We spend so
> much time trying to be compliant to these standards, but one tiny
> mistake and the browser will switch back to quirksmode anyway.[/color]

That's not true. Just because a document doesn't validate to strict dtd, for
example, doesn't mean it will trigger quirks mode.
[color=blue]
> For example: trademe.co.nz has a doctype, they probably tried to
> comply, yet the w3c validator said it isn't valid
> (http://validator.w3.org/check?uri=www.trademe.co.nz), and if you
> look, its invalid for some tiny insignificant mistakes, not for
> missing closing tag, or something like that. So I guess the browser
> will render it in quirksmode afterall.[/color]

Wrong.
[color=blue]
> I only put doctype if client especially ask for it[/color]

Then you're doing your clients no favor!

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

re: name reference

Hi Matt, you're right, I stand corrected about quirksmode != valid HTML
and the importance of putting DTD.

I guess its just my experience with trying to use xhtml strict DTD and
trying to validate against w3c validator. Seems like a lot of time
spend on syntax, rather than getting on things that users can see. I
just test my pages on the major browsers.

Matt Kruse wrote:[color=blue]
> Crazy Code Ninja wrote:[color=green]
> > If quirksmode almost certainly will always exist, why should I spend
> > so much time trying to "fix" my pages and be limited? Oh to adhere to
> > standards?[/color]
>
> You have a significant misunderstanding of quirks mode.
>
> Quirks mode != valid HTML
>
> The advantage of standards mode is that browsers like IE will behave more
> closely to the standards and other browsers. So you can write your HTML
> correctly once and have it work the same across more browsers. Having your
> page in quirks mode retains fundamental differences which make it more
> difficult to create cross-browser pages.
>
> Just because a browser is in standards mode doesn't mean the HTML must
> validate.
>[color=green]
> > Besides, why do we have many different DTDs for?[/color]
>
> Read up on the history of HTML.
>[color=green]
> > We spend so
> > much time trying to be compliant to these standards, but one tiny
> > mistake and the browser will switch back to quirksmode anyway.[/color]
>
> That's not true. Just because a document doesn't validate to strict dtd, for
> example, doesn't mean it will trigger quirks mode.
>[color=green]
> > For example: trademe.co.nz has a doctype, they probably tried to
> > comply, yet the w3c validator said it isn't valid
> > (http://validator.w3.org/check?uri=www.trademe.co.nz), and if you
> > look, its invalid for some tiny insignificant mistakes, not for
> > missing closing tag, or something like that. So I guess the browser
> > will render it in quirksmode afterall.[/color]
>
> Wrong.
>[color=green]
> > I only put doctype if client especially ask for it[/color]
>
> Then you're doing your clients no favor!
>
> --
> Matt Kruse
> http://www.JavascriptToolbox.com
> http://www.AjaxToolbox.com[/color]

re: name reference

Matt Kruse wrote:
[color=blue]
> Crazy Code Ninja wrote:[color=green]
>> If quirksmode almost certainly will always exist, why should I spend
>> so much time trying to "fix" my pages and be limited? Oh to adhere to
>> standards?[/color]
>
> You have a significant misunderstanding of quirks mode.[/color]

You, too, it seems.
[color=blue]
> Quirks mode != valid HTML[/color]

Quirks mode != invalid HTML

would be correct, but not sufficient.


PointedEars

re: name reference

Thomas 'PointedEars' Lahn wrote:[color=blue][color=green]
>> You have a significant misunderstanding of quirks mode.[/color]
> You, too, it seems.[/color]

I don't believe so
[color=blue][color=green]
>> Quirks mode != valid HTML[/color]
> Quirks mode != invalid HTML
> would be correct, but not sufficient.[/color]

Duh. The point being made that the validity of html is not a trigger for
standards vs. quirks mode.
The OP seemed to imply that HTML that did not validate correctly would throw
a browser into quirks mode, which is incorrect.

Posting just to be an argumentative jerk is quite unnecessary.

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

re: name reference

Matt Kruse wrote on 21 mrt 2006 in comp.lang.javascript:[color=blue]
> Posting just to be an argumentative jerk is quite unnecessary.[/color]

This is true, Matt, because it is an argumentative sub-argument of

"Posting is unnnecessary"

which I submit to be true.

;-}

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

re: name reference

Evertjan. wrote:[color=blue]
> Matt Kruse wrote on 21 mrt 2006 in comp.lang.javascript:[color=green]
>> Posting just to be an argumentative jerk is quite unnecessary.[/color]
> This is true, Matt, because it is an argumentative sub-argument of
> "Posting is unnnecessary"
> which I submit to be true.
> ;-}[/color]

You win.

PS: This post was unnecessary. ;)

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