Today, too many websites are still inaccessible. In our new book Inclusive Design Patterns, we explore how to craft flexible front-end design patterns and make future-proof and accessible interfaces without extra effort. Hardcover, 312 pages. Get the book now →
When it comes to CSS techniques, nobody is more stubborn and smart enough to find solutions to any problems than Lea Verou. Recently, Lea has written, designed and published "CSS Secrets", a truly fantastic book on the little CSS tricks and techniques for solving everyday problems. If you thought that you know CSS fairly well, think again: you will be surprised. In this article, we publish a few nuggets from the book, which were also presented in Lea's recent talk at SmashingConf New York — on designing simple pie charts, with CSS. Please notice that some demos might not work as expected due to limited support in browsers. —Ed.
Frequently, when I discuss CSS3 with other developers, the issue of stubborn clients comes up. They tell me that even though they personally don’t think a website should look the same in all browsers and they’re eager to try all of these new techniques, their clients insist that their website should look the same, so the developers are stuck with the same Web development techniques that we used five to ten years ago. Their clients just don’t “get” graceful degradation.
Is this really the issue? Are our clients incapable of understanding these things? Is the problem that our clients don’t “get” the Web and need to be educated? I don’t think so. We got ourselves into this. We are the ones who caused this problem for our industry. We are the ones giving ourselves this trouble and making our profession less creative and enjoyable than it could be. It’s entirely our fault and no one else’s.
Very frequently in Web development (and programming in general), you need to store a long list of boolean values (yes/no, true/false, checked/unchecked… you get the idea) into something that accepts only strings. Maybe it’s because you want to store them in localStorage or in a cookie, or send them through the body of an HTTP request. I’ve needed to do this countless times.
The last time I stumbled on such a case wasn’t with my own code. It was when Christian Heilmann showed me his then new slide deck, with a cool feature where you could toggle the visibility of individual slides in and out of the presentation. On seeing it, I was impressed. Looking more closely, though, I realized that the checkbox states did not persist after the page reloaded. So, someone could spend a long time carefully tweaking their slides, only to accidentally hit F5 or crash their browser, and then — boom! — all their work would be lost. Christian told me that he was already working on storing the checkbox states in localStorage. Then, naturally, we endlessly debated the storage format. That debate inspired me to write this article, to explore the various approaches in depth.
The code I write in my live demo slides and presentations doesn’t have any prefixes, even for things like @keyframes or the transition property, which aren’t yet supported anywhere prefix-less. To be able to do this, I wrote a script that detects the prefix of the current browser and adds it where needed. Recently, I thought, why not adapt the script to process all of the CSS code on a page, so that the CSS in my style sheets is as elegant as the code in my demos? Shortly after, prefixfree was born.
You’re developing a new website and have decided to use some CSS3 and HTML5, now that many of the new specifications are gaining widespread support. As you’re coding the theme and thinking of how much easier these new technologies are making your job, you decide to stop for a while and test in other browsers, feeling a bit guilty for getting carried away and having forgotten to do so for a while. “Please work,” you whisper to your computer, while firing up all of the browsers you have installed. Browser A, check. You smile, feeling a bit relieved. Browser B, check. Your smile widens, and you start to feel better already. Browser C, “FFFFUUUUUUUUUUU…!”
Sound familiar? You might be surprised to hear that this is not necessarily your fault. With the competition in the browser market these days and the fast pace at which the new specifications are developing, browser makers are implementing new stuff in a hurry, sometimes without properly testing it. CSS3 and HTML5 are much more complex than their predecessors. The number of possible combinations of new features is huge, which leads to the most common cause of bugs: two (or more) things that weren’t tested together. As a result, developers these days stumble upon browser bugs much more frequently than they used to.