Jens Oliver Meiert

HTML and Non-Script Styling

Published on Feb 21, 2012 (updated Feb 5, 2024), filed under , , (feed). (Share this on Mastodon or Bluesky?)

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

If you are to style a document differently based on whether certain technology is available, you should keep two things in mind:

  1. HTML itself is static. An HTML document doesn’t care how it’s manipulated. Any ID or class names you’re using by default, that is, directly in the markup and not added by scripts, should reflect that fact.

  2. Separation of concerns is important for maintainability. ID or class names should hence be functional or generic.

For pragmatic reasons, techniques like class=no-js nicely avoid script-related classes all over the code but do not follow these principles. class=no-js misses 1) by not stating what the document represents but what it does not represent. It misses 2) because it is technology-centric, or behavioral.

Let’s see what else could do the trick.

Separation of concerns is the best starting point to come up with styling and scripting solutions. The challenge with non-script styling, however, is that there is justification for a root level ID or class name for which it is more difficult to find a “functional” name, which hence suggests a generic name. Alas, generic names are harder to work with as they tend to be less obvious and understandable.

What developers can do to cater for non-script styling while at the same time separating concerns is to, for example, use their project name as each HTML document’s @id or @class. For that reason we’ve moved to using “google” on some of Google’s properties, while on my site I could use “meiert.”

Similar to “no-js,” one can then use that “project” ID (or class) to use scripting to change that ID to, say, “project-script” and do the following:

.example {
  foo: bar;
}

/* Matches only when scripting is disabled: */

#project .example {
  foo: baz;
}

While, due to aforementioned lack of functional naming options, there is a trade-off in terms of how understandable such names are, they confer some meaning (HTML documents are marked as “project” documents), they can be repurposed for other script or styling maneuvers, and they are less likely to require markup changes again (which makes them more maintainable).

Note that the situation is different for tools like Modernizr which don’t require to hard-wire any IDs or classes in the HTML. This is, as we know, useful: What developers should care most about is the markup—it requires much greater effort to spoil projects just by their style sheets and scripts.

About Me

Jens Oliver Meiert, on November 9, 2024.

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve been working as a technical lead and engineering manager for companies you’ve never heard of and companies you use every day, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)