WordPress.org

Make WordPress Core

Opened 19 months ago

Closed 18 months ago

Last modified 18 months ago

#22038 closed defect (bug) (invalid)

Bad UX with default background color

Reported by: DrewAPicture Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Appearance Keywords:
Focuses: Cc:

Description

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

Change History (11)

comment:1 DrewAPicture19 months ago

  • Cc xoodrew@… added
  • Keywords ux-feedback added

comment:2 follow-up: Ov3rfly19 months ago

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.

Last edited 19 months ago by Ov3rfly (previous) (diff)

comment:3 in reply to: ↑ 2 DrewAPicture19 months ago

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

comment:4 Ov3rfly19 months ago

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.

comment:5 Ov3rfly19 months ago

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.

Last edited 19 months ago by Ov3rfly (previous) (diff)

comment:6 nacin19 months ago

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

comment:7 MikeHansenMe19 months ago

  • Keywords close added

comment:8 MikeHansenMe19 months ago

  • Cc mdhansen@… added

comment:9 MikeHansenMe18 months ago

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.

comment:10 DrewAPicture18 months ago

  • Cc xoodrew@… removed
  • Keywords dev-feedback ux-feedback removed
  • Resolution set to invalid
  • Status changed from new to closed

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.

comment:11 helenyhou18 months ago

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