W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2006

Re: Radio button group&In-Reply-To=<11717A70-813A-427C-9ED4-65EF35392C20@personallegal.net>&References=<11717A70-813A-427C-9ED4-65EF35392C20@personallegal.net>

From: Calogero Alex Baldacchino <alex.baldacchino@email.it>
Date: Wed, 22 Mar 2006 03:07:05 +0100
To: www-dom@w3.org
Message-ID: <op.s6slh3n6cy4r00@xp-tiger>

Maybe I've been unclear in some points, maybe because English isn't my  
first language and so I apologize for any syntactic error or ugly  
expression. My aim wasn't to criticize anything nor anyone, the web needed  
one unique standard and W3C working groups' afford has been great. I've  
just tried to suggest a reflection hint starting from a concrete situation  
which might seen as a DOM lack, but which I don't consider a DOM fault,  
and which was the subject of a discussion: html allows you to group  
controls in a form by giving them the same "name" attribute, but DOM APIs,  
by working at the whole document level in this case, don't let you  
directly access that group in that form and only that group in that form,  
so you must rely (if different from yourself) in html developers' choice  
to use that name just for that group in that form and invoke  
getElementsByName, or you can manually search grouped controls.

So we get the point: when talking about "language" I didn't refer to  
"Javascript" or any other scripting language, as well as DOM APIs binding,  
but to the hypertext markup language, which allows you to use the same  
name as attribute for several different elements, solving any ambiguity by  
managing different elements simply as different elements, despite their  
name, and that is an anchor is anchor while a radio button (or a checkbox)  
is a radio button (checkbox), and two radio buttons in two different forms  
sharing the same name are not grouped (according to html 4.01  
specification, http://www.w3.org/TR/html401/interact/forms.html#h-17.2,  
"The scope of the name attribute for a control within a FORM element is  
the FORM element"). However, such a behaviour for name attributes leave a  
considerable ambiguity the DOM have to "fight" in order to group elements  
based on their name attribute: outside a form, strong typing and  
identifier uniqueness prevails, while inside a form name identifiers are  
shareable, and this seems to prevail over typing, since form controls are  
encoded and transmitted as name/value pairs, being a number of couples  
with the same name forming a logical group, regardless their type (I'm not  
fully sure, but I think that if some radio buttons and checkboxes shared  
the same name, than all checked elements - the only selected radio and all  
selected checkboxes - would be encoded as pairs with the same name). So I  
consider this a matter of the language (html) defining the document,  
before than a Document Object Model matter, because the DOM reflects, in a  
strongly typed form, the document structures so as they've been defined by  
the markup language; but this doesn't mean I'm blaming on html for any  
reason, because html, and particularly its form  
behaviour/encoding/transmission, was born before DOM and with a different  
purpose (I think it was to minimize transmitted data leaving to the  
server-side elaboration the burden of a correct interpretation and  
manipulation).

Anyway, the impossibility to "directly" access a group of controls in a  
form, "and only that group of controls" through a DOM "canonical" function  
rests. A partial solution is found in DOM level 2, where the search is  
limited to form controls for xhtml 1.0 and thus elements outside a form,  
whose name attribute acts as a fragment identifier sharing the same  
namespace as id attribute, but is meaningless in xhtml and preserved only  
for legacy, are discarded in favour of control elements, whose name  
attribute is a "control name" in name/value control pairs (from here the  
ambiguity I've spoken about, being different the meaning of equally named  
attributes for different elements); but, since the scope of the name  
attribute for a control within a form element is the form element itself,  
that should be legal to give the same name to radio buttons in different  
forms, thus, by working at the top document level, and that is scanning  
the whole document, with no capability to distinguish between different  
forms, could not return exactly the desired collection. Because of this  
I've said I'd find useful to have another parameter, representing the  
desired form name, in the "getElementsByName" function, or to have a  
similar method in the HTMLElement interface, scanning only one element  
descendants, the same way I can find the "getElementsByTagName" method in  
both the Document and the Element interfaces operating in a similar way,  
or just in HTMLFormElement, being its control child elements the only ones  
with a meaningful, grouping shareable name attribute. However, I'm not yet  
asking for that, since I now the difficulties to obtain it just through  
this mean, and because I consider this another partial (but more precise)  
solution, since having to organize a certain form fields so to be able to  
access any meaningful group through DOM, I'd prefer to use a fildset with  
a declared id, possibly related to the form name (i.e.  
"formname.groupname"), so to have the "illusion" to force a strong typing  
suitable for my purposes. However, I'd like to clarify that my only aim is  
to discuss an aspect I consider interesting, starting from a previously  
formulated question on a concrete DOM application. Best regards.
 
 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f

 
 Sponsor:
 DVDNetRent: il primo noleggio on line senza spese di spedizione, per ricevere comodamente a casa i tuoi DVD preferiti!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=4631&d=22-3
Received on Wednesday, 22 March 2006 02:07:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:58 GMT