- From: Calogero Alex Baldacchino <alex.baldacchino@email.it>
- Date: Wed, 22 Mar 2006 03:07:05 +0100
- To: www-dom@w3.org
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 UTC