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

[Edward Caissie]

Somehow I missed a lot of emails in this thread making my last rather
redundant.


Cais.


On Mon, Jun 11, 2012 at 8:36 PM, Edward Caissie <edward.caissie at gmail.com>wrote:

> The use-case I was describing actually affects one of my clients with a
> Child-Theme that pre-dates the custom background additions ... granted I
> happen to like this client and will be more than happy to add the few lines
> of code to sort this out to current "standards" (at no charge ... it is a
> Five-Minute-Fix after all); and, I am willing to accept I should have
> addressed this in all client Child-Themes months ago, but ... if it works
> you don't fix it.
>
> Which leaves the dilemma, do I implement custom-backgrounds as you (@Otto)
> are recommending whereas I set the default I have chosen for the theme, and
> let the chips fall where they may ... or do I continue with not setting the
> defaults and leaving the background styles in the stylesheet where they
> have been from the theme's inception.
>
>
> Cais.
>
>
>
> On Mon, Jun 11, 2012 at 8:05 PM, Otto <otto at ottodestruct.com> wrote:
>
>> 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
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> 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/364410bd/attachment.htm>