Theme Customizer: Add "no-customize-support" class to the body tag by default

[kobenland]

I just stumbled across this comment for wp_customize_support_script():

It is also recommended that you add the "no-customize-support" class to the body tag by default.

And I thought: Let's!

Related: #20751, [20918]

Add 'no-customize-support' class to the body tag by default

First of all, why? What does this patch fix?

In JS: just replace the class don't add it, since it's already there.

Replying to scribu:

First of all, why? What does this patch fix?

In [20918] functionality was introduced to hide the 'Customize' link, when the customizer is not supported.

By adding 'no-customize-support' to the default body classes (when the admin bar is showing), we can be sure it is there and don't have to rely on Themes' best practice, we'd streamline behavior with the admin, where the class is also added by default and can shave off a bit from the JS.

The reasoning behind removing the class was to specifically separate the loader from the admin. koopersmith probably remembers more.

So this ticket can be closed as wontfix then, right?

#22052 was marked as a duplicate.

From #22052:

In order for hide-if-no-customize in the Toolbar to work, no-customize-support has to be added by default to the body classes. If there is Customize support, wp_customize_support_script() rewrites it to customize-support.

The loader was split from wp_customize_support_script() in r20918, which allows us to add the body class now. Not sure about the changes proposed in theme.php but the body class alone sufficed in my testing. See #20751.

In order for hide-if-no-customize in the Toolbar to work, no-customize-support has to be added by default to the body classes.

From my testing, this is exactly what wp_customize_support_script() does, on the front end as well. In IE 7, which doesn't support the customizer, the link in the Toolbar is not visible.

I guess the comment about adding no-customize-support class to the body tag by default is no longer relevant. 20896.3.diff​ removes it.

Adding no-customize-support by default is to handle flashes of should-be-hidden content before the JS in wp_customize_support_script() fires. Otherwise, content that is both .hide-if-customize and .hide-if-no-customize might appear by default, among other side effects.

But, since "Customize" appears in a dropdown in the toolbar, and therefore hidden on load, we're not worried about a flicker, and can let the JS handle it.

body class

Replying to nacin:

Adding no-customize-support by default is to handle flashes of should-be-hidden content before the JS in wp_customize_support_script() fires. Otherwise, content that is both .hide-if-customize and .hide-if-no-customize might appear by default, among other side effects.

But, since "Customize" appears in a dropdown in the toolbar, and therefore hidden on load, we're not worried about a flicker, and can let the JS handle it.

My intent is to allow for a graceful no-js fallback. no-js means no Customizer and it also means we can't rely on the JS to add the correct class for us. This is accounted for (unintentionally?) in the two other instances of Customizer links in the Dashboard because no-customize-support is added in admin-header.php. 20896.4.diff​ adds the body class for the front-end.

Conceptually, this makes sense. The original patch (20896.diff​) is solid.

Replying to DrewAPicture:

This is accounted for (unintentionally?) in the two other instances of Customizer links in the Dashboard...

It was intentional. Your reasoning is correct.

In [22107]:

Add no-customize-support to the body classes when the toolbar is showing. Allows for 'Customize' to be hidden when JS is disabled. props obenland, DrewAPicture. fixes #20896.

Related: #22103 - wp_customize_support_script() removes spaces separating classes