By Jon Cuthbert

Title CSS: A Simple Approach to CSS Class Naming

By Jon Cuthbert

If you are like me then you spend way too much time coming up with the perfect class name for an element. You might Google for synonyms or imagine what this element would be if it were a real life object. You know that any semantic name will work, but somehow trying to think up the perfect name seems worth it.

To be honest, the perfect name won’t help your stylesheet all that much, but utilizing a CSS methodology could make a big difference.

Examples of CSS Methodologies

OOCSS is environmentally-friendly advice helping you write sustainable classes through recycling styles.

SMACSS is an all-encompassing CSS game plan that will coach you through all the proper techniques.

Idiomatic CSS is an analytical house cleaner, organizing everything in uniform for easy recognition and peace of mind.

And BEM? Well, BEM is the gold standard of CSS class naming of which all CSS class naming schemes are measured against.

So Why Any More Talk About Class Naming?

The BEM approach is about writing scalable CSS with an emphasis on readability and avoiding collisions. In short, BEM stands for Block__Element–Modifier. The Block is an element that encompasses a small chunk of related elements (in SMACSS it is called a module). The Element is a descendant of the block and normally wouldn’t exist without the presence of the block. The Modifier controls the state of the block.

In BEM, you write a normal class name for the block, and for any element you copy the block name and append the element name.

Conventional BEM looks like this:

<div class="block block--modifier">
    <p class="block__element">

This is good because anyone will understand that “block__element” relates to “block” and there is little chance the class “block__element” has been used anywhere else in the project.

But there is a problem with this approach. You write CSS all day and you do not want to write long class names that muddy up your clean markup.

Title CSS is about giving you the benefits of BEM without adding any prefixes or special characters to your class names.

The Trick to Title CSS is Simple

Using Title CSS, you’d do the following: For any global CSS class, use a capitalized name (title case). For any modifier or descendant class, use a lowercase letter for the beginning of th name.

This means with Title CSS you capitalize any class name that will get referenced in the stylesheet without a parent class. This means even the objects in OOCSS get capitalized. The distinction is simple; anything that is capitalized in the stylesheet must not be used again.

Here is an example of how the markup would look when using Title CSS:

<div class="Title isModified">
    <p class="descendant">

And here is how the corresponding CSS would look:

.Title {}
    .Title.isModified {}
    .Title .descendant {}

Why Title CSS Works

Block identifiers or “Title” classes create a scope for all the descendent classes within the block. Descendant classes can be repeated in other Title blocks without style collision.

This is not vital for the methodology to work but since HTML class name are case-sensitive, “Title” classes are also free to be repeated as descendant classes.

How Does Title CSS Help?

With the Title CSS methodology, you’ll see the following benefits:

  • Write CSS classes in a more natural manner.
  • CSS selectors resemble the written language, like English sentences that start with an uppercase letter.
  • Shorter class names are faster to type and easier to scan.
  • Title case classes are easy to spot in the markup; to see what a lowercase descendant class belongs to, just traverse up the nodes for a Title class.

A Pitfall and Workaround

Title CSS may have issues when you use a Title block to contain other blocks. If a containing Title block has the same descendant selector class as one that it envelopes than there will be a conflict, in which case you should use child combinator in Title blocks that act as containers.

To demonstrate the issue, below is some sample markup with the problem present:

<div class="Container">
    <header class="header"></header>
    <main class="body">
        <section class="Title">
            <div class="header"></div>
            <div class="body"></div>
        <section class="Title">
            <div class="header"></div>
            <div class="body"></div>

And the accompanying CSS:

.Container {}
    .Container .header {}
    .Container .body {}
.Title {}
    .Title .header {}
    .Title .body {}

Notice that the styles applied to the .header and .body elements inside .Container will also apply to the other .header and .body elements nested further. To avoid this, here is the solution:

.Container {}
    .Container > .header {}
    .Container > .body {}

With a selector that uses the child combinator (>), the styles will apply only to the direct children, and not to the further nested elements that have the same class names.

A Word About Sass

Pre-processors provide an excellent way to write Title CSS. The nesting ability allows you to identify Title blocks easily in the stylesheet.

Here is a Title CSS example in SCSS:

.Title {
    &.modifier {}

    .descendant {}

    > .tightlyBound {}


As BEM, SMACSS, and OOCSS would suggest, it is important to keep the blocks or modules small. There are performance and maintainability benefits to include only elements that are closely related to the Title class.

If you have any observations or feedback on Title CSS, I’d be happy to hear them in the comments. And if you’d like to get more information or want to collaborate, be sure to check out the GitHub repo for Title CSS.

  • Other than the caveat you mentioned, I think there is one more caveat: selector specificity. I think that BEM was specifically designed to eliminate the issues related to selectors having too much specificity, which makes it difficult to override styles.

    What I really like about your approach, though is the possibility for global styles for modifiers and descenders. Often times modifiers of the same name exist in multiple places and they bring largely the same style changes, so you could have a `.inverse` modifier that makes the background dark and the text color light, which you can set in a single rule and apply it to all blocks and elements that use that modifier.

    The same holds true for descendants. Many block types will have a `.header` element, and you can set global styles for it, like bold font, though usually headers will be in an H1-6 tag which should do this anyway, but you can see the point.

    One thing that I would do to help distinguish modifiers from elements in the stylesheet though is give a prefix to modifiers. Maybe just a simple underscore or `mod-`.

    • Jon Cuthbert

      Thanks Joe!

      I agree, it is very important to not make selectors too specific.

      If you want to use modifiers or descendants globally then you are really describing another module or object and I would suggest capitalizing it.

      Thanks for your suggestion, I also think it’s helpful to distinguish modifiers from elements. My suggestion is a little more subtle as I would prefix them with “is” or a short preposition (.isActive, .of5).

      • What I mean by a global modifier is something similar to some of Bootstrap’s “helper classes” (, which is used on many elements to modify some bits. This wouldn’t make sense to be made into a block, since it is a modification that can be applied to many blocks or elements.

        Also, I think using a preposition prefix to mark modifiers is just silly. Modifiers aren’t always something than can rightfully be prefixed this way, and using a syntax character (like _, -, etc.) is clearer to the meaning and easier to spot in the source code. Then again, I’m one of those people who prefers C-like programming syntax versus Ruby syntax.

  • Nathan Jessen

    I don’t necessarily like the workaround you provided. While it does provide a solution to the problem, what happens if your markup becomes more complex (due to crazy “creativeness” of designers) and you can no longer use a strict, semantic structure. For example, wrapping your header (.Container > .header) in a div. The child combinator will no longer work for the header in .Container since now it is .Container > div > .header. The great benefit to the BEM approach is that the styling applied to a child element, .block__element is that it isn’t completely tied to the structure of the html. You can still add stylistic div’s and it won’t break the page.
    I like the overall idea though, I just think there might be a piece missing. Or maybe the approach has best-use scenarios such as styling a minimalistic website with a great semantic structure.

    • LouisLazaris

      I tend to agree with your last statement, that this would probably be a nice way to write your classes in a small-ish project.

      But as for what you said about changing the structure… Sure, that is possible, but my feeling is it would be so rare that would happen. With CSS3 and pseudo-elements, it’s very unusual to have to go back and add extra wrapper elements. Maybe I’m wrong, but that’s just my thoughts.

      • Roman

        We can’t rely on CSS3 yet. Older browsers are still popular enough.

        • LouisLazaris

          People using IE8 won’t know what’s missing, it’s decorative. See:

          Graceful degradation takes care of the older browsers, and you can safely use any decorative features.

          Now as for JS and DOM features, that’s a different story, some people can’t use those yet.

          • Roman

            Those people would be seeing a crappier site, and I wouldn’t like that to happen.

          • LouisLazaris

            In some cases, you’re right. For example, a client might insist it looks the same.

            But in a lot of cases, it doesn’t mean it’s “crappier”, it means it’s just not as great. In other words, the IE8 version should look good, but the modern browser version should look better. Neither of them is bad. After all, we’ve been making websites look good in IE8 for years.

          • akmjenkins

            Those people would be seeing a crappier site and I would like that to happen. Don’t expect to get the feeling you’d get when you drive a Porsche when you’re actually in a Ford. If you want the best experience, use the best browser.

            If you develop for the lowest capability browser, one of two things will happen:
            1) You’ll never get an A-plus experience because no old browsers can handle it or
            2) Old browsers will crack under the weight of all the polyfills that you have to use to try and shoehorn in your excellent experience and those browsers will end up being 10x worse than if you just served them a “not-all-features-included” experience.

          • Roman

            A client may want users of older browsers to have pretty UI too. This could be accomplished with images. Using CSS3 isn’t necessary.

    • Jon Cuthbert

      Thanks Nathan! Your hypothetical caveat is fair, but my suggestion would be that if you can add a “stylistic” div in between two element then those elements may not be related enough to be joined in a module. In this case we could use two global elements and capitalize them (.Container, .Header).

  • I think that topic could be described as beyond of professionalism topic. Who is care about reading css class’s name? However, It is good article.

    • LouisLazaris

      Everyone who’s ever used a CSS framework or methodology like BEM or OOCSS cares about class naming. In large projects, and when working with multiple developers, it matters a lot, so it’s not just a trivial thing.

      • TroyBatty

        Agreed – I have recently been charged with updating our web app to support white-label customization / different color-schemes that requires digging into over 50,000 lines of CSS that has very little structure or consistency in naming. So drawing attention to methods like this that help reduce the number of headshaped dents in my desk is extremely valuable.

    • Clearly every single front-end developer.

  • I realize this is a teaching tutorial and I believe it is important to mention that writing CSS with multiple concatenations like .Title.header, is slower than .title-header. Also using Capitalization in your CSS class names affects processing time.

    Great points about naming conventions!

  • This should by no mean be a reason not to use such a naming convention.

  • Ian Woodward

    “Capitalization in your CSS class names affects processing time”…picture or it didn’t happen ;)
    I could buy it I guess, but I’ve never seen any indication that it’s enough of a tax to not use capital letters for class names. I’m personally split on the subject because I prefer hyphens in class names, but the people running the company I work for use camelCase so for the sake of consistency I maintain their pattern.

  • Roman

    …using Capitalization in your CSS class names affects processing time”

    Who has told you that?

    • KOTRET

      what about the readers processing time? :)

  • One thing to note: If you’re creating a class inside another class, you should consider that maybe that child class could be written at the same level of its parent.

    It’s important to pay attention to how many child classes in a single rule you’re using (my threshold is 3). If you have too many classes in a single rule you’re defeating the purpose of CSS.

  • James Sinclair

    This looks rather similar to the SUIT naming convention: written by the very talented Nicolas Gallagher.

  • Sarah

    I still don’t quite understand what you’re trying to tell us above. It all sounds very confusing. Very interested in especially Title CSS but I’m still very confused about it.

  • Nice! I always knew how important class naming conventions were important but I never felt comfort using BEM, OOCSS or SMACSS because they kinda bloat your markup. If you don’t know BEM, for instance, you’ll be really scared when you see the markup in a big project. To have to teach the developer involved the whole method is just a no go for me.

    Title CSS seems to be – until know – the more humanized and readable naming scheme. I’ll try and use it in my next projects and see how far it can go.

  • I while I love the OOCSS design pattern and used it throughout Cascade Framework ( ), I don’t like either Title or BEM. Cascading is a very powerful feature in CSS that allows you to do very much with little code, yet the very purpose of both Title and BEM is to neuter the Cascade.

    The distinction between blocks and elements is entirely artificial. This is where both Title and BEM get it wrong IMO and eg. HMVC ( ) gets it right. Components should be able to contain other components that contain other components that contain other components etc… and this can only be done efficiently when blocks and elements are treated the same.

  • Maurice

    this seems like a good article. I just can’t quite figure out what you are saying.

  • Hoto

    Great article, thanks. I’m new to CSS and this helps alot.

  • I believe there are eternal naming basics [1] that already alleviate a lot of headache: do without, otherwise use functional names, or else generic names.

    I find the idea with Title CSS interesting, but worry that it requires class names where none may be needed otherwise. Can you comment on this risk, Jon?


  • Welles Lo

    Any well-known websites use BEM, other than Yandex?

    In BEM, each block on a page has their own css file, would this increase the page loading time?

    Many thanks!

    • In BEM, each component has it’s own parent (B), and likely exists in its own file, but you should 100% concatenate and minify before shipping to production.

  • Scott Romack

    This is awesome, BEM is too verbose. Whatever system you choose set it and stick to it and it will work regardless of the size of your site.

Get the latest in Front-end, once a week, for free.