The Top 5 Mistakes of Massive CSS

That’s correct.

The basic idea is that you avoid location-dependent styles. When you need to override your default heading styles, “h3.loud” is better than “#sidebar h3″.

Of course, this does mean you will sometimes be adding an extra class to your HTML. The benefit is that your CSS becomes predictable, as well as shorter and reusable.

My god yes. Number 1 mistake. Uh. Uh. Uh. Uh. Uh. Uh. Unbearable.

There are really two questions here:

1. Do I use an ID, or a class?
2. Do I use minimal HTML and longer CSS, or longer HTML and minimal CSS?

(1) For styling purposes, use a class. It’s not “extra html code”, because you need to use *something* — class or ID. Classes are reusable; IDs are not.

As Nicole says in the presentation, IDs are often useful in javascript DOM work (even with JS selector engines, getElementById has the advantage of being fast). But for CSS, IDs are very rarely useful; classes are almost always better.

(2) Using minimal HTML means that you have as few IDs and classes as possible, and as few semantically empty elements as possible (div, span). Advantages: your markup is “cleaner”, with slightly fewer bytes down the wire.

The downside of minimal HTML is that your CSS becomes complicated and massive. It’s difficult to write CSS in a modular fashion if you won’t allow yourself a few extra divs (e.g. as a module container) and classes (e.g. the module container’s class name).

Nicole’s approach is to *slightly* increase the markup, in return for short, reusable, and robust CSS. This is much better for performance and maintenance. Bear in mind that CSS blocks rendering, so the size of CSS files is much more important than the size of other assets (e.g. images).

I don’t understand why people get hung up on “table layouts without the table tags”.

In terms of layout, tables are great: they let you make a robust grid system. CSS methods for grid-based design have been quite fragile by comparison — until relatively recently, when solid CSS grid frameworks came out.

There are three problems with table layouts:

1. Bad semantics (saying something is a table of data, when it’s not)
2. Accessibility (many table layouts are hard to understand in a screen reader)
3. Performance (many table layouts prevent progressive rendering)

CSS grid systems have none of these problems.

Note that “non-semantic” doesn’t really matter: adding spare markup doesn’t affect the end-user at all. Nobody looks at your source code and counts the divs (I’m talking about real people here, not web geeks ;) ).

*Bad* semantics can matter, however, because you change the meaning of the document. Depending on how the document is accessed, this can affect the user’s experience.

It depends on the type of performance optimisation.

Some optimisations make the code less robust or harder to maintain. For example, unrolling loops in javascript can make them faster. In these cases, there are trade-offs to be made between performance and other aspects of code quality. Unless the performance improvement is huge, it’s usually better to aim for high-quality code.

The optimisations that Nicole is teaching are different. They are faster, but they also improve your code quality: it’s shorter, more reusable, easier to understand, and easier to maintain.

Learning to code CSS in “Nicole’s way” should actually *save* you a lot of time, especially on large or long-term projects.

google is your friend.

I agree with this. I feel elements should be styled a certain default way. Like “All H3′s will be 18px size, Arial Font, bold, and green” but then you should be able to add a class for exceptions like “my h3 is all these things, but if i have a class of ‘special’ on it, then give it a red color”.

I feel in general it’s best to start with a bunch of general rules for everything, then code for the “one offs” as needed by adding extra classes.

I tend to agree with you.

The entire concept of “Object Oriented CSS” irks me to no end, especially class based HTML/CSS.

There is nothing wrong with complex CSS. Design is a complex entity. Semantics, however, should not be complicated.
IMO, people are wont to really understand the Cascading aspect of CSS.
And you are also correct about the richness of CSS selectors. div#content > p > li + a[href="#"] may look complex, but if you are trying to target a very specific element, there’s no need to muck up its markup.

I’m curious as well as Kristiaan.

i set up a local test and this:

.media{overflow:hidden; overflow:visible; zoom:1; padding:20px; background: #eee; }
.media div { float: left; width: 200px; height: 200px; background: #9ed36c; }

<div class=”media”>
<div></div>
</div>

doesn’t seem to do anything.