id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
18698,Use body class in custom background callback,GaryJ,markjaquith,"When themes want to include an alternative color scheme, they might make use of a body class, added via a choice on a theme settings page. They can then do:
{{{
body {
    background: red;
}
...
body.grunge { // or .grunge
    background: black url(images/grunge.png);
}
}}}

The problem comes when the theme also adds support for custom backgrounds.

The lowest selector specificity score an alternative color scheme could have using this method would be 11 (`body.grunge`) or 10 (`.grunge`).

The default custom callback CSS just uses `body` (specificity score of 1), which means even though it's an internal style sheet, and later in the cascade, it doesn't override the external style sheet.

There are two options:

1) Have all themes that want to use custom backgrounds and alternative color schemes define two extra functions - one that adds a body class `if ( get_background_image() || get_background_color() )` is true, and a second which duplicates all of the `_custom_background_cb()` function with a tweak of the output selector to include this new class, and then use that as the admin callback.

2) Have WP add a 'custom-background' class within `get_body_class()` and use that within `_custom_background_cb()`.

Certainly 1) is possible now without any changes to core code, but it does mean duplications of core code, just to change the CSS output (perhaps a filter on the selector, default `'body'` might work instead here?), and that, along with a filter to add a body class, seem redundant when it could be done in core. Most of the default body classes are content-related (type of page, template used, queried object etc.), but there are ones that are feature-related (admin-bar, logged-in), so custom-background isn't something too different.",enhancement,closed,normal,3.3,Themes,3.2.1,normal,fixed,has-patch,ncrice@…