Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 14 of 14
  1. #1
    New to the CF scene
    Join Date
    Jan 2004
    Posts
    9
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Inconsistency btw form.element and DOM

    I used DOM to add another input field ot the middle of a HTML form, when I do a submit or look at the fields using form.elements, they are in the right position in IE.

    However, if I do it in Mozilla, the new input field shows up at the end rather in the right position. For me, the ordering in submit is important. Is there anyway to get around the problem?

    BTW, using DOM to go through the fields is a pain too because one cannot just use getElementsByTagName('INPUT') because there are also textarea and select.

  • #2
    Master Coder
    Join Date
    Feb 2003
    Location
    Umeň, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts

    Re: Inconsistency btw form.element and DOM

    Originally posted by datamech
    I used DOM to add another input field ot the middle of a HTML form, when I do a submit or look at the fields using form.elements, they are in the right position in IE.
    That's because iew doesn't behave as it should. Form elements are identified by their name - their position in the elements collection or is irrelevant, since you don't normally address them using their position. Iew has a nasty tendency to sometimes not at all add the form fields to the elements collection, however, so you must add them manually if that is the case.
    However, if I do it in Mozilla, the new input field shows up at the end rather in the right position. For me, the ordering in submit is important. Is there anyway to get around the problem?
    Mozilla adds them to the collection in definition order. Why is order important? They each have a name/value pair, right (if not, they should)?
    BTW, using DOM to go through the fields is a pain too because one cannot just use getElementsByTagName('INPUT') because there are also textarea and select.
    That's why you use the DOM to get the form element, and from there use the elements collection to access them by name.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #3
    New to the CF scene
    Join Date
    Jan 2004
    Posts
    9
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Re: Inconsistency btw form.element and DOM

    The position in the elements collection is irrelevant, since you don't normally address them using their position. Iew has a nasty tendency to sometimes not at all add the form fields to the elements collection, however, so you must add them manually if that is the case.

    Mozilla adds them to the collection in definition order. Why is order important? They each have a name/value pair, right (if not, they should)?
    The fact that position is usually irrelevant does not means that they are irrelevant in any applicaiton. In my case I use position to denote important information.

    That's why you use the DOM to get the form element, and from there use the elements collection to access them by name.
    I already said it, I cannot do it this way for Mozilla because the elements collection is not in the right order. To get it in the right order I have to walk the DOM tree.

    Right now I have two possible work arounds for the problem. One is to append a speical symbol followed by a order number to the name before I submit and remove it afterwards. Or I just do everything on the client side and forget about CGI.

  • #4
    Master Coder
    Join Date
    Feb 2003
    Location
    Umeň, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    Hmm, correct me if I'm mistaken, but isn't the submitted data always in name:value pairs, and that is all the data the server gets from the client? If you're prevented from using the name, why can't you use the value to tell the server what element you're referring to?
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #5
    New to the CF scene
    Join Date
    Jan 2004
    Posts
    9
    Thanks
    0
    Thanked 0 Times in 0 Posts
    <QUOTE>Hmm, correct me if I'm mistaken, but isn't the submitted data always in name:value pairs, and that is all the data the server gets from the client? If you're prevented from using the name, why can't you use the value to tell the server what element you're referring to?
    </QUOTE>

    They are always in name, value pair. I need to use both of them, and I need to know the order.

    Let me give an example, suppose a name will appear serveral times and the CGI program want to know the last value, but keep the other values for record. However if the order can be scrambled, then you are not getting the right information.

  • #6
    Master Coder
    Join Date
    Feb 2003
    Location
    Umeň, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    You mean you have multiple form fields of a type that shouldn't take multiple values with the same name? You know that only checkboxes and radio buttons may share name with other controls, though select elements may send multiple values as well?

    As for as specification goes, the sequence control name/value pairs should take is unspecified - which means that you should never rely on it being a certain way or another.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #7
    New to the CF scene
    Join Date
    Jan 2004
    Posts
    9
    Thanks
    0
    Thanked 0 Times in 0 Posts
    This is Mozilla Bug 204784, https://bugzilla.mozilla.org/show_bug.cgi?id=204784
    The status is fixed but not yet released.

  • #8
    Master Coder
    Join Date
    Feb 2003
    Location
    Umeň, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    Datamech: Whether that bug gets fixed or not, the fact remains: Only radio or check boxes may share names according to the specification. All other form controls must have unique names. None of the form control types that allow multiple control withe the same name allow for user specified values, so if you do everything to the specification, you are always in either of the below situations:
    - For all user specified values, control names must be unique, thus you can always know the form control by only name.
    - For all user toggleable values, control names may be shared, but you always know from the name what group of allowed values may be toggled on and off, thus you always know the form control by name:value pair.

    The only case where the order really matters is thus when dynamically inserting or changing one of the user toggleable controls or in the case of the control being a select inserting or changing an option, in the happenstance you would chose the same value for the newly inserted or changed control as one of the previous control values.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #9
    New to the CF scene
    Join Date
    Jan 2004
    Posts
    9
    Thanks
    0
    Thanked 0 Times in 0 Posts
    I did a little experiment, I make a html file with a form that has two input elements with the same name. Then I go to the W3C Markup Validation Service at http://validator.w3.org/

    I guess they should know something about what is valid or not. So I use their service and validate my test file.

    No problem at all.

  • #10
    New to the CF scene
    Join Date
    Jan 2004
    Posts
    9
    Thanks
    0
    Thanked 0 Times in 0 Posts
    If you have multiple text input fields in form "formX" with the same name "name1", what happens when you do document.formX.name1 in JavaScript? If indeed the name must be unique, then you should either get an error, or get the first input named "name1". However you get a list of inputs. If indeed name must be unique, why would JavaScript go through all the effort to work with something that is illegal according to the specification?

  • #11
    Master Coder
    Join Date
    Feb 2003
    Location
    Umeň, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    Datamech: Browsers are made to tolerate user error. That's the reason for the JavaScript to work.

    As for the HTML specification, it does actually put a limit on the use of form control names, but that limit can not be represented in the DTD validation system and since the HTML validator is DTD based it has the same limits as the DTD syntax it validates towards. However, some limits above what the DTD can convey are placed on some HTML constructs, among them the name attribute of form controls, are both written as comments in the XHTML DTDs and are written in the HTML specification. Another such limit is that forms may not nest, but still if you put a form element inside a div element inside a form element it will validate using a DTD validator. Same goes for links inside links and some other such cases. The HTML validator catches a little more of these errors since the SGML DTD syntax is more verbose than the XML DTD syntax and can do element exclusion, but it can still not change the attribute definitions of an element depending on other attributes.
    Last edited by liorean; 12-09-2004 at 10:23 PM.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #12
    New to the CF scene
    Join Date
    Jan 2004
    Posts
    9
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by liorean
    Datamech: Browsers are made to tolerate user error. That's the reason for the JavaScript to work.
    If JavaScript merely want to tolerate user error, it would return the first matching item rather than a list. Returning multiple items when only single item is expected is certain to cause more errors.

    Quote Originally Posted by liorean
    As for the HTML specification, it does actually put a limit on the use of form control names, but that limit can not be represented in the DTD validation system and since the HTML validator is DTD based it has the same limits as the DTD syntax it validates towards. However, some limits above what the DTD can convey are placed on some HTML constructs, among them the name attribute of form controls, are both written as comments in the XHTML DTDs and are written in the HTML specification. Another such limit is that forms may not nest, but still if you put a form element inside a div element inside a form element it will validate using a DTD validator. Same goes for links inside links and some other such cases. The HTML validator catches a little more of these errors since the SGML DTD syntax is more verbose than the XML DTD syntax and can do element exclusion, but it can still not change the attribute definitions of an element depending on other attributes.
    I don't know how exactly the W3C validator works, and the above is pure speculation. If you put a form inside a div and put the whole thing inside another form, the W3C validator does reject it. So there goes the theory.

    The bottom line is, exactly where in the HTML specification does it say input names must be unique in forms? I cannot find that at all.

  • #13
    New to the CF scene
    Join Date
    Sep 2005
    Posts
    1
    Thanks
    0
    Thanked 0 Times in 0 Posts
    hi,

    I use the DOM to change some INPUT node in my form (to hide and unhide a field). the problem is that this Input node appear in the INPUT list if I do a getElementByTagName('INPUT') but I can't have it in my formX.elements ... submitting the form won't send this field.

    any idea to fix this?

    thx

  • #14
    Kor
    Kor is offline
    Red Devil Mod Kor's Avatar
    Join Date
    Apr 2003
    Location
    Bucharest, ROMANIA
    Posts
    8,478
    Thanks
    58
    Thanked 379 Times in 375 Posts
    Quote Originally Posted by asem03
    hi,

    I use the DOM to change some INPUT node in my form (to hide and unhide a field). the problem is that this Input node appear in the INPUT list if I do a getElementByTagName('INPUT') but I can't have it in my formX.elements ... submitting the form won't send this field.

    any idea to fix this?

    thx
    The disabled form's elements are not submitted.

    BTW, using DOM to go through the fields is a pain too because one cannot just use getElementsByTagName('INPUT') because there are also textarea and select.
    Select is not an input tag. And you may use a simple type specification to get all the textfiels among the inputs

    PHP Code:
    var allTxt=[]//the textfields collection
    var allInp document.getElementsByTagName('input')
    for(var 
    i=0;i<allInp.length;i++){
    if(
    allInp.getAttribute('type')=='text'){allTxt[allTxt.length]=allInp[i]}

    KOR
    Offshore programming
    -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •