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

[Edward Caissie]

Eww ... further testing using the above ideas really isn't providing pretty
results.
I'll wait for the community in general to weigh in on this "feature" since
its not a "bug" (*grin*)


Cais.


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

> 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/2f998e4a/attachment-0001.htm>