Quick question about using a table of text input fields within ajavascrip function

[GTalbot]

sub print_javascripts {
    print "<script LANGUAGE=\"Javascript\" type=\"text/javascript
\">var n = 0</script>\";
    print "<script LANGUAGE=\"Javascript\" type=\"text/javascript\">

Language is deprecated. Type is required, good.

Javascript Best Practices
http://www.javascripttoolbox.com/bestpractices/#script

          function addRow(id){
             n++;\"
             var str = 'item' + n;
             var tbody = document.getElementById(id).getElementsByTagName
(\"tbody\")[0];
             var row = document.createElement(\"tr\");
             var input = document.createElement('input');
             input.type = 'text';
             input.name = 'str';
             input.size = 50;
             input.maxlength = 256;

It's maxLength, not maxlength
http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-54719353

             var data = document.createElement(\"td\");
             data.appendChild(input);
             row.appendChild(data);
             tbody.appendChild(row);
          } </script>";

}

As you can see,

Ted, it would have been utterly relevant to provide an url with only
the involved javascript. Then, you would have gotten useful help from
this newsgroup.

Second question, I wrote this on the assumption that text input fields
have to have unique names.  Is this assumption correct, or can I give
all the text input fields in this table the same name,

document.getElementsByName is pretty buggy in IE (all versions). So,
all text input with the same name is not an recommendable option.

Finally, such script will most likely not work in IE 6 and IE 7 (too
buggy). You can recommend your visitors to upgrade or to switch here.

Gérard

 

[VK]

Folks, please research a bit before posting about a rather well known
issue.

http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/DynamicallyInsert...

{
Internet Explorer 8 and later can set the NAME attribute at run time
on elements dynamically created with the createElement method. To
create an element with a NAME attribute in earlier versions of
Internet Explorer, include the attribute and its value when using the
createElement method.}

Well, this is a urban legend, must be a reflection of some in-between-
fixes state of IE4-5 or some IE4-5-specific troubles with bad HTML
markup. One having IE6 is welcome to test the code at
http://www.whitenightsopera.com/tmp/table.html

 

[VK]

The standards-compliant approach is safe. Windows IE does not like it if
you attempt to assign to a form control's - type - property after you
attach it to a DOM (or imply its attachment to a document fragment), but
that is easy enough to avoid (by assigning the - type - immediately
after creation).

No, it doesn't help until IE7. The set of input elements where it
doesn't help varies by IE6 lesser-minor and lesser-lesser-minor
versions but never equals to 0.

The standards competent approach has been successful
with form controls in all versions of Windows IE since 5.

Oh, your poor customers... :-( Well, at least their scripts died
acting in the fully proper way to the last breath, like real
gentlemen

 

[Eric Bednarz]

[…] ill-mannered, obnoxious, arrogant,
offensive, etc.

The mnemonic anti-pommy device simply being ‘Dr’

 

[Thomas 'PointedEars' Lahn]

just IE6 has a majority of security fixes,
some of which are not directly attributed as IE-fix but
coming as Windows XP fixes. Say the only real IE6 I left
for testing is 6.0.2900.2180 / Windows XP SP2 and it gives
"Command not supported" exception for

var elm = document.createElement('INPUT');
elm.type = 'RADIO'; // exception here

var elm = document.createElement('BUTTON');
elm.type = 'BUTTON'; // exception here
[...]

IOW, triggering an error with the standards-compliant approach

The above is not a standards compliant approach. The W3C HTML Level 2
DOM specifies the - type - properties of INPUT, BUTTON, TEXTAREA and
SELECT element's DOM interfaces as being all lowercase, so there never
was any reason for expecting to be able to successfully assign what is
in effect an incorrect value to the property.

Thanks, I was not aware that the case-insensitivity defined in HTML¹ does
not apply here.

¹ <http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#adef-
type-INPUT>

The standards-compliant approach is safe. Windows IE does not like it if
you attempt to assign to a form control's - type - property after you
attach it to a DOM (or imply its attachment to a document fragment), but
that is easy enough to avoid (by assigning the - type - immediately
after creation). The standards competent approach has been successful
with form controls in all versions of Windows IE since 5.

Exactly my experiences and train of thought.


PointedEars

 

[Thomas 'PointedEars' Lahn]

No, it doesn't help until IE7.

You are wrong. It works fine in IE 6.0 (exact version unknown) in Windows
XP SP 3 and IE 6.0.2800.1106 in wine-1.0.1-174-gc4039bd.

The set of input elements where it doesn't help varies by IE6 lesser-minor
and lesser-lesser-minor versions but never equals to 0.

Gibberish again. You would continue to support versions of operating
systems and browsers that pose a security risk, wouldn't you?

Oh, your poor customers... :-( Well, at least their scripts died
acting in the fully proper way to the last breath, like real
gentlemen

Question retracted. Please find someone competent to do your job instead,
for the sake of your so valued customers.


PointedEars

 

[GTalbot]

Well, this is a urban legend, must be a reflection of some in-between-
fixes state of IE4-5 or some IE4-5-specific troubles with bad HTML
markup. One having IE6 is welcome to test the code athttp://www.whitenightsopera.com/tmp/table.html

VK,

I tried your test.

It's maxLength, not maxlength.
http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-54719353

Creating and inserting dynamically an input (with createElement and
with assigning it a name) is one thing. Accessing (referencing) it
later in IE 6 and IE 7 is another thing. I provided links and test on
this. That bug was confirmed and the limitation was also documented at
MSDN.

So, on all these points, there are real issues with IE 6 and IE 7;
there is no "urban legend" about these points.

Gérard