Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#23868 closed defect (bug) (wontfix)

Twenty Eleven: Multiple search forms should increment ids

Reported by: wraithkenny's profile WraithKenny Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Bundled Theme Keywords:
Focuses: Cc:

Description

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

Attachments (6)

23868.patch (1.8 KB) - added by WraithKenny 11 years ago.
23868-2.patch (1.6 KB) - added by WraithKenny 11 years ago.
23868.2.patch (1.9 KB) - added by WraithKenny 11 years ago.
back-compat
23868-2.2.patch (1.9 KB) - added by WraithKenny 11 years ago.
back-compat
23868-3.patch (5.7 KB) - added by WraithKenny 11 years ago.
23868-4.patch (5.2 KB) - added by WraithKenny 11 years ago.

Download all attachments as: .zip

Change History (17)

@WraithKenny
11 years ago

#1 @WraithKenny
11 years ago

Patch works with the patches on #16539

#2 @WraithKenny
11 years ago

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

@WraithKenny
11 years ago

back-compat

@WraithKenny
11 years ago

back-compat

#3 @SergeyBiryukov
11 years ago

  • Component changed from Widgets to Bundled Theme
  • Summary changed from TwentyEleven Searchform to Twenty Eleven: Multiple search forms should increment ids

#4 @obenland
11 years ago

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. :(

#5 follow-up: @SergeyBiryukov
11 years ago

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.

#6 in reply to: ↑ 5 @obenland
11 years ago

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.

#7 @MikeHansenMe
11 years ago

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.

#8 @WraithKenny
11 years ago

@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.

#9 @bpetty
11 years ago

I didn't catch this earlier in #16539, but MikeHansenMe brings 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

Version 0, edited 11 years ago by bpetty (next)

#10 @WraithKenny
11 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

#11 @SergeyBiryukov
11 years ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.