Menu Search
Jump to the content X


Lea is currently busy doing research in Human-Computer Interaction at MIT CSAIL. She has previously written an advanced CSS book for O’Reilly (CSS Secrets) and worked as a Developer Advocate at W3C. She has a long-standing passion for open web standards, and is one of the few Invited Experts in the CSS Working Group. Lea has also started several popular open source projects and web applications, such as Prism, Dabblet and -prefix-free and maintains a technical blog at Despite her academic pursuits in Computer Science, Lea is one of the few misfits who love code and design equally.

Twitter: Follow Lea Verou on Twitter

Google Profile:

Designing Flexible, Maintainable Pie Charts With CSS And SVG

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.

Designing Simple Pie Charts With CSS

Pie charts, even in their simplest two-color form, have traditionally been anything but simple to create with web technologies, despite being incredibly common for information ranging from simple stats to progress indicators and timers. Implementations usually involved either using an external image editor to create multiple images for multiple values of the pie chart, or large JavaScript frameworks designed for much more complex charts.


“But The Client Wants IE 6 Support!”

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.

Money always wins

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.


Optimizing Long Lists Of Yes / No Values With JavaScript

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.


PrefixFree: Break Free From CSS Prefix Hell

Editor's note: This article is the first piece in our new series introducing new, useful and freely available tools and techniques presented and released by active members of the Web design community. Lea Verou is well-known for her experiments with CSS and JavaScript and in this post she presents her recent tool, prefixfree which will hopefully help you break free from the CSS prefix hell.


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.


Help The Community: Report Browser Bugs

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.


↑ Back to top