CSS: Unavoidable Bad Parts

An ersatz CSS tutorial for people who need to style a web page, but<br>aren’t web developers. I am a wrong person to write this kind of<br>thing, as I have neither the time, nor experience. I’d much rather<br>read a book about this. Alas, I had to learn all this stuff from<br>trawling MDN, so perhaps it is valuable to document what I have so<br>far.

CSS, HTML and Web APIs are truly vast, and it takes a career to become<br>a professional. The good news is that modern web has a<br>reasonably-sized, learnable subset which is enough for simple tasks<br>like a programming blog or a simple GUI. I haven’t seen a resource<br>that teaches just this subset, but it’s not too hard to<br>figure this out. The bad news is that there’s also a nasty set of<br>gotchas, which will mess up your page, which you won’t suspect to<br>exist, and which will need days of debugging to figure out. Still,<br>it’s not that bad. I am quite happy with the styling on<br>this site, and it’s only about 200 of readable CSS.

Good: HTML5 semantic tag names

It’s worth looking through MDN<br>Elements Reference. There aren’t that many elements, and things<br>like main, article, nav, kbd make it much easier to structure your page. Less obvious:

ul for any kind of list, like site’s sections in<br>header > nav.

details for table-of-contents (check the source of<br>MDN).

dl/dt for list of pairs.

Bad: Wrappers

If you “View Source” on any “real” website, you’ll notice<br>that everything has layers and layers of wrapper elements, so you<br>might be tricked into thinking that wrappers are how you solve layout<br>problems. I can’t really agree or disagree here, as I never wrote<br>“production” CSS, but, in my experience, it’s much easier to<br>understand if you do the opposite — restrict yourself to using only<br>markup-meaningful semantic tags, and then figure out CSS which works<br>with the markup you have.

Bad: Layout

This one is not an exclusively Web problem, layout is a struggle in<br>every GUI framework I know. Imagine a fixed sized raster image, and a<br>paragraph of text describing it. There are many ways to arrange these<br>two elements on the screen’s rectangle. Generally, for every given<br>width and height, you can do a decent job, as long as the total area<br>is enough. A typical GUI is a hierarchy of such boxes, with a lot of<br>“layout freedom”. The problem though is that layout of each box<br>affects the layouts of all other boxes, as you generally want all<br>boxes to meet exactly, without gaps and overlaps. An important<br>negative realization is that the layout algorithm doesn’t<br>exist. There isn’t a fully general solution to positioning and<br>sizing GUI boxes. Rather, different systems use different sets of<br>heuristics to do the job, from simple<br>RectCut, to fully general constraint solvers, with<br>everything in between. It is hard to get the mental model of how<br>layout works, in general. So, don’t think “how can I do<br>my layout in a given system”, think instead “what possible layouts<br>are allowed by the system”.

Bad: Browser defaults

Let’s start with a bare (but still semantic) HTML markup of a blog<br>article, without any CSS. If you open it in a browser, it will show<br>something. The content isn’t unstyled — the text is of a<br>certain color, font and size. Headers are bigger than the main text,<br>links are underlined, etc. These are the default styles of your<br>browser. They are helpful! The problem is that these styles differ<br>between the browsers. So, even when you add your own CSS, and the end<br>result looks fine in your browser, I might see something different,<br>because you might rely on a browser default, without knowing it. The<br>last bit is the killer here — the problem is in something you didn’t write.

The general solution here is a CSS reset, or normalization — starting your CSS with an<br>explicit set of rules, overriding defaults. Not because defaults are<br>inherently bad, because they are inconsistent. I don’t know which set of rules you need to override in practice, it’s a<br>good idea to compare several existing CSS resets.

This touches on the big question: should you style your web<br>page? There are two competing views of the Web platform — some<br>people treat it as a flexible, adaptive, primarily visual medium for<br>expressing design, others would prefer if the Web focused on<br>delivering the content, allowing each user to customize the<br>presentation. My personal answer here is pragmatic — by default, an<br>unstyled page is poorly usable and looks bad. I would have preferred<br>the world where CSS-less pages were readable as is, but, in this<br>world, I think it is helpful to style the content. At the same time,<br>it’s a good idea to allow advanced users to bring their own CSS.<br>Make sure that your HTML markup is reasonable, that you don’t<br>overfit your HTML to CSS (vice-versa is fine), and that your page<br>functions in reader mode.

Good: Classless CSS

You can’t reset styles to true neutral nothing: if you make the text<br>invisible (white or transparent), it is still a style. So you might as<br>well embrace it: after reset, style...