php processing name vs. id field
in [General]
|
Prev: Past discussion
Next: Integers
From: Ashley Sheridan on 2 Jul 2010 09:01 On Fri, 2010-07-02 at 08:49 -0400, Bob McConnell wrote: > From: Ashley Sheridan > > > Not sure if my other email got through earlier. Replacing the name > > attribute on form fields with the id one is not feasible at all. They > > don't even behave the same. What would happen if you had two forms on > a > > page that both had an element with the same name? Using the name > > attribute, everything is fine, but not so if you were using the id > > instead. > > These conditions sound like a bugs to me. I can't imagine any reason why > different forms could have the same name or id. That applies to any set > of elements on a page. Each one must have a unique moniker, no matter > which attribute you use. Even the simple validations I use will complain > about your duplicates, as they should. Making them all unique also makes > it much simpler to use tools like Selenium or Silk Test to automate the > testing process. > > Looking at the HTML 4.01 references given earlier in this thread, I see > that id is now a core attribute, i.e. it is available for all but a > handful of tags, while name is only available for the tags where it is > explicitly included. So it still appears to me that id is the preferred > attribute, as it is more generally available. > > Bob McConnell > It's not a bug in the code. Imagine this scenario: <form name="product_filter"> <input type="submit" name="action" value="By Product Name"/> <input type="submit" name="action" value="By Product ID"/> </form> A valid form with two input elements given the same name, which sends a different value to the server depending on which button was triggered. Seems valid enough to me. Only one value is ever sent, so why do I need to give them unique names and further complicate my server-side code? Imagine further that there is another form on the page containing the product listings, and each one has a delete button. Now we all know the folly of putting things like delete code into an <a> tag, so a button will do the job: <button type="submit" name="action" value="pid_1">Delete Product</button> <button type="submit" name="action" value="pid_2">Delete Product</button> <button type="submit" name="action" value="pid_3">Delete Product</button> Perfectly valid, and something that is done a lot on apps I've seen and built. Giving each a unique name just gets in the way, as you need to use some sort of loop and pattern matching on the server just to get the data you need. ID is not a substitute for name on form elements. The reason name is only available for a few elements is because it has a specific use-case, which is not the same as the ID attribute at all. I never said the forms themselves would have the same name or id, but elements within them might have the same name, and two forms might have elements with the same name. If the ID were to be a substitute for the name attribute, then this could never happen, our scripts would become more complex, and all for no gain. Thanks, Ash http://www.ashleysheridan.co.uk
From: Peter Lind on 2 Jul 2010 09:14 On 2 July 2010 15:01, Ashley Sheridan <ash(a)ashleysheridan.co.uk> wrote: > On Fri, 2010-07-02 at 08:49 -0400, Bob McConnell wrote: > >> From: Ashley Sheridan >> >> > Not sure if my other email got through earlier. Replacing the name >> > attribute on form fields with the id one is not feasible at all. They >> > don't even behave the same. What would happen if you had two forms on >> a >> > page that both had an element with the same name? Using the name >> > attribute, everything is fine, but not so if you were using the id >> > instead. >> >> These conditions sound like a bugs to me. I can't imagine any reason why >> different forms could have the same name or id. That applies to any set >> of elements on a page. Each one must have a unique moniker, no matter >> which attribute you use. Even the simple validations I use will complain >> about your duplicates, as they should. Making them all unique also makes >> it much simpler to use tools like Selenium or Silk Test to automate the >> testing process. >> >> Looking at the HTML 4.01 references given earlier in this thread, I see >> that id is now a core attribute, i.e. it is available for all but a >> handful of tags, while name is only available for the tags where it is >> explicitly included. So it still appears to me that id is the preferred >> attribute, as it is more generally available. >> >> Bob McConnell >> > > > It's not a bug in the code. Imagine this scenario: > > <form name="product_filter"> > Â Â <input type="submit" name="action" value="By Product Name"/> > Â Â <input type="submit" name="action" value="By Product ID"/> > </form> > > A valid form with two input elements given the same name, which sends a > different value to the server depending on which button was triggered. > Seems valid enough to me. Only one value is ever sent, so why do I need > to give them unique names and further complicate my server-side code? > > Imagine further that there is another form on the page containing the > product listings, and each one has a delete button. Now we all know the > folly of putting things like delete code into an <a> tag, so a button > will do the job: > > <button type="submit" name="action" value="pid_1">Delete > Product</button> > <button type="submit" name="action" value="pid_2">Delete > Product</button> > <button type="submit" name="action" value="pid_3">Delete > Product</button> > > Perfectly valid, and something that is done a lot on apps I've seen and > built. Giving each a unique name just gets in the way, as you need to > use some sort of loop and pattern matching on the server just to get the > data you need. > > ID is not a substitute for name on form elements. The reason name is > only available for a few elements is because it has a specific use-case, > which is not the same as the ID attribute at all. > > I never said the forms themselves would have the same name or id, but > elements within them might have the same name, and two forms might have > elements with the same name. If the ID were to be a substitute for the > name attribute, then this could never happen, our scripts would become > more complex, and all for no gain. > Let's also not forget radio buttons that *by design* should have the same name - if they don't, they don't work properly. Regards Peter -- <hype> WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 </hype>
From: tedd on 2 Jul 2010 10:10 >At 2:01 PM +0100 7/2/10, Ashley Sheridan wrote: -snip- I agree with Ash 100%. There is an "id" and a "name" attribute for input (et al) tags -- that's html. I can use the attribute "name" for php and the attribute "id" for javascript and css because these are different languages with different scopes running in different environments -- that's the way it is. Each attribute can be accessed by a variety of languages with no requirement on any specific language to know what the other languages may, or may not, be doing -- that's logical. I can also use the same value for any attribute because there is no restriction on that either -- as well as it should be. So, what's the major beef here? Is someone objecting to having both "id" and "name" being legal attributes for a tag? If so, this is really not the place to submit a compliant. However, it is the place to see the error of that thinking. Giving the slightest bit of thought to dismissing the "name" attribute from tags should result in the realization that the act would break countless forms already in use. So the "beef" here is not well thought out, nor is it likely to happen. Arguments against using/dismissing the "name" attribute in tags is simply nonsense. Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com
From: "Bob McConnell" on 2 Jul 2010 10:53 From: tedd > >At 2:01 PM +0100 7/2/10, Ashley Sheridan wrote: > -snip- > > I agree with Ash 100%. > > There is an "id" and a "name" attribute for input (et al) tags -- that's html. .... > So, what's the major beef here? Is someone objecting to having both > "id" and "name" being legal attributes for a tag? If so, this is > really not the place to submit a compliant. However, it is the place > to see the error of that thinking. > > Giving the slightest bit of thought to dismissing the "name" > attribute from tags should result in the realization that the act > would break countless forms already in use. So the "beef" here is not > well thought out, nor is it likely to happen. > > Arguments against using/dismissing the "name" attribute in tags is > simply nonsense. This discussion began when I pointed out that the name attribute is deprecated in XHTML. This was later confirmed when someone pointed to the actual specification at <http://www.w3.org/TR/xhtml1/>, however there may be some confusion about the scope of the change. The applicable section is shown below. Apparently HTML 5 is planning to take a different path. Of course, nobody knows that for sure since the spec is far from complete and will likely be undergoing major changes for several more years. Bob McConnell -----8<------------------------------------------------ 4.10. The elements with 'id' and 'name' attributes HTML 4 defined the name attribute for the elements a, applet, form, frame, iframe, img, and map. HTML 4 also introduced the id attribute. Both of these attributes are designed to be used as fragment identifiers. In XML, fragment identifiers are of type ID, and there can only be a single attribute of type ID per element. Therefore, in XHTML 1.0 the id attribute is defined to be of type ID. In order to ensure that XHTML 1.0 documents are well-structured XML documents, XHTML 1.0 documents MUST use the id attribute when defining fragment identifiers on the elements listed above. See the HTML Compatibility Guidelines for information on ensuring such anchors are backward compatible when serving XHTML documents as media type text/html. Note that in XHTML 1.0, the name attribute of these elements is formally deprecated, and will be removed in a subsequent version of XHTML. -----8<------------------------------------------------
From: tedd on 2 Jul 2010 11:10
At 8:49 AM -0400 7/2/10, Bob McConnell wrote: >These conditions sound like a bugs to me. I can't imagine any reason why >different forms could have the same name or id Bob: No offense, but duh! I can imagine, try this: The first form asks for the user's email address. The input statement has the attributes of "name" and "id" and both have values equal to "email", such as: <input type="text" id="email name="email"> You have a css rule that styles the email input statement via "id" as the browser gets it from the server and presents it to the user. You have a javascript routine that does a live-check of the validity of the email address while the user enters the data. You have a php script that processes the data using "name" after the submission of the form. All of these are using name and id attributes from an input tag AND there is NO restriction as to what values any of these attributes can hold nor is there any restriction on what you call them, nor does any of this happen at the same time or even in the same stage of action. The css is delivered from the server to the browser, the javascript routine is triggered by the user entering data via his browser, and the php script is run after the user clicks submit. All of these happen at different times. The second form (to fulfill your "different forms requirement) simply repeats the email value (i.e., value="<?php echo($email); ?>" and awaits the user to confirm. End of example -- and that's done routinely. --------------- > Each one must have a unique moniker, no matter >which attribute you use. That's nonsense. Why would html require that php, javascript, and css use different values for different attributes? I don't think you've thought this out. --------------- >Even the simple validations I use will complain >about your duplicates, as they should. Show me any validation that requires no duplicates in attribute naming convention. --------------- >Making them all unique also makes >it much simpler to use tools like Selenium or Silk Test to automate the >testing process. Simpler for whom? >Looking at the HTML 4.01 references given earlier in this thread, I see >that id is now a core attribute, i.e. it is available for all but a >handful of tags, while name is only available for the tags where it is >explicitly included. So it still appears to me that id is the preferred >attribute, as it is more generally available. > >Bob McConnell Popularity of attributes is not an indicator of which is correct to use for all languages. It is only an indicator that the "id" attribute is more common, which has no point. The net is a collection of efforts and languages -- while you may want to reduce input statement (and other tags) attributes from allowing both "name" and "id" to just "id" the practice would be devastation on a global scale. Please rethink. Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com |