WordPress.org

Make WordPress Core

Opened 13 months ago

Closed 13 months ago

Last modified 13 months ago

#23868 closed defect (bug) (wontfix)

Twenty Eleven: Multiple search forms should increment ids

Reported by: 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 13 months ago.
23868-2.patch (1.6 KB) - added by WraithKenny 13 months ago.
23868.2.patch (1.9 KB) - added by WraithKenny 13 months ago.
back-compat
23868-2.2.patch (1.9 KB) - added by WraithKenny 13 months ago.
back-compat
23868-3.patch (5.7 KB) - added by WraithKenny 13 months ago.
23868-4.patch (5.2 KB) - added by WraithKenny 13 months ago.

Download all attachments as: .zip

Change History (17)

WraithKenny13 months ago

comment:1 WraithKenny13 months ago

Patch works with the patches on #16539

WraithKenny13 months ago

comment:2 WraithKenny13 months ago

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

WraithKenny13 months ago

back-compat

WraithKenny13 months ago

back-compat

comment:3 SergeyBiryukov13 months ago

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

comment:4 obenland13 months 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. :(

comment:5 follow-up: SergeyBiryukov13 months 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.

comment:6 in reply to: ↑ 5 obenland13 months 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.

WraithKenny13 months ago

WraithKenny13 months ago

comment:7 MikeHansenMe13 months 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.

comment:8 WraithKenny13 months 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.

comment:9 bpetty13 months ago

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

Last edited 13 months ago by bpetty (previous) (diff)

comment:10 WraithKenny13 months ago

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

comment:11 SergeyBiryukov13 months ago

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