Idiomdrottning’s homepage

CSS — Back to Basics

We had three things:

On the one hand, the document’s semantics (section, list, paragraph, link etc).

On the other, the document’s appearance (fonts, colors, layout etc).

Between them, the CSS, where the mapping between those other two things should live.

People make themselves really unhappy, and their lives really complicated, by wanting to somehow make the mapping between the HTML and the CSS be 1:1.

Instead, CSS is great as the layer that separates semantics and presentation so that they don’t have to be 1:1.

Using CSS classes (or custom HTML5 elems) is fine when and only when your document has unusual semantics.

Structural selectors are unfairly maligned. They are fine. Basically “anything goes” in the CSS.

Document Semantics

An HTML document is like a tree.

Don’t select a heading level because you think it looks nicer than another heading level. H6 should only be used as subsections in an h5 section, h2 only as subsections in an h1 subsection etc. Don’t skip levels.

Just put correct semantics in there. Ideally when you design your HTML you shouldn’t even get to look at the design, instead just view it in an outline viewer.

Presentation Semantics

This is fine:

i, em, cite {
	font-style: italic;
}

That’s an example of a mapping that’s not 1:1. Those three things have different semantics (as long as your HTML code is used for other things that just being rendered for display) but the same presentation.

The reverse, mapping one type of semantics to different styles depending on context, parents, siblings etc is also completely fine. Learn the selectors and use them.

It’s fine to style some h3s differently than others, depending on context.

This is what CSS is for.

OOCSS…!?

We had two layers (semantics + presentation) and a glue layer between them (CSS). Life was simple.

But with the OOCSS model, we needed three layers. Semantical HTML, semantical CSS (“Structure” CSS), presentational CSS (“Skin” CSS)—which means two glue layers.

Arguably in the OOCSS model, the combo of semantical HTML + “Structure” CSS almost becomes like it’s own language that replaces/supersedes HTML, since there’s such a need for a tight 1:1 mapping between the HTML and the “structural” CSS.

I don’t think this is good. Since the HTML now needs to have so many classes, you’ve made its semantic model…

  1. …much more complicated
  2. …much less standard
  3. …much more tightly coupled to a specific visual design

I get that a lot of these proposals came from the age before <section>, <main>, etc. It’s even easier to go back to basics now, with them. An h2 or p in footer can be different-looking than an h2 or p in main.

Embrace many-to-many…

… and think in both directions, both backwards and forwards.

In CSS, the same selector can be assigned to multiple blocks. This is a great thing to reduce duplication. This also can also replace a lot of the use cases for “mix-ins”.

Maybe you have

a, h2 {
	font-style: italic;
	color: red;
}

h2, h3 {
	font-weight: bold;
}

a, h3 {
	border-left: thin black solid;
}

Uh, not that that’s an example that’ll look good, it won’t. It’s just an example of how you can think of it as one set of structure and semantics on the left side, and one set of visual styles on the right side, and then create mappings between them.

Of course, you need good tools that lets you do that without losing track. You don’t wanna be in a position where you wanna see “OK, so what styling do I have on this element” and you’re tripping yourself up because you don’t see which blocks apply to it.

But… we have good tools. There are inspectors that lets you easily see those things.

Summary of Practices