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

Re: Radio button group

From: Calogero Alex Baldacchino <alex.baldacchino@email.it>
Date: Tue, 21 Mar 2006 03:21:34 +0100
To: www-dom@w3.org
Message-ID: <op.s6qrh8xacy4r00@xp-tiger>

On 2006/3/20 Garrett Smith <dhtmlkitchen@gmail.com> wrote:

> you should use getElementsByName

Yes, this is a good solution, and I have to admit I didn't thought to it,  
but generally speaking I believe that's not the definitive solution, but  
rather another workaround to what I consider a language (html) concern  
before than a DOM issue, and the concern is name attribute scoping in  
general and radio (as well as checkbox) controls grouping through name  
sharing in particular.

First of all, according to DOM level 2 html specification it seems that  
"getElementsByName(in DOMString elementName)" in HTMLDocument interface  
has different behaviours for html 4.01 and xhtml 1.0. In the first case it  
should return all elements sharing the same name in the whole document,  
thus an anchor element sharing the same name could be returned with the  
requested form control elements; such a sharing would be logically  
meaningless, but syntactically and semantically correct, being form  
controls and anchors (in this example) differnet things managed (by the  
browser) as different things, reguardless their name attribute. In the  
second case, the return value should be limited to form controls, but  
there is no way to scope the name and limit the research to a particular  
form through this method, having it just one parameter corresponding to  
elements shared name; furthermore, and this is true in both cases, a form  
control name semantic is scoped by each form, so controls sharing the same  
name in different forms (i. e. forms created through a sort of template or  
elaborated server side by a certain generic script, specialized by the  
form name) whould cause no problem in their management, neither server  
side, nor client side.

One could object that such situations might be rare or never happen, being  
logically quite meaningless, but the language itself allows this to  
happen, without any problem arising but in dom manipulation through  
document.getElementsByName (however, any problems might arise if controls  
of different types shared the same name, in example, but this would be -  
also - a developer's logic error). So I think it is a language concern, a  
side-effects question. Of course, mine is not a real problem notification,  
which wouldn't find here the right place furthermore, but a language  
examination born from a related DOM practical application, a  
clarification. Generally speacking, I think a control grouping based on a  
specific fields grouping element, such as the optgroup element for related  
options in a select group, or such as the select element itself, whould  
have been more "error free" and more suitable for directly searching  
through DOM functions.

Returning to document getElementsByName method, perhaps it might be  
improved by adding a parameter to limit the search to a particular elment  
discendents, or by adding a method with such a behaviour in the  
HTMLElement interface, the same way the getElementsByTagName is repeated  
both in Document and in Element interfaces. Lastly a question:  
HTMLCollection namedItem method should return a Node, thus a single  
element, but what about HTMLFormElement elements fild? Isn't it a  
limitation for name sharing controls? Furthermore: the capability to  
access a form control, as well as an array or collection of controls  
sharing the same name, directly from a form object elements fild is not a  
W3C DOM compliant behavior, is it?
 
 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f

 
 Sponsor:
 I migliori fun sound Jamba!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=4843&d=21-3
Received on Tuesday, 21 March 2006 02:21:51 GMT

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