[wp-trac] [WordPress Trac] #16539: Duplicate search widgets cause ID conflicts

WordPress Trac wp-trac at lists.automattic.com
Thu Dec 1 01:30:16 UTC 2011


#16539: Duplicate search widgets cause ID conflicts
------------------------------------+-----------------------------
 Reporter:  solarissmoke            |       Owner:
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Future Release
Component:  Widgets                 |     Version:  3.0
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |
------------------------------------+-----------------------------
Changes (by WraithKenny):

 * type:  enhancement => defect (bug)


Comment:

 @TechDagan: The subsequent `form` elements and `input[type="submit"]`
 buttons will be lacking unique `id` attributes but that's not what's
 important. The important thing (Which I think there was some confusion) is
 that all the `label` and `input` elements **will** have matching `for` and
 `id` attributes for accessibility. @azaozz and @kurtpayne were actually
 saying the same thing ;-)

 It also sounds like kurtpayne did somewhat extensive testing. As for
 concerns about styling breakage, the structure and IDs will be exactly the
 same for the first searchform (and apparently, no one is concerned about
 subsequent ones, lol). Worst case is a degradation of the "graceful" sort:
 styling may not be exactly perfect, but would still be usable. The trade
 off for that is fixing broken validation and accessibility (if duplicate
 input ids cause accessibility issues that is).

 For a theme to use CSS rules like `.entry-content #s`, `.widget_search
 #s`, and `#branding #s` when `#s` appears in those contexts
 simultaneously, is a bug in the theme itself (i.e. id's are unique). This
 shouldn't stop core from fixing its own bugs.

 Leaving it as is does more harm then good. Designers who understand this
 problem are forced to add wrapper elements (for styling) or implementing
 the patch in searchform.php themselves (for validation and accessibility).
 Fixing these bugs now, both in core, and in the default theme will allow
 designers to not jump through hoops to do the right thing, and show new
 designers how to do it correctly.

 +1 The patch looks good. I think I've demonstrated that this is actually a
 bug, not an enhancement, as on a default widget setup with the
 TwentyEleven Theme the search field appears 2 times on most pages, 3 times
 on the search results page, which can be considered expected behavior.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/16539#comment:29>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list