Bad UX with default background color

[DrewAPicture]

As (sort of) noted in #22030, when you clear the background color option in the Customizer and/or Background settings, the hex value is still output on the front end, which is expected behavior. But the options in the Customizer and/or Background color pickers still register as being empty.

It would be nice to auto-fill the background-color options based on the theme's default color if none is set.

This isn't specific to TwentyTwelve really, as any theme can set a default background color, but it might be a good test case.

Related: #21226, #22030

[Ov3rfly]

The inline css in front end

<style type="text/css" id="custom-background-css">
body.custom-background { background-color: #e6e6e6; }
</style>

should not be included if a custom background-color in Design -> Background -> Color was never saved or has been reset with the "clear" option there.

Actually the "clear" option would be pointless otherwise.

Having that inline css there even if "cleared" in backend could override edited theme background-colors in style.css or via third party front end color-theme switchers in functions.php or similar and cause confusion.

My advise: No/empty/cleared setting = no extra inline css.

[DrewAPicture]

Replying to Ov3rfly:

The inline css in front end should not be included if a custom background-color in Design -> Background -> Color was never saved or has been reset with the "clear" option there.
Actually the "clear" option would be pointless otherwise.

I think there needs to be an examination of the implications of themes setting default background colors.

• Does the default always rule, meaning if nothing is set then the default is used?
• Or does it only apply for when the theme is first activated?

If the former is true, then clearing it should have no effect other than to set the default and the UI should reflect that default as it current does not.

If the latter, then you're correct that the inline css shouldn't be there and the UI should reflect no setting as it currently doesn't as of r22080

[Ov3rfly]

I have investigated more, see updated #22030

In a new wordpress install, where no value has been set for custom background-color via backend yet, no inline css is added to front end html, as expected.

[Ov3rfly]

So if no value is set in backend, or has been "cleared" with the "clear" option (which is there for a reason) in backed, and if there is no add_theme_support() for custom-background in theme functions.php file, the default color from style.css should be used, and no inline css should appear.

[nacin]

History: #20132, #20448, [21054], etc.

[MikeHansenMe]

Just to clarify on this ticket. The current behavior in 3.5-beta2-22252 is as follows.

add_theme_support( 'custom-background' );

results in no single line css in the head and "Clear" button in customizer.

example from Twenty Twelve

add_theme_support( 'custom-background', array('default-color' => 'e6e6e6',) );

results in single line css in the head and "Default" button in customizer.

This seems like expected behavior to me.

[DrewAPicture]

Somewhere along the way this must've gotten worked out.

The originating behavior was that on a vanilla install with Twenty Twelve as the default, the body background-color was being output (in this case) as #e6e6e6, but it wasn't being reflected in Appearance > Background settings nor in the Customizer.