Generated Semantic Classes

I’ve been working with Scott Allan Wallick on a WordPress theme he calls Minimalist Sandbox. One of the things we’re trying to do is create a rich semantic markup pattern that will make it easier to customize the blog with CSS alone.

For example, take the <body> tag. We know whether is_home or is_post or is_page by the time we render this tag, so why not drop some of this context into the body’s class? The distinction between “home” and “post” and “page” is simple and powerful. It utterly destroys the old widecolumn/narrowcolumn classes. A full-blown class list such as “wordpress author archive author-andy” also gives each author the ability to style their archives differently with just a bit of CSS.

We can do similar things to the post div class list: “post publish author-andy category-asides category-funny” gives you tremendous power to shape your blog’s presentation with CSS. You could have a different style for certain categories or authors, attach a headshot to each of an author’s posts, use :before selectors to congratulate visitors on their wise choice of browsers…

What’s more, this makes your semantic data accessible to javascript. You could use the classnames to place relevant ads in posts, collapse posts of a certain category according to the visitor’s cookies, attach category-targeted link submission buttons…

There are all manner of tricks you can play when you have the right information in the right place. If you think of any other information that could enhance the semantic value of a theme’s markup, drop a note right here.

Published by

Andy Skelton

Code Wrangler @ Automattic

16 thoughts on “Generated Semantic Classes”

  1. Month of the (single) post—not the most useful thing, but allows having (for instance) a calendar-like theming of posts according to the month they were posted. Likewise: Year of the post. And why not: day of the week.

  2. I think this is tremendous. I currently use a custom function to style the body tag. The more semantic control, the better.

  3. it’s a brilliant idea. i’ve put the body classes into action on my own blog already.

    a couple questions:
    1) doesn’t this require wrapping each post+heading+footer in an extra div that might otherwise be unnecessary?
    2) i see the brilliance in name the body and post divs semantically, but i’m not sure how that affects .widecolumn and .narrowcolumn
    3) is there really any semantically valid naming conventions for things like sidebars and bottomblocks that don’t imply graphic representation?

  4. @adam:
    1) no (on the contrary, the div that is currently classed .wide-/.narrowcolumn can be eliminated, and elements — like the post — be styled as childs of a body.home, body.single, etc.).
    2) instead of saying, in CSS, that a .widecolumn is, erm, wide, and that a .narrowcolumn is, erm, narrow, you’d say something like “body.home .column” is narrow and “body.single .column” is wide (being “.column” the div that is currently being classed .wide-/.narrowcolumn, but can be “.content” everywhere). the advantage in separating content from presentation is clear.
    3) some people use “extra”.

  5. 1. riiiiiiight, i get it now. *hangs head*
    2. .content (although better as #content) makes perfect sense, and is semantic.
    3. if users have control over that content via widgets, or html editting, naming like .extras, or .sidebar, or .secondary are all shaky. they are layout divs, and as such, i don’t see a real reason for their name to matter.

    i think semantic naming is brilliant for instantiated items like widgets, posts, comments, etc. but for layout items (other than #content), IMO, they’re rather extraneous. andy?

  6. I think this makes things clearer for the beginner—it’s reasonably easy to expect to draw a connection between the body.home declaration and the post tiles on the home page of the blog.

    This currently (and somewhat partially) will be implemented as a basic function in the functions.php file. You can read the particulars on my blog.

    3) I think for sidebars, a structure like <div id="primary" class="sidebar"> is semantic to the purpose.

    It’s in my revision to the Sandbox. (Ah-hem.)

  7. It’s in my revision to the Sandbox. (Ah-hem.)

    yeah, hurry that one up already😉

    .primary and .secondary could possibly be construed as semantic, but .sidebar is absolutely visual. the .extra is almost up for the task, but i’d say .tangent is a better compliment to #content.

  8. adam: Sure we could change .sidebar, and we might, but that’s not the point of this evolution. The point is to make WP’s rich semantic context available to CSS and javascript. That’s it.

  9. I love the idea of WordPress templates with a fuller set of XHTML hooks the CSS can grab on to. It seems like you’re proposing a sort of CSSzengarden of WP templates.

    We use this same idea in our SurveyGizmo survey tool with an “ideal” XHTML survey template and customizable CSS. We have found it very challenging to strike that balance between making it simple enough for the masses to use and flexible enough to allow crazy customization. Best of luck with the template, we look forward to see what you do with it!

  10. This sounds like a fantastic idea and makes a lot of sense. I wish I’d seen this post before I went and customised Minimalist Sandbox myself.

    Admittedly it’s possible to go overboard with CSS… I’ve reached a point where my CSS file is about 50% larger than the actual page. ;/

  11. Great Ideas. I can never leave my CSS alone, but I have some trouble getting pages to look exactly how I want them to. I will be trying some of these ideas soon. I especially like the idea of allowing an author’s picture to be used next to a post and the “congratulate visitors on their wise choice of browsers” idea. Don’t click the blue “e”!

  12. I agree with the comments here, by and large. It would be very cool to have some conventions that template authors could use if they wanted to make “WordPress modifiable”.

    I’ve actually used this sort of idea for a long time, but lately have been coming onto another idea — if we think of a web page as an application (and many of them are, what with all this AJAX fun that’s happening these days), the class of an element can be considered to be an application state.

    Peter-Paul Koch had an article on A List Apart about this that was marked “controversial”. I find it a really fascinating concept — element classes represent additional metadata that extends the meaning of the element in the context of your page/web app, and therefore represent something some what wider than simple hooks for visual effects.

    I’ve been working on a couple projects where I’m fully exploring the possibilities of a very rich and elegantly degrading interactions between backend code, generated XHTML, and Javascript. What I’m struggling with are modeling tools that let you conceptualize these interactions — I’m no UML master, but it seems to break down when I try to use it to create conceptual maps of my application behavior, because of the multitude of technologies and methodologies employed. However, I have found that it can be effective to represent block elements on the page as objects with properties derived from class information and additionally, with methods if you instantiate a Javascript object for that element.

    A final note — unless you want to mess around with actually creating a convention and parsing the text of your ids and classes, such hooks are fundamentally binary (hidden/not hidden being the most basic example).

Comments are closed.