The Way We Talk About CSS
I’ve been writing new talks, creating new workshop material, and thinking about how best to teach CSS as we head all too quickly towards 2019. One of the things I’ve been thinking about is how we have typically thought about CSS, and how that should be changing given where the language is now.
CSS has been seen as this fragile language that we stumble around, trying things out and seeing what works. In particular for layout, rather than using the system as specified, we have so often exploited things about the language in order to achieve far more complex layouts than it was ever designed for. We had to, or resign ourselves to very simple looking web pages.
However that has changed. Over the last few years CSS has developed a real layout system, one which has been designed for the complexities and challenges of the environment we work in. That system isn’t Flexbox, nor is it Grid Layout. It is these specifications and more and, as so often is the case, it is the behind the scenes elements and not the star players, that really pull everything together as a system.
On the web we can never be sure how much space we have, so CSS gives us alignment properties based on the distribution of available space. No available space? That’s ok. Nothing is going to break. We often don’t know how much content we have, so CSS gives us sizing based on min and max content sizes, allowing items to grow and shrink into their containing boxes. We don’t necessarily know the direction text is flowing on the page, so CSS gives us the ability to size, align and place our items relative to the flow of text rather than the physical dimensions of the screen. These features are part of the Box Alignment, CSS Intrinsic and Extrinsic Sizing, Writing Modes, and Logical Properties and Values specifications. These specifications tie together the individual layout methods into one system, with various methods to create the type of layout we need to see.
We do that system, and our ability to use it in an elegant way, a disservice if we simply concentrate on the properties and values in the big-name specifications of Flexbox and Grid.
Modern day specifications are incredibly detailed. It’s why we have so few interoperability bugs in CSS Grid Layout. Things are not left to whatever the user agent decides, if a decision has to be made it is made at the spec level, to ensure that all user agents interpret it in the same way. So when I see people writing and speaking about CSS pointing to some behaviour and saying, “oh this behaves in a weird way”, I want to ask them (and sometimes do) if they have looked to see why it is behaving like that. Most of the time, if you look at the spec, you find that the answer is not all that weird. In general, if all of the browsers are doing that weird thing in the same way, it has been specified to behave like that. Perhaps we should start reframing the way we talk about these things. They are not weird, we just haven’t identified the reason yet. Perhaps because we who have been doing this for such a long time, don’t always expect there to be a reason.
There are things in CSS that are not intuitive, or seem at odds with the rest of the system. Many of those are due to legacy reasons and the fact we can’t break the web, however they can be read about and understood. We know these things exist. The fact they exist does not prevent us from moving forward to redefining our understanding of CSS as used for layout. An elegant system, far more powerful than any framework, designed for the realities of a flexible, multilingual, multi-device web. Then, as we push at the edges of that new system, to find the gaps, the things we cannot yet do, and help to make the next phase a reality.