Kind of a follow-up to Should I write HTML or CSS first?

On a relatively large website, we are considering to use SASS and/or Bootstrap. From previous projects, there seem to be different ways to go about it:

  1. A framework (e.g. bootstrap) provides a bunch of css classes (esp for the grid layout). We may even add to that with our own reusable classes. We then create the html to use these classes.
    If we want to change the layout, we have to modify the HTML, not the CSS. A class for a sidebar would be like col-lg-3 instead of sidebar-left.
    I call this the "CSS first" strategy.
  2. We first create our HTML, using semantic classes. A sidebar would be classed sidebar-left, or even sidebar-first to not imply anything about how it will be displayed. Then we use custom CSS that targets this region.
    Probably using a SASS mixin for the grid column layout.
    If we want to change the layout (e.g. make the sidebar smaller), we modify the CSS, not the HTML.
    I call this the "HTML first" strategy.
    Usually we want to do this with "components", where parts of the page are independent of each other, and we avoid arbitrary deep selectors.
  3. Traditionally in Drupal (this is what we work with), a lot of the HTML is already provided by core and 3rd party modules. Traditionally, we would leave most of the HTML as it is, and then target it with ugly deeply nested selectors.
    This is also "HTML first", but without components. I try to avoid this pattern.
    Often the classes provided in the generated html are based on configuration living in the database, and created with the UI. So then we have CSS (=code) depending on stuff in the database. It would be more maintainable in the other direction, if stuff in the database depends on CSS.
  4. Content authors want to be able to add some special effects in their authored html (which is filtered, of course). E.g. wrapper boxes for images. We provide some classes that they can use.
    This would fall into the "CSS first" strategy, although it is a special use case.
  5. In a CMS, we might have some components that you can choose from the UI, to configure how something should be displayed. These components might have human names that show how it looks like, e.g. "slider", "grid", "blue box".
    Maybe this is again "CSS first".

The strategies 1. and 2. seem quite opposite to each other. I can think of examples where one or the other approach would be preferable. But I wonder if there are some general rules of thumb which approach is better, or where to use which.

It seems a main difference is whether I prefer to update the HTML or the CSS, if I want to make a layout / appearance change.

This also leads to the question of how "semantic" your class names should be.

  1. With the "CSS first" approach, I would write CSS for a class "shiny-blue-button" and another "shiny-red-button". If I want to change the appearance, I will change the HTML to use the red button instead of the blue one.
  2. With the "HTML first" approach, I would write HTML with a class "panic-button" and another "submit-button", and then style them accordingly. Here the classes are way more semantic, but much less reusable.

See also Cogent arguments for 'semantic css' over 'object oriented css'

  • 1
    In terms of class name semantics, overly-specified class names can just mean a headache when it comes to maintenance. Somebody on a project I was working on lately used 'red' as a class name on a span within a heading, obviously to highlight the word. We had to 're-skin' the site and swap out the primary red colour for a blue, which meant any occurrences like this needed a manual find and replace. It was hardly hell on Earth, but it was the result of bad practice. Commented Jul 17, 2015 at 9:13
  • CSS first vs HTML first? Ask yourself, does your content holds more value or the way of presenting it? Commented Jul 17, 2015 at 9:41
  • 1
    @AbhinavGauniyal I don't really know why it would be relevant what is "more important". But the authored content, which I do care about, typically comes after the CSS is already in place..
    – donquixote
    Commented Jul 27, 2015 at 12:16

3 Answers 3


Your 'HTML' represents the elements that corresponds to the DOM. As your CSS is applied to these elements to create the layer of presentation, it would be like coloring before sketching. I would use HTML to define the individual elements of page, without style first. When their behavior works to pass the testing, I would start using CSS. The behavior usually asks for a dynamical use of classes - like :hover or a certain state or theme.

To answer your question: define HTML before CSS, in my opinion.


After having spent more time thinking about this, I come to the following conclusion:

HTML first, or CSS first?

The "html first" is misleading advice, imo.

The good way is to think about classes and tag names as a protocol or language for html to communicate with or to the CSS. A language or protocol is an agreement between two sides.

Even if technically you might be writing the CSS first, or the HTML first, you always have both sides in mind when you invent new class names. When writing CSS first, you are simultaneously writing HTML in your imagination. When writing HTML first, you are simultaneously writing CSS in your imagination.

Or if you are writing CSS components with a HTML style guide (HTML example snippets), you are actually writing both at the same time, even technically.

Even if, by this philosophy, you are always doing both at the same time (just one in your head), there is a difference:

On the one hand it can happen that your "protocol" (classes and tag names) expresses internal implementation details, e.g. about components of your CMS or server-side framework, or your content architecture, instead of visual or functional hints. To style such elements with CSS, you need unnecessarily complex selectors and overrides, which end up being painful to maintain. (I have seen this a lot in Drupal 7 sites - although there are clearly ways to avoid such problems in Drupal).

On the other hand, it can happen that your protocol is too focused on specific styling, e.g. if your classes encode specific colors or fonts.

Ideally, the protocol should be somewhere in between. The HTML side should not need to know too much about styling details, and the CSS side should not need to know too much about server-side content architecture and framework details.

Additional thoughts

The following might not be 100% related to the original question, but they come up when thinking about this stuff.


You sometimes want to package HTML and CSS into a module which you can share across projects. In this case yes you can use a CSS namespace (prefix) for this package.

By installing the package, you get HTML (or HTML-generating code) and CSS at the same time. Of course you might want to override or replace the CSS for your specific project.

Content vs CSS

Do you allow content editors to use CSS classes? In this case, the rule should always be "CSS first". Or rather, you tell the editors which CSS classes are available.

You do not want to write CSS to target classes invented by content editors.

No matter what you think about the original question, CSS is still code, and content (or data) (not content structure, but the content itself) should always come after code. You do not want code to depend on content or data. This rule beats any "HTML first" rule that you might have.

Of course you could say the content editors are not really writing new HTML, they are just combining HTML components that already exist.


After a long time, I have to give another answer, reflecting my current perspective, and perhaps a changing trend in the industry.

TLDR: This answer boils down to "CSS first, HTML second".

Utility-first CSS

There are some modern CSS frameworks like Tailwind or Tachyons that follow a "utility first" strategy. This clearly follows into the "CSS first" category. Recent versions of Bootstrap (esp bs 5) also provide utility classes.

A utility class usually sets a specific CSS property on the element that has the class, without having any effects further down the DOM. So it is the most atomic kind of class.

I recommend a blog post by Adam Wathan that describes the transition from "Semantic CSS" with html first through "Component CSS" to "Utility CSS". I really recommend to read the full article!

The essence:

The philosophy that leads to the "html first" dogma, as well as the work flow that results from it, are flawed:

  • If CSS classes describe the content structure, we would then write CSS that targets e.g. a "News article". This implies that a news article always looks a certain way, whereas a blog post might look differently. In reality, there could be different displays of news article and blog post, and a news and a blog post using the same display might look quite similar.
  • On a dynamic website, the content itself but also the content structure can change. With a "html first" strategy, each change in the content structure would require an update of the CSS, and also leave behind orphan CSS.
  • We are lying to ourselves if we think that our made-up class names are "semantic". Getting rid of "useless abstractions" actually makes things simpler.

If CSS targets content-agnostic components, then we are already in a "CSS first" world. On the other hand, a component usually expects a very specific html structure, so we end up with a system of limited flexibility.

Utility-first CSS is the consequence of breaking the components down to atomic reusable parts.

The only challenge is that you need to take full control of your html. This can be difficult with some systems, but it is ultimately worth it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.