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

[Edward Caissie]

Here's the rub ...

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).

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.

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


Cais.


On Mon, Jun 11, 2012 at 3:20 PM, Philip M. Hofer (Frumph) <philip at frumph.net
> wrote:

> While I see  what you're saying, and it's very valid.  It is not the
> behavior that would be the most beneficial to creators.
>
> Keeping that in mind.   What do we do about child themes and defaults.
> Something should be written up explaining the "if defaults set in parent
> then all child themes must use defaults" or it won't work.
>
>
>
> -----Original Message----- From: Otto
> Sent: Monday, June 11, 2012 12:10 PM
>
> To: theme-reviewers at lists.**wordpress.org<theme-reviewers at lists.wordpress.org>
> Subject: Re: [theme-reviewers] Something we need to check for 3.4
> appearance -> background
>
> On Mon, Jun 11, 2012 at 2:05 PM, Philip M. Hofer (Frumph)
> <philip at frumph.net> wrote:
>
>> The simple thing about it is, if a custom background image and color is
>> not
>> used, then the CSS for it for custom-background and the class should not
>> exist.
>>
>
> False, entirely. If the custom background is defined in the them, then
> it's *always* used. A "no-background" selection is a perfectly valid
> selection by the *user* of the theme.
>
> If your method was used, then the user of the theme would have no way
> to use the custom background functionality to select "no background".
> Removing the class would allow the theme's CSS to come through
> instead. That is not the desired outcome.
>
>  Whatever default in the style.css of either the parent or child is
>> inconsequential and up to the designer.  Not the core.
>>
>
> If the theme defines custom-backgrounds to be used (remember, this is
> off by default, a theme must support custom backgrounds), then the
> theme should not be defining any "defaults" in the style.css at all.
> It's supporting custom backgrounds, it should have the defaults in
> that custom background support call.
>
> -Otto
> ______________________________**_________________
> theme-reviewers mailing list
> theme-reviewers at lists.**wordpress.org<theme-reviewers at lists.wordpress.org>
> http://lists.wordpress.org/**mailman/listinfo/theme-**reviewers<http://lists.wordpress.org/mailman/listinfo/theme-reviewers>
> ______________________________**_________________
> theme-reviewers mailing list
> theme-reviewers at lists.**wordpress.org<theme-reviewers at lists.wordpress.org>
> http://lists.wordpress.org/**mailman/listinfo/theme-**reviewers<http://lists.wordpress.org/mailman/listinfo/theme-reviewers>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20120611/bf474744/attachment.htm>