Extending body classes

[natejacobson]

As a part of trying to enable as much site design and themeing as possible to take place without overriding templates and digging into code, I plan to extend Wordpress' default body classes in two ways: 1) add classes that group sections and types of pages and, 2) add a randomizer to enable the illusion of a diversity of backgrounds and elements without having to touch each page. Below is the code I'm using to achieve these two aims.

// Extend Body Classes
add_filter( 'body_class','spine_extend_body_classes' );
function spine_extend_body_classes( $classes ) {
    $speckled = 'speckled-five'.mt_rand(0,5).'-ten'.mt_rand(0,10).'-twenty'.mt_rand(0,20); // Add Randomizer
    $classes[] = $speckled;
    $classes[] = 'spine-section-slug-'.spine_section_slug("section");
    $classes[] = 'spine-sub-section-slug-'.spine_section_slug("subsection");
    $classes[] = 'spine-page-slug-'.spine_section_slug("page");
    return $classes;
}

Variability

The randomizer allows for different levels of variability using advanced css selectors. So, for example, if you wanted to provide five random page backgrounds, you could target:

body[class*="five1"] { background: url(); } 
body[class*="five2"] { background: url(); }
etc.

For greater variability (using a random number between 1 and 10)...

body[class*="ten1"] { background: url(); } 
etc.

The random/variable class looks something like:

body class="stippled-five4-ten8-twenty14"

Similarity

The extended classes also include a top level section class, a second level subsection class, and a current page class. All of these use the slugs at each level. Another approach might be to use menu hierarchy instead of page hierarchy. The body classes appear as follows (also friendly to advanced css selecting):

body class="spine-section-slug-yoursection spine-sub-section-slug-yoursubsection spine-page-slug-yourpage"

These classes should enable assigning a color, a particular background, or whatever to a whole section of a site.

Question

I'd like to refine these extended classes to meet any unanticipated needs.

What are some other body classes that you regularly find lacking that, if present, could serve other designers and help you stay in CSS/JS and out of custom page templates?

[natejacobson]

As for getting pseudo sections... this is an interesting approach that is content-type agnostic.

http://wordpress.org/plugins/add-url-slugs-as-body-classes/

Also, for reference...

http://www.wpbeginner.com/wp-themes/wordpress-body-class-101-tips-and-tricks-for-theme-designers/

[jeremyfelt]

Only because I was wondering and it's slightly applicable, per this SO answer:

• The limit on an attribute value in HTML4 is theoretically 65536 characters.
• HTML5 apparently has no limit.

So no worries there. 👍

It's also worth noting the default body classes that do appear in various WordPress views: https://codex.wordpress.org/Function_Reference/body_class

And as a general example of what the latest default theme in WordPress, TwentyFourteen, has done—there's this

[quantumJLBass]

There is a practical note on class chaining which is that it does take longer to process a page if there are large number of combinations classes to use. The same can be said on id's too but that SO may not be as accurate too, it seems the SGML parser is not used on the classes. http://www.w3.org/TR/html401/struct/global.html#id-and-class

The parser is not that only reason for keeping the number of classes and id down in DOM, the indexing that happens is stored in memory, and it can get pretty big with a lot of class chaining. You can feel the effects when you look at a page with in inspectors, but there is a simple parallel that we can draw. Think of a search engine, if there is a lot of indexed items it runs slower then an near empty one. Also if there is a lot of JavaScript usage it could slow that down. We are talking nanoseconds but it's important to keep things as light as possible as habit.

Just some thoughts for ya, but I would agree with Jeremy on making use of the default WP per page bode classes. Oh and one more thought, the randomizer, I am doing near the same thing on the stores by default. What I'm doing is something like

$randomClass = 'five'.rand(0,5).' ten'.rand(0,10);

The reason why I was not joining them in one string is that like having to many identifiers can slow things down, to many wild cards can have that same effect. So I tried to avoid

body[class*="five1"] { background: url(); } 
body[class*="five2"] { background: url(); }

for

body.five1 { background: url(); } 
body.five2 { background: url(); }

because that will process faster as you don't need to use regex on the whole of the list of classes stored for the DOM. Just some thoughts here.

[natejacobson]

Thanks for the thoughts, guys. With respect to the Wordpress body classes, it's true they cover types and templates, but not sectioning. I definitely won't redundantly replicate the classes provided by Wordpress. The twentyfourteen body classes seem to be mostly targeted at theme specific design options.

I'm pretty indifferent to separating the randomizer classes. I was primarily conjoining them to avoid any possible namespace issues, but really, classes like .five4 and .twenty16 should be fine.

[natejacobson]

Url-based and page-parent-based have made it to functions.php. The random classes are no longer chained, which as I've thought about it more is much better.