Sessions is temporarily moving to YouTube, check out all our new videos here.

A CSS Eulogy

Michael Riethmuller speaking at Front-End London in August, 2016
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

It’s time to say goodbye to again, only this time it's not to enemies (ie6 and 7), but old friends. I’m going to give a eulogy for some much loved design patterns and techniques we love but sadly don’t need anymore. Warning: This will be an emotional experience and you might cry.


[00:00:09] As you said, I’m an independent web developer from Australia and for a long time I used to work for the Australian government, for I don’t know how long, it felt like 90 years. It wasn’t actually that bad but it was a little bit bad so I quit my job and now I’m here. I spent a lot of time hiking around the world. This is me hiking 800 kilometres across Spain. When I’m not hiking and exploring, I like to experiment with code and you can find some of my half-baked ideas on CodePen or GitHub and occasionally I write something a little bit more detailed on my blog. I’m on Twitter too if you want to follow me and it’s how I measure my self-worth, so that would be awesome. The title of my talk is a CSS Eulogy. I should say thank you all for coming on this very sombre occasion. Now, it’s not a eulogy for CSS itself; although, the landscape is certainly changing and that is something that I want to touch on. I don’t think we’ll be saying goodbye to CSS itself any time soon. Rather, this is talk about looking critically at some of the patterns and techniques regularly used and asking us, “Is this the best way”? Or, have things moved on? Surprisingly, the answer to that might now always be obvious. Now, I’ll be honest with you, it’s not going to be easy, we’ll be laying to rest some much loved patterns and designs, things that have served us well over the years, so lean on the people around you. [00:01:35] Be prepared to reflect on negative margins, lament your love of gratuitous clearfixes and long for the days of pixel-based certainty. We’ll also be looking to the future and acknowledging Flexbox, Viewpoint Units. Legacy is something that we’re constantly dealing with. As a result of this, we don’t always move on as fast as we should. I think we often cling to outdated techniques, either out of fear or comfort. I want to tell you that it’s okay to not let go. In the dying days of IE 6 and 7, despite my personal rocky relationship with them, I still found myself reaching for the comfort of a robust star hack and to this day where inline block is concerned, in my heart Zoom will always be one. What I’m getting at is like anything, our habits when writing CSS can become ingrained and difficult to change. This might be even though we know better. What I think we need is proper acknowledgement of this so that we can all move on and get that well needed closure. Cherish that memory now as we say goodbye to one of our fondest friends, the clearfix. That’s not quite working there, sorry. [00:02:37] Now, you all know what I’m talking about when I say a clearfix, it’s a hack to make an apparent element clear children. It’s, of course, a very versatile hack, one that underpins a lot of patterns that we use. Things like media objects, navigation, grids, and all of that. In fact, we use it so much we forget it’s a hack. If you’ve ever had to explain what a clearfix is to someone who doesn’t know, you might have realised it doesn’t really make much sense. Although it feels like second nature to us, floats were never meant to be used for solving the majority of layout problems that we asked them to solve, they require hacks like clearfix to even work in the first place. “Why should we have to do this?” is a perfect legitimate question. I think all of us in this room have come to accept that this is the default way solve this problem, no more thinking required. I think when we get to that point that I think we become close to new ways of thinking and fail to see better options. So, before we look at those better options, this is a eulogy, so let’s take a quick look at the like and evolution of clearfix. It’s been good to us, so it feels like the honourable thing to do. This here is of course a primitive ancestor to our modern clearfix. If anyone here as perhaps been to the London zoo you might say, “Mike, you fool, that’s a chimp”. This is exactly the type of nonsense we expect from the colonies. Okay, London, very clever of you and also very snotty I might say but he’s a very symbolic chimp and the reason he’s so happy is he’s just realised that he can force a container to clear its children by adding an empty div at the bottom with the property clear both. [00:04:09] It was a simple and fairly elegant solution but it wasn’t semantic and dare I say it, real developers don’t use empty elements. I feel like I should duck when I say that. What this chimp didn’t realise is that like a fish taking its first evolutionary steps out of water, the next few years were going to be a little bit awkward. I do hope that you’ll forgive me for extending that metaphor but I think you’ll agree it was worth it to get these guys on a slide. What I’m not really getting at very well is how early clearfix tricks, they weren’t very pretty, they looked something like this. I don’t want you to read this, I just want you to glance at this with a fond nostalgia. It contains various hacks to target specific browsers and each case these hacks are trying to achieve just one thing. That is to trigger an internal browser rendering property known as “block formatting context”, so you might remember HAS layout in IE. If you don’t know what block formatting context is, simple put, it’s the devil’s magic. It’s an internal property that we can only trigger indirectly and it’s what all of those hacks were trying to achieve. Clear fix is a side-effect. Pretty soon browsers lifted their game and we didn’t need all of those ugly hacks. I call this one a transitional stage clearfix. It’s not quite as ugly and not quite as scary. In 2011, Nicola Gallagher improved on this again and we have the micro clearfix. Now, if you’re using a clearfix today, it should look something like this. [00:05:35] An interesting point to make about this example is like the earlier one, we’re inserting an empty element at the bottom of a container with the property, clear: both, the only difference is that this time it’s a pseudo-element. I think it can be valuable to reflect on the life an evolution of techniques that we use because sometimes like this, they point us to the future. Okay, so a quick show of hands, who here has used a clearfix in the last year? Nearly all of you. Of those of you who put your hands up, who’s used it in the context of a .clearfix utility class or something similar? I’m very pleased to see a lesser number but I’m sure it’s something that we’ve all done at least once at some point and it’s something that I’m guilty of too. I’ll be willing to bet you my left hand, and this is my left hand if anyone wants to know what they’ll get into, I bet that this is going to be one technique that we’re going to say goodbye to once and for all this year. Now, the reasons I think that is firstly there are better layout techniques that don’t need clearfix at all. More importantly than that, pre-processors such LESS and SASS and I guess I should include PostCSS now as well, in terms of a .utility class, they offer us tools to get rid of this. Previously, it might have been easier to write the clearfix once in your CSS and then apply the class anywhere in the markup that you needed to use it. This was obviously faster than writing it in every component when needed, but obviously mixins give us an opportunity to do this now. This is something that I had difficulty letting go of, again. [00:07:02] I don’t know if you can read that at the back but it kept me up at night wondering whether I should use a mixin or a utility class. I’ll always have fond memories of this. I used to call this the clearfix shotgun approach, if you don’t know how to solve a layout problem, simply clearfix all the things. It was always a nice surprise to come in morning and find that someone had committed this. It usually happened in large teams with multiple developers. It wasn’t until pre-processors gave us placeholders that we were able to forcefully put an end to this. Now, placeholders differ from regular mixins and they’re not written to the final stylesheet, except where they are used. In general, I think that modern tools like pre-processors are good things to lean on in times of hurt, they’ll help you move on and I think you should do that. When I first gave this talk, to test this theory, I did a little research. I went and visited the blogs and websites of all the speakers and organisers at the conference because that’s a great way to make friends. Luckily, when I was conducting that test, I found that despite it being very non-scientific, I confirmed that the clearfix utility class was indeed out of favour out of about 50 websites I’ve visited. Only around five had it and I might have had a hand in one of those as well. I hope I’ve convinced you that you probably don’t need a clearfix utility class, but do we need a clearfix at all? The answer to that is it depends. [00:08:32] In a lot of situations there are better techniques that we can use now and I think it’s time that we took a look at some of those examples. This is the media object, you’ve probably all seen this, it was popularised by Nicola Sullivan. It’s suppose char object orientated CSS. It’s been a pretty solid go-to pattern for a number of years and traditionally it has an image, a heading and some text to one side. Apart from the container needing a clearfix, you also need a block formatting context on the content or a left margin equal to the width of the image to prevent the text from wrapping underneath. I’d often see a lot of examples like this when browsing the interweb. I’m thinking, how might we rethink this well-known example to get rid of this reliance on magic numbers? I found a solution by someone call Harry Roberts. Now, I have no idea who he is but his solution looks pretty good. He wrote about something he calls “the flag object” and it’s not just a poorly disguised rebranding, no, it is just a poorly disguised rebranding of the media object, let’s just be honest. It adds to it with some additional options and versatility. It’s support as far back as IE 8, so if you’re supporting legacy it’s an option. As well as that, you can vertically centre the image or align it to the bottom, and because the image extends to the full width of the container, you can have different background colours. Sorry for my terrible colour choice there. I’m a much better designer these days than when I developed that one. [00:10:07] Anyway, it makes use of display: table and personally I feel that’s something that is criminally overlooked, I wouldn’t use it for laying out a whole page but used in moderation in components, I don’t see really what the problem is. I think we just sometimes cringe at the word “table”. If you’re ready, there is a more robust solution that uses flexbox. This one is by Philip Walton. Like the flag object, this implementation gives us control over the positioning of the image but as well as this we get something called “source order control”, this means that we can move it to the left or the right without changing any of the HTML. All of those alignment options are inherent in flexbox. This is really good, this means that we’re not relying on hacks and things to make them work. I’m not going to give the full detail of all those techniques but suffice it to say that flexbox gives us greater control over layout than any other techniques that we commonly use. As I said, they’re built in. If you haven’t seen Philip Walton’s site, “sold by flexbox” I strongly recommend that you go and have a look at it after this. It contains that and many other patterns. For now, let’s just take a quick moment’s silence to say a farewell to clearfix. We’ve loved you and you were there for us when things were tough. You will always have a place in our hearts, but sadly we no longer need you like we once did. You may be destined to fade into obscurity but you will not be forgotten. Thank you clearfix. [00:11:39] Let’s not dwell on our sorrow for clearfix too long because there are other patterns that we need to say goodbye to. One of those is negative margins. Despite their image as a hack, negative margins are well described by the CSS specification and in many cases we use them exactly as was intended. I’m not firing at negative margins in general but I do think that they tend to be a symptom of poor choice in our CSS. With more layout options available, I’m finding fewer situations where I actually need them. One practical example of this and a pattern that we’ve seen many times, one that’s probably familiar to you, if not quite comfortable, is modals, or more generally positioning anything in the centre of the screen. It might be a log on box, a message, a dialogue, or you might be asking me to share your article on Facebook before I’ve even read it. Of course, if that’s what you’re doing, you can stop but there are legitimate reasons for needing a pattern like this. Whilst it might not be as close to our hearts as clearfix, I think we could quickly take a look at the life and evolution of this pattern. Historically, we might have used an alert or a confirm dialogue, but the problem with these is they were ugly, obnoxious and we couldn’t change a thing about how they looked. With those limited options, understandably, we all just avoided them in favour of customer options. [00:13:07] Sorry about this guys. Hang on. Yes. Let’s just do this. All right. Now, I’ve lost my speaker notes now. Yes. Modals. What we would do is we’d give it an absolute position and a top and left value of 50%. That would move the top left corner into the centre of the screen and to move the centre of the element into the centre of the screen we gave it a negative left margin equal to half its width and a negative top margin equal to half its height. You’ve all probably seen this. Who here has used this technique before? Is anyone still commonly using this technique? Just one hand, that’s really good. I still find sometimes that I reach for this just out of habit or comfort. The problem I have with this technique is that the width, height, and margins are all magic numbers. I also find that with responsive design, I’m doing multiple versions of it for different screen sizes and maybe an in-line version for mobile. As well as this, there might be situations where I don’t know the size of the thing I need to centre or whether that should be a percentage. This once robust technique is no longer meeting all of my needs. Now, to address that unknown size thing, one of my first inclinations was to try and solve this problem using percentages for negative margins. Of course, that’s a problem I only made a thousand times as a seasoned developer and it’s a simple mistake that you’ve possibly all made. Percentages where negative margins are concerned are relative to the parent container and not to the element itself. That’s not really that intuitive. [00:14:47] Luckily, this is how CSS transforms work, unlike negative margins when using translate to position an element, you can move it 50% of its own width or 50% of its own height any direction. It’s a lot more robust and intuitive and no more magic numbers. Like I said, you’ve probably all seen that technique as well but this too might be a transitional stage solution. I think that this pattern may also be on the verge of making another evolutionary step. What I’m talking about is the dialogue element. Now, this is relatively new, I think it’s in Chrome and Opera but it may have landed in Firefox, I’m not too sure. There are some polyfills, however, that you can use today and they’re as good as any custom solutions that we use. I think you can start using this. The dialogue element doesn’t require any CSS for positioning. I don’t know if you can read it there but it’s only got a width in that example. You can override the default positioning, of course, with CSS, but as well as that we get native JavaScript methods for interacting with it, no more toggling classes or anything like that. We get this backdrop pseudo-element which makes it pretty easy to add a background overlay, which you probably know is very hard in CSS. Here I’ll just quickly set it to a beautiful shade of pink. There you go, that would have been many lines of CSS prior. [00:16:16] Again, in a circle of life kind of way, I feel like this pattern has come back to its origins. We’ve gained full control over the presentation with CSS but just like the alert and confirm dialogues, we’re back to a semantic representation of a dialogue with native JavaScript methods for interacting with it. This is how it often goes, we have a problem that doesn’t quite meet our needs and we bend it and we break it. Sometimes hacks are born, things like clearfix, but occasionally a new element, like the dialogue is born. Goodbye negative margins, our relationship was one of necessity but you made so many things possible. Whilst this might be goodbye, it could be, however, a chance to reacquaint ourselves with some patterns and thanks to your hacky ways, we may have lost our spark. Now, the final farewell I want to mention today is the shakeup that viewport units are going to give our typography and layout best practices. Viewport units have been around since 2012. In fact, IE was an earlier moving and they were supported as far back as IE 9. Viewport units are really easy to understand. It’s basically 1% of the viewport. There are four types of viewport unites, viewport VW, which is viewport width, VH which is the viewport height, VMin, which is the width or height, whichever is smaller, and Vmax which is the width or height whichever is largest. That’s pretty intuitive. [00:17:40] I think that the reason viewport units are not used more often isn’t due to a lack of developer’s understanding or browser support but rather more down to the lack of control that designers have and maybe specifically over things like font size. You might have thought we said goodbye to pixel based font sizes in the late 2000s, and we largely did, we favoured EMs and percentages because pixels don’t change according to user preferences and this is bad for accessibility, if not just rude. Pixel based typography wasn’t quite dead, it was just lurking in the shadows and waiting for the days when browsers offered zoom to enlarge text. With this, some developers decided that the accessibility concerns of pixel based fonts were no long an issue. That debate still rages but the truth is whether you’re using EMs, REMs, or percentages, these are all just abstractions of a base font size and we usually know that to be 16 pixels. We’ve never really had to give up complete control. Viewport units are different, they represent an evolutionary leap, a fundamental change in approach. For the first time, we have true responsive typography. Viewport units are not relative to the base font size in any way and I think that’s what scares some people. This means goodbye to clunky responsive type techniques like this. [00:19:01] The problem with this is that they’re jumpy. They require multiple media queries and they don’t necessarily resize in proportion to other elements on our page, this means that they can jump out of containers, trigger overflow, cause all kinds of mess. It’s like feeding a gremlin after midnight. Honestly, I don’t know why we’ve persisted with this method of responsive typography for so long. Avoiding some of these problems and we can limit the scaling by only applying viewport units above a certain screen size. We could also use CALC and this example says, set the font size at a viewport width of zero to exactly 16 pixels, so that’s a little bit more precise. Then, scale at a rate of three viewport widths from there. Yes, there are still limitations but there are ways to hack around them again. When I was preparing this talk initially, I was thinking about some of those limitations and whilst we can limit scaling with media queries and CALC, we still don’t have full control. We’re essentially not over multiple viewport widths anyway. We’re limited to whatever three viewport widths was in the previous example, at any screen size without another media query or a change in the font size. We can’t change it, for example, to 32 pixels at an 800-pixel resolution. [00:20:10] Like every eulogy you’ve ever been to, this one ends with a closing rank. Now that we’ve had a detailed look at the life and evolution of a few patterns, as well as some of the hacks we’ve used to get around those limitations, I hope you’ve realised a familiar thing. Our hacks are usually just clever work arounds for the limitations of CSS. In most cases, those limitations relate to layout. That’s because CSS was not designed for solving layout problems. It was designed for adding simple styles to HTML documents. In fact, not even necessarily HTML documents. XML was still a viable option then. Thank you.