Mistakes in CSS
Tags: cssmistakes, cssconfusion, cssweirdness
Published: 2018-04-04 02:52:26

---
title: Mistakes in CSS
published: true
description: CSS has some weird mistakes in it's design. Here are a few instances that I've dealt with.
tags: CSS mistakes, CSS confusion, CSS weirdness
---


Recently I came across the CSS Working Group’s [“Incomplete List of Mistakes in the Design of CSS”](https://wiki.csswg.org/ideas/mistakes), a post about items in the CSS standard that are now viewed as mistakes. While not a new article, I had never come across it until quite recently. I immediately found it fascinating, in large part due to how I have come across a few of these issues, and in several cases I didn’t even realize it.

I figured I would discuss some of the “mistakes” that caught my attention or have been particularly vexing for me in the past.

## white-space: nowrap should be white-space: no-wrap

### &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;and line wrapping behavior should not have been added to white-space

The first thing in the list is an easy one. Why (why!?) “white-space: nowrap” is involved in line wrapping, I never understood. “Whitespace” feels semantically irrelevant to the goal of causing things that are *not* whitespace to wrap. This weirdness has caused me to have to google the syntax for this nearly every time it came up for me.

## Vertical-align: middle should be text-middle or x-middle because it's not really in the middle, and such a name would better describes what it does

This was something I never realized until I saw this. This seems like an immediate, likely culprit for why vertically centering text always seemed to require something like vertical-align *and* padding to get it just right. Could have also been a mistake on my part, but this doesn’t sound like it helped.

## Percentage heights should be calculated against fill-available rather than being undefined in auto situations

If I understand this entry correctly, this issue was especially problematic to me on one occasion. This was especially irritating as it was in a way that was effectively unfixable using just CSS as far as I could tell. (If you have a solution, please comment! I could easily have missed something about this situation). The problem was a sidebar with a header that grew, and a scrollable section beneath. Further complicating this was that the sidebar was below an existing header, and the results for responsive behavior precluded using vh values. The result was that the percentage height was always undefined, and the scrollable section would not be, well, scrollable. As such, we were forced to give the sidebar header a static height in order to make the “content” section of the sidebar scrollable/give it a defined percentage height value. Everything we tried came back to lacking a defined height value to give to the scrollable div.

## The top and bottom margins of a box should never have been allowed to collapse together automatically as this is the root of all margin-collapsing evil

It doesn't show in markdown, but "**the root of all margin-collapsing evil**" is how it appears normally. I didn’t add the emphasis. That is the only thing bolded in the original post. I think it speaks for itself.

## Tables (and other non-blocks, e.g. flex containers) should form pseudo-stacking contexts

I don’t use tables often myself, however I have seen some issues with tables, especially with accessibility (for example [link](https://developer.paciellogroup.com/blog/2018/03/short-note-on-what-css-display-properties-do-to-table-semantics/)). I can see making a new context for display being worthwhile.

## 'overflow: scroll' should introduce a stacking context

I was not aware of this one, and am not aware of any problems this might have caused me, but this sounds gross. While stacking contexts are *typically* not a problem, when they do become a problem it is often frustrating. I can imagine this causing more of a problem than a developer was likely bargaining for given the details involved with stacking contexts with fullscreened elements that are also scrollable.

A lot of other issues regard semantics and a lack of vision for future use. The former is obviously a problem, whether it be a change in the ordering of arguments (e.g. height vs width) or in wording (“border-radius only affecting the corners). The latter is more a usage issue that can hopefully be fixed with backwards compatibility in a future version.

Hopefully this brings attention to issues you have had in the past and maybe gives some thoughts as to some solutions!