XHTML validation of contact-form, double id's changed
ntiostle - February 26, 2007 - 18:33
| Project: | Drupal |
| Version: | 6.x-dev |
| Component: | contact.module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | patch (code needs work) |
Jump to:
Description
The validation of a drupal 5.1 site-wide contact-page looks like that:
Below are the results of checking this document for XML well-formedness and validity.
1. Error Line 85 column 52: ID "edit-name" already defined.
...ext" maxlength="255" name="name" id="edit-name" size="60" value="" class="fo
An "id" is a unique identifier. Each time this attribute is used in a document it must have a different value. If you are using this attribute as a hook for style sheets it may be more appropriate to use classes (which group elements) than id (which are used to identify exactly one element).
✉
2. Info Line 64 column 51: ID "edit-name" first defined here.
...text" maxlength="60" name="name" id="edit-name" size="15" value="" class="fo
3. Error Line 103 column 35: ID "edit-submit" already defined.
<input type="submit" name="op" id="edit-submit" value="E-Mail senden" class="fo
✉
4. Info Line 38 column 35: ID "edit-submit" first defined here.
<input type="submit" name="op" id="edit-submit" value="Suchen" class="form-submThe patch should fix that.
| Attachment | Size |
|---|---|
| contact.module_32.patch | 727 bytes |
#1
#2
I bet the search form causes this on a few pages with 'edit-submit'. I'd think we would want to change the search form instead.
What form is creating a second 'edit-name'?
#3
the search block and the user login block will both use the same ids as the contact form uses.
You can also break XHTML validation by just including the search block and the user login block.
#4
A temporary solution for contact and search: http://drupal.org/node/111719#comment-663318
#5
Speaking of which, why didn't the above issue solve the problem once and for all, centrally? I recall that code was committed to Form API in the end. If we're already rendering forms centrally, then we could also centrally take care that ids are either "uniquified" or custom ids are simply prohibited, with ids always being auto-generated. This could be an API change, but broken XML wellformedness (not the same as XHTML validity) is quite a critical bug.
#6
subscribing.
will there be a back port to 5.x?
tried to test if it is actually fixed in D6-rc3 but the search form is disappearing for the anonymous user even though the block is set correctly.
#7
Grant the permission "search content" to the anonymous user in admin/user/permissions.
Edit: I just did, and it is indeed fixed. Search form gets an "edit-submit-1" ID.
#8
thanks for the fast response. i am sleepy so did not even think about the permissions on my D6 test system.
i tested and yes it is fixed for D6. great!
what about D5 back port?
#9
And what about edit-name?
#10
looks ok. i only see two id's when login and search are shown.
id="edit-name"
id="edit-name-wrapper"
#11
I found the best fix for this here: http://drupal.org/node/243249
Very simple.