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

[WordPress Trac]

#16539: Duplicate search widgets cause ID conflicts
--------------------------+-----------------------
 Reporter:  solarissmoke  |       Owner:  azaozz
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  3.6
Component:  Widgets       |     Version:  3.0
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |
--------------------------+-----------------------

Comment (by bpetty):

 Replying to [comment:62 azaozz]:
 > Looking at 16539.10.diff, removing the id from <input type="search"> in
 html5 mode would break [#comment:44 older screen readers] (Jaws7). Since
 this is for the front-end, are we OK with that?

 The id is already removed in the HTML5 version committed to SVN.

 The HTML4 version in the patch chooses to use duplicate IDs, as opposed to
 incrementing (dynamically changing) IDs for the purpose of not breaking
 compat with themes/plugins (since it was using the same duplicated ID in
 3.5 and below) - see ticket:23868#comment:7. Basically it reverts the
 changes made earlier in this ticket to the HTML4 version so it behaves
 like it did in 3.5 and below. If Jaws wasn't broken in 3.5, it shouldn't
 be with 16539.10.diff.

 So, from what I gather here, older Jaws should be fine with the HTML4
 version in 16539.10.diff, and if theme designers care to remain compat
 with older Jaws, they will probably stick with writing HTML4 anyway rather
 than opting for the HTML5 version.

 For HTML4, either we break CSS/JS compat with themes/plugins by using
 incremented IDs, we break Jaws7 in IE6 by not using an ID, or we break
 HTML validation (and possibly JS) with duplicate IDs. It's one of those 3
 options. I'm inclined to stick with what was already broken broken before
 - option number 3.

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