[theme-reviewers] Something we need to check for 3.4 appearance -> background

[Otto]

On Mon, Jun 11, 2012 at 6:43 PM, Edward Caissie
<edward.caissie at gmail.com> wrote:
> While its all well and good if the Parent-Theme implements the
> add_theme_support( 'custom-background' ) with default parameters set to some
> value but this then requires the Child-Theme must implement the same
> functionality if the background is to be anything other than the
> Parent-Theme's default (as noted by Philip).

That's not the case with the current code (post changeset 21054). That
changeset reverted the behavior to the same as 3.3. Which is, IMO, the
wrong behavior, but it is what it is, and what it is is 100%
backwards-compatible.

If a parent theme defines a default with add-theme-support, and the
default has been "removed" by the user, then whatever the child has in
the stylesheet will take effect. No "custom-background" class will be
added to the body_class.


> Again this is not really an issue for *new* Child-Themes but it will be an
> issue for existing Child-Themes ... how many installations will this affect?
>
> Unknown, but it also the reason why I advocated existing themes that
> implement the add_theme_support( 'custom-background' ) do so with no default
> $args being set so as not to "break" existing (and quite likely unknown)
> Child-Themes.

Themes that now add a new default-image where there was no
default-image before will be affected only if no custom-background was
ever chosen by the user and the child-theme did-it-wrong by defining
the default image via CSS.

*This is not a breaking-change*. The same thing can happen with 3.3
alone, if a parent-theme suddenly defines the BACKGROUND_IMAGE
constant, which does more or less the exact same thing and has ever
since custom backgrounds have been around.

Given that the parent theme already had custom background UI for users
to use, then I would hope it wouldn't affect anybody.
- If they used the UI to make background images, then nothing breaks.
- If the parent doesn't define a default-background in the future,
then nothing breaks.

In Phillip's case, he's saying that he's been making child-themes for
clients, and using the style.css to add background images instead of
using the custom-background UI of the parent theme. And yes, those
cases will be affected if-and-only-if the parent theme suddenly
changes to define a default-image. But this isn't new, if the parent
defined the BACKGROUND_IMAGE, then the exact same thing would have
occurred.

It's a timebomb that's always been there. Maybe the fuse is a bit
shorter now that theme authors can more easily define default-image,
but I don't see that as a reason to restrict the usefulness of the
feature to theme authors.


> Perhaps this falls into more of a PSA when using this feature, as it's not
> really a bug ... or is it?!

It's not a bug. It may be a lack of foresight by child-theme creators.


-Otto