Reputation: 167
Is there ever a case (like some quirky browser) where a form input field's id becomes the key in $_POST, $_GET or $_REQUEST, instead of the field's name?
We were having trouble with a field where the ID didn't match the name. Changing the ID to match appeared to fix the problem. The issue was purely PHP parsing; no JS involved.
Coincidence?
Google returns no such thing...
A function (sorry, old php4 code) generates the field. Here's part of it
echo "<select name=\"$varName";
echo "_dd\" id=\"$varName";
echo "e_dd\">\n";
Removing the 'e' from that last line apparently fixed it. I didn't do it myself; someone here told me it fixed the issue. It didn't break every date field, it seemed to be an intermittent problem. That's why I immediately thought of some strange browser quirk.
Upvotes: 1
Views: 1073
Reputation: 23259
In XHTML 1.1 strict, id has replaced name and name is deprecated.
If your XHTML is sent using the HTTP Content-Type application/xhtml+xml (which according to standards, it must), then it is probable that a browser that goes by the standard to a Tee would use ids to populate $_POST in PHP, not name.
http://www.codingforums.com/archive/index.php/t-29229.html
See the XHTML 1.1 spec: http://www.w3.org/TR/xhtml-modularization/abstract_modules.html
Name attributes are only allowed in a, applet, frame, iframe and map elements. And any other element that just happens to have a name, must have an id of the same name.
Upvotes: 1
Reputation: 33921
Clean code is nice code :). Can you verify this doesn't work?
echo "<select name='".$varName."_dd' id='".$varName."e_dd'>\n";
It would be good to see the generated html too.
Upvotes: 0
Reputation: 655509
No, it’s the name
attribute that names the control field:
A control's "control name" is given by its
name
attribute. The scope of thename
attribute for a control within aFORM
element is theFORM
element.
Upvotes: 0