Twenty Eleven: Multiple search forms should increment ids

[WraithKenny]

Related to #16539 the searchform template should increment ids. CSS will need a modification for the id change.

[WraithKenny]

Patch works with the patches on #16539

[WraithKenny]

the second patch uses all the scoped variables, while the first only uses the counter

[WraithKenny]

back-compat

[WraithKenny]

back-compat

[obenland]

I doubt this will be feasible with the amount of child themes dependent on Twenty Eleven.
Twenty Eleven itself uses an id to style the searchform, chances are high that child themes do the same.

I'm really sorry, but I don't think there is a way to get that in without breaking stuff. :(

[SergeyBiryukov]

In 23868-2.2.patch​, looks like $search_form_counter should be incremented somewhere.

Replying to obenland:

Twenty Eleven itself uses an id to style the searchform, chances are high that child themes do the same.

The first search form would still have the same id, only subsequent forms may have some styles missing.

[obenland]

Replying to SergeyBiryukov:

The first search form would still have the same id, only subsequent forms may have some styles missing.

Exactly. With one searchform fix in the header, on empty search result pages, 404 pages, and sidebars, it would not be styled.

[MikeHansenMe]

I do not think this will be backward compatible. If a child theme styled a search field in the sidebar by using

ex:

#secondary #s{
    color: red;
}

their CSS rule would not apply since the id is now s-2.

I think Twenty Eleven was one of the more popular parent themes(I have seen) and this risks breaking all the child themes that reference #s.

[WraithKenny]

@obenland: it wouldn't be completely unstyled. They'd still get all general styles, and styles inherited via class name (with 23868-4). Any child theme that didn't target the duplicated IDs and any child theme that copied the searchform template, wouldn't be affected at all.

@MikeHansenMe: It is true that the hypothetical style you describe would no longer be applied. This is an error in the theme's css though. (I would not have thought that any theme would do such a thing, but core's own default did.) The problem is, that we shouldn't avoid fixing a bug in order to prevent some small style degradation.

While its always been wrong to use duplicate ids for various reasons (best practice, validation, JavaScript compatibility, over-weighted specificity, etc.), I've come across another reason: "duplicate ID errors are known to cause problems for assistive technologies" ​http://www.w3.org/TR/WCAG20-TECHS/F77.html .

Many sites (government) require WCAG validation by law. Luckily for them, the online scanning software almost always miss these errors, so they don't know that they aren't in compliance (I won't tell if you don't). And perhaps I'm somehow misreading the requirement (it's been known to happen).

Having said that, at least core has fix it by default, so the severity is lessened somewhat. It's now possible for sites wishing to clear up this error can switch to a different theme. New themes created from WP v3.6 forward will never style these duplicate IDs again (unless they follow TwentyEleven's bad example).

I'll leave it to others as to whether to close this bug as "wontfix". I, Of course, feel that it should be fix.

[bpetty]

I didn't catch this earlier in #16539, but obenland and MikeHansenMe bring up a good point here. If all the old IDs were only available for (child) themes and plugins in the first place, what's the point in leaving them in if we're going to break compatibility anyway? We might as well remove them entirely.

I think this needs to be re-addressed in #16539