“Classy HTML”: A Speculative Design Pattern about Classes and Composition

This is a pattern about Classy HTML.

Classy

ooo posh

No, not THAT “Classy”. This “Classy”:

HTML

No, not THAT “HTML”. This HTML:

The Classy HTML Pattern

Pretty simple: Store important app state as classes in your root (“html”) element.

For example, consider a countdown app. Its significant (from a UI perspective) state can be summed up as being one of three things: “fresh” (app just started), “counting”, “done”. Your app is, in effect, a state machine transitioning between those states according to a set of rules. (Acknowledging that reality and subsequently managing those state transitions with JavaScript can also be an interesting problem ripe for a parsimonious design, but let’s just take that for granted here.)

You would set your HTML class as “fresh” to begin with, and then programmatically switch it over to “counting” or “done” as the app plays out.

Your CSS reflects it:

  1. /* We choose the default case to reflect the most common case, ie "counting" or "done" */
  2. html.fresh .welcomeMessage { display: none; }
  3.  
  4. html.fresh { background: white; }
  5. html.fresh .counter { opacity: 0.3; }
  6.  
  7. html.done { background: red; }

The important thing here is the selector idiom, which can be summed up as “html.state descendentSelector“. We’re styling our classes all the way down, based on the overall application state.

I haven’t done too much of this kind of design, but I can see myself doing more of it as apps get more complex and everything becomes single-state. I’ve been contemplating refactoring the Hacker News Reader along these lines, since (thanks mostly to Paul), it now has sliding panels, and so can effectively be in three states: stories, story (one story above the list of stories), comments (comments above one story above the list of stories).

I guess all this is obvious to CSS design pros, i.e. it’s a natural consequence of the CSS model, but I’ve not thought about doing it much and I mainly got the idea from this FOUC trick, which uses this pattern, but in a very restricted and specific way. The main insight really is that single-page apps usually have a small number of key states which can affect the entire UI.

As with any good pattern, it raises further questions:

  • Should you use “class” or an HTML5 custom “data-something” attributes. I think it’s in the spirit of HTML/CSS to use “class” to represent a state, so that’s fine. And CSS attribute-based support won’t work on older browsers, so that’s another tick for “class”. BUT custom attributes have the distinct advantage that you can be more precise about what kind of state you’re referring to. So while it could just be “data-state”, it could also be “data-phase” or (a boolean) “data-active”. Which takes us to the next question …
  • Should you use more than one type of state? I think for complex apps, yes. And you can then use custom data attributes to manage the type of class. Or you could just use them as a list of free-floating class names on the HTML tag.
  • Should you use multiple selectors, e.g. [data-phase="counting"][data-authenticated="false"] to be more precise? In general, I think no. It would lead to ridiculous combinatorial complexity, so it’s better to treat each state variable – if you must have more than one of them – as being orthogonal. That said, there are probably special cases where it makes sense and fortunately modern CSS makes it easy to pull off.
  • What’s the base case? Should it be the initial state or the “typical” state?
  • Looking at the bigger picture, when do you switch pages versus switch states inside the app?

9 thoughts on “Classy HTML”: A Speculative Design Pattern about Classes and Composition

  1. Pingback: Tweets that mention “Classy HTML”: A Speculative Design Pattern about Classes and Composition -- Topsy.com

  2. I built an app like this recently.

    It works nicely and makes it particularly easy to add style which reflects the current state of the application. Adding small tweaks at the end becomes particularly easy.

    Using multiple classes turned out not to be an issue. Even in situations where the state can only be derived from multiple classes. eg:

    .item.counting.notAuthenticated

  3. We’ve used this style for years using the tag as root.

    I think using a class makes sense because there might very well be CSS associated with the state.

    In Streamie I use an interesting variation: Here the URL fragment defines which tweets to show. When you enter an URL fragment it get added as a class in the body and the system dynamically generates CSS to hide all tweets except tweets with the same class as the string in the URL fragment if the class is present in the body.

    The body tag always felt more natural to me but now that you say use the HTML tag that kinda makes more sense. I was always thinking in terms of “the outermost tag of my current component”. This makes sense if the page as multiple components.

    Having an equivalence between className of the HTML tag and contents of the URL fragment might also be an interesting pattern.

  4. @malte – syncing classname and frag ID is a pretty interesting idea and would work nicely with the topic of the month, pushState.

    As far as “html” tag, I think most developers are used to treating “body” as root(me too in the past), but really why not the actual root element? Besides which, when it comes to CSS, we could always do with *another* intermediary element. (html { text-align: center; } body { width: 40em; margin: 0 auto; })

  5. Pingback: Full Screen Mode: Quick Notes

  6. Pingback: My Talk and Slides from jQueryTO | Impressive Webs

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>