Menu Search
Jump to the content X X
Smashing Conf San Francisco

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf San Francisco, dedicated to smart front-end techniques and design patterns.

Writing CSS For Others

I think a lot of us CSS authors are doing it wrong. We are selfish by nature; we get into our little bubbles, writing CSS (as amazing as it may be) with only ourselves in mind. How many times have you inherited a CSS file that’s made you say “WTF” at least a dozen times?

(Image: Toca Boca2)

HTML has a standard format and syntax that everyone understands. For years, programmers have widely agreed on standards for their respective languages. CSS doesn’t seem to be there yet: everyone has their own favorite format, their own preference between single-line and multi-line, their own ideas on organization, and so on.

A New Way of Thinking Link

Recently, I have begun to think that CSS authors could take a leaf from the programmers’ book. We need to write CSS that others can understand and use with ease. Programmers have been writing sharable code since day one, and it’s high time that CSS be written with as much organization and openness.

In writing inuit.css3 and working on a huge front-end framework at my job4, it has become more apparent to me that writing code that can be easily picked up by others is extremely important. I wouldn’t say that I’ve nailed everything yet, but I’ll share with you some things that I think are vital when writing code, specifically CSS, that will be used by others.

First, the reasoning: my number one tip for developers is to always code like you’re working in a team, even when you’re not. You may be the only developer on your project right now, but it might not stay that way:

  • Your project could be taken to another developer, agency or team. Even though this is not the best situation to find yourself in, handing over your work smoothly and professionally to others is ideal.
  • If you’re doing enough work to warrant employing someone else or expanding the team at all, then your code ceases to be yours and becomes the team’s.
  • You could leave the company, take a vacation or be off sick, at which point someone else will inherit your code, even if only temporarily.
  • Someone will inevitably poke through your source code, and if they’ve never met you, this could be the only basis on which they judge your work. First impressions count!

Comments Are King! Link

One thing I’ve learned from building a massive front-end framework at work and from producing inuit.css is that comments are vital. Comments, comments, comments. Write one line of code, then write about it. N.B. This is not meant to mean write about every line of code, as that would be overkill. Only comment where it helps/is useful.

It might seem like overkill at first, but write about everything you do. The code might look simple to you, but there’s bound to be someone out there who has no idea what it does. Write it down. I had already gotten into this habit when I realized that this was the same technique that a good friend and incredibly talented developer, Nick Payne5, told me about. That technique is called “rubber-duck debugging6”:

… an unnamed expert programmer would keep a rubber duck by his desk at all times, and debug his code by forcing himself to explain it, line by line, to the duck.

Write comments like you’re talking to a rubber duck!

Good comments take care of 99% of what you hand over and — more importantly —  take care of your documentation. Your code should be the documentation.

Comments are also an excellent way to show off. Ever wanted to tell someone how awesome a bit of your code is but never found the chance? This is that chance! Explain how clever it is, and just wait for people to read it.

Egos aside, though, comments do force you to write nicer code. I’ve found that writing extensive comments has made me a better developer. I write cleaner code, because writing comments reminds me that I’m intending for others to read the code.

Multi-Line CSS Link

This issue really divides developers: single-line versus multi-line CSS. I’ve always written multi-line CSS. I love it and despise single-line notation. But others think the opposite — and they’re no more right or wrong than I am. Taste is taste, and consistency is what matters.

Having said that, when working on a team, I firmly believe that multi-line CSS is the way to go. Multi-line ensures that each CSS declaration is accounted for. One line represents one piece of functionality (and can often be attributed to one person).

As a result, each line will show up individually on a diff between two versions. If you change, say, only one hex value in a color declaration, then that is all that needs to be flagged. A diff on a single-line document would flag an entire rule set as having been changed, even when it hasn’t.

Take the following example:


Above, we just changed a color value in a rule set, but because it was a single-line CSS file, the entire rule set appears to have changed. This is very misleading, and also not very readable or obvious. At first glance, it appears that a whole rule set has been altered. But look closely and you’ll see that only #333 has been changed to #666. We can make this distinction far more obvious by using multi-line CSS, like so:


Having said all this, I am by no means a version-control expert. I’ve only just started using GitHub for inuit.css, so I’m very new to it all. Instead, I’ll leave you with Jason Cale’s excellent article on the subject.

Furthermore, single-line CSS makes commenting harder. Either you end up with one comment per rule set (which means your comments might be less specific than had they been done per line), or you get a messy single line of comment, then code, then comment again, as shown here:


With multi-line CSS, you have a much neater comment structure:


Ordering CSS Properties Link

Likewise, the order in which people write their CSS properties is very personal.

Many people opt for alphabetized CSS, but this is counter-intuitive. I commented briefly on the subject on GitHub11; my reasoning is that ordering something by a meaningless metric makes no sense; the initial letter of a declaration has no bearing on the declaration itself. Ordering CSS alphabetically makes as much sense as ordering CDs by how bright their covers are.

A more sensible approach is to order by type and relevance. That is, group your color declarations together, your box-model declarations together, your font declarations together and so on. Moreover, order each grouping according to its relevance to the selector. If you are styling an h1, then put font-related declarations first, followed by the others. For example:

#header {
   /* Box model */
   width: 100%;
   padding: 20px 0;
   /* Color */
   color: #fff;
   background: #333;

h1 {
   /* Font */
   font-size: 2em;
   font-weight: bold;
   /* Color */
   color: #c00;
   background: #fff;
   /* Box model */
   padding: 10px;
   margin-bottom: 1em;

Please note that the comments above are not intended to go into your CSS file, but are just to illustrate my point in the article.

Ordering CSS Files Link

Ordering CSS files is always tricky, and there is no right or wrong way. A good idea, though, is to section the code into defined groups, with headings, as well as a table of contents at the top of the file. Something like this:


html {

body {


And so on.

This way, you can easily read the contents and jump straight to a particular section by performing a quick search (Command/Control + F). Prepending each heading with a dollar sign makes it unique, so that a search will yield only headings.

The “Shared” Section Link

All CSS files should have a section for sharing, where you tether selectors to a single declaration, rather than write the same declaration over and over.

So, instead of writing this…

h1 {
   font-size: 2em;
   color: #c00;

h2 {
   font-size: 1.5em;
   color: #c00;

a {
   color: #c00;
   font-weight: bold;

#tagline {
   font-style: italic;
   color: #c00;

… you would write this:

h1 {
   font-size: 2em;
h2 {
   font-size: 1.5em;
a {
   font-weight: bold;
#tagline {
   font-style: italic;

h1, h2, a, #tagline {

This way, if the brand color of #c00 ever changes, a developer would only ever need to change that value once. This is essentially using variables in CSS.

Multiple CSS Files For Sections, Or One Big File With All Sections? Link

A lot of people separate their sections into multiple files, and then use the @import rule to put them all back together in one meta file. For example:

@import url(main.css)
@import url(type.css)
@import url(images.css)
@import url(tables.css)
@import url(misc.css)
@import url(responsive.css)

This is fine, and it does keep everything in sections, but it does lead to a lot more HTTP requests than is necessary; and minimizing requests is one of the most important rules for a high-performance website.

Compare this…


… to this:


If you section and comment your CSS well enough, using a table of contents and so forth, then you avoid the need to split up your CSS files, thus keeping those requests down.

If you really want to break up your CSS into multiple style sheets, you can do that — just combine them into one at build time. This way, your developers can work across multiple files, but your users will download one concatenated file.

Learning From Programmers Link

Programmers have been doing this for ages, and doing it well. Their job is to write code that is as readable as it is functional. We front-end developers could learn a lot from how programmers deal with code.

The code of my good friend (and absolutely awesome chap) Dan Bentley14 really struck a chord with me. It’s beautiful. I don’t understand what it does most of the time, but it’s so clean and lovely to look at. So much white space, so neat and tidy, all commented and properly looked after. His PHP, Ruby, Python or whatever-he-decides-to-use-that-day always looks so nice. It made me want to write my CSS the same way.

White space is your friend. You can remove it before you go live if you like, but the gains in cleanliness and readability are worth the few extra bytes (which you could always cut back down on by Gzip’ing your files anyway).

Make the code readable and maintainable first and foremost, then worry about file size later. Happy developers are worth more than a few kilobytes in saved weight.

Code Should Take Care Of Itself Link

So far, we’ve talked about people maintaining your code, but what about actually using it?

You can do a number of things to make the life of whoever inherits your code much easier — and to make you look like a saint. I can’t think of many generic examples, but I have a few specific ones, mainly from inuit.css.

Internationalize Your Selectors Link

Inuit.css has a class named .centered, which is spelt in US English. CSS is written in US English anyway, so we’re used to this; but as an English developer, I always end up typing UK English at least once in a project. Here is the way I have accounted for this:

.centred, .centered {

Both classes do the same thing, but the next developer doesn’t have to remember to be American!

If your selectors include words that have US and UK spelling variants, include both.

Let the Code Do the Heavy Lifting Link

Also in inuit.css, I devised a method to not need class="end" for the last column in a row of grids. Most frameworks require this class, or something similar, to omit the margin-right on the last item in a list and thus prevent the grid system from breaking.

Remembering to add this class isn’t a big deal, but it’s still one more thing to remember. So, I worked out a way to remove it15.

In another major inuit.css update, I removed a .grid class that used to be required for every single grid element. This was a purely functional class that developers had to add to any <div> that they wanted to behave like a grid column. For example:

<div class="grid grid-4">

This .grid class, in conjunction with the .grid-4 class, basically says, “I want this <div> to be a grid item and to span four columns.” This isn’t a huge burden on developers, but again, it’s one more thing that could be removed to make their lives easier.

The solution was to use a regex CSS attribute selector: [class^="grid-"]{}. This says, “Select any element whose class begins with .grid-,” and it allows the developer’s mark-up to now read as follows:

<div class="grid-4">

CSS attribute selectors may be less efficient than, say, classes, but not to the point that you’d ever notice it (unless you were working on a website with massive traffic, like Google). The benefits of making the mark-up leaner and the developer’s life easier far outweigh the performance costs.

Do the hard work once and reap the benefits later. Plus, get brownie points from whoever picks up your project from you.

Be Pre-emptive, Think About Edge Cases Link

An example of being pre-emptive in inuit.css is the grid system. The grids are meant to be used in a series of sibling columns that are all contained in one parent, with a class of .grids. This is their intended use. But what if someone wants a standalone grid? That’s not their intended use, but let’s account for it should it happen16.

Note: inuit.css has changed since this was written, but the following is true as of version 2.517.

Another and perhaps better example is the 12-column grid system in inuit.css. By default, the framework uses a 16-column grid, with classes .grid-1 through .grid-16 for each size of column.

A problem arises, though, when you attempt to switch from the 16-column system to the 12-column system. The .grid-15 class, for example, doesn’t exist in a 12-column layout; and even if it did, it would be too big.

What I did here was to make .grid-13 through .grid-16 use the exact same properties as .grid-12. So, if you switch from a 16-column layout to a 12-column one, your .grid-13 through .grid-16 would’t break it — they would all just become .grid-12s.

This means that developers can switch between them, and inuit.css will take care of everything else.

Pre-empt the developer’s next problem, and solve it for them.


A few people have mentioned that some of these practices lead to a bloated CSS file. Bloat is where unnecessary code makes its way into a file, and your comments should be anything but unnecessary. It will lead to a larger CSS file, but not a bloated one.

If you are worried about increased file size then you should minify18 and gzip your stylesheets, but this is best practice (particularly for highly trafficked websites) anyway.

That’s It Link

There you have it: a few humble suggestions on how CSS authors can write code that is perfect for other developers to inherit, understand, maintain, extend and enjoy.

If you have any other tips, do please add them in the comments.


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18

↑ Back to top Tweet itShare on Facebook


Harry Roberts  is a Senior UI Developer for and type nerd from the UK. Enthusiastic, passionate and often outspoken, he is a writer, designer and member of Smashing Magazine’s Experts Panel. He tweets at @csswizardry.

  1. 1

    Great write up Harry. It’s always interesting to see how others write their CSS when there are fewer restrictions on laying it out.

    I also favour multi line, I find it so much easier to scan but again, a totally personal preference.

    Getting used to working as part of a team even when you’re on your own is great advice and something everyone should try and get into the habit of!


    • 2

      Oneline css though has the advantage of fewer lines to run through thus speeding up the initial loadtime. A mid size site with 500 lines of oneline css could easily be around somewhere like 2-3000 lines of css when using the multiline approach.

      Sure you can minify your multiline css file before uploading it to your server, but i would rather adapt (which i did recently) and skip that part.

      If you make sure to indent your css elements and their childrens you quickly get a proper overview:

      I took me some getting used to at first but after the first couple of hours it was no issue at all working with the oneline approach.

      • 3

        I agree with Martin, plus there are different ways of keeping track of changes to a CSS file, like SVN.

        • 4

          The example in the article uses version control.

          I think the author’s point about single vs multi-line css in svn is that changes are tracked per line #. So single-line css will be a bit difficult to debug based on line # alone.

          Not that I’m closed to the idea of single line css. Martin’s comment about being able to see the structure at a glance (using proper indentation) seems good enough to make me want to try single line css.

          • 5

            When coding your CSS, it’s best to use multiline, especially when collaborating – and that is the point of the article. Whenever I go live with code, be it CSS or JavaScript, I minify it anyway to strip out all comments and empty spaces.

            That said, this is a good starting point if you don’t have any sort of style guidelines set up yet, but I find many places already have style guides set up. This article is just one coder’s opinion, after all. :)

      • 6

        I also agree with you Martin I also use multi-line css before but i switch into single line css because it speeds up the initial loadtime.

      • 7

        One-line CSS doesn’t really save you many bytes. You probably still add a space after each semicolon, so that’s the same as hitting Enter. Essentially, the only extra byte is the tab character after the newline.

        Also, you can still indent multi-line CSS rules for descendants, I always do it religiously. (although in that case minification becomes quite necessary in big files).

        • 8

          Hi Lea

          When doing one-line css i’m looking to reduce the number of lines the server has to traverse in order to serve the css file, not so much reducing the number of kilobytes. Are you saying that the whitespace after the semicolon gets treated like a new line (pressing enter)? I did not know that.

          In my experience that has left me with a more swift initial load of the css file and with time i kinda like the one-line structure more as i don’t have to scroll that much.

          Wether or not one uses the one-line css, indenting is always a nice way to ensure a quick overview of the structure of the file.

      • 9

        At work we use a custom minimse/gzip css on the server when it’s pulled down anyway so comments are typically removed along with whitespace and minification takes place so what’s output to the browser is less than both multi or single line anyway.

        With that in mind, I’d prefer a local production version I can easily read and for me that’s always been multi-line.

        I do totally appreciate it’s a personal thing though as to what’s easier for people to read and that at this time, there’s no right or wrong but to me the argument is largely void by the fact that you should ideally be minifying and gzipping on live sites anyway.


        • 10

          Hi James

          We operate with gzipping and other stuff too and you’re right that it’s a personal thing when you make sure to minify and gzip.

          If you don’t do this i have had better loadtimes with one-line css files on alot of sites. Not much, but every millisecond counts and down the road i’ve found that i can more easily scan one-line css files (as long as they are indented properly) after some getting used too.

      • 11

        CSS gets read more than it does written, so for me it’s important that its readable over speed improvement, plus that’s what minify is for.

        Multiline works as you would read any other document, it’s great for scanning. With single line you’re having to pan and scan (somtime even vertical scroll :( )

      • 12

        Wait, what? Shouldn’t CSS and javascripts always be combined and minified dynamically? Thus you as much space and comments as you like, and it’s all taken care of without your extra time. Of course caching as well.

        Minifyjs, or other libraries can do it in a snap. There’s a plugin for just about every framework out there for plug and play, or more like upload and activate.

        Anyway, given that it’s done dynamically, I’d agree with extra comments as space. Saves time, headaches, and performance is just as good.

  2. 13

    Yep great article Harry. Well done.. Organising your CSS is an important part of differentiating yourself as a great front-end developer instead of just a good front-end developer


  3. 14

    Nassimbwa Catherine

    August 26, 2011 3:17 am

    very enlighting…. it has cleared some areas that were kinda puzzling me… nice read

  4. 15

    This is a fabulous article, Harry. I’ve skimmed it and bookmarked it for more detailed scrutiny. I actually spent more time poring over inuit.css — fascinating. I put together a piece on organizing your CSS in my “how-to” site for beginning designers, based on work by Rob Glazebrook, Douglas Bowman, and Tom Fadial and tweaked by me. Interesting to see the similarities and differences between that methodology and yours.

  5. 16

    Single vs multi-line CSS debate is pointless since you shouldn’t be using a CSS/HTML editor that can’t format the code with single click or keyboard shortcut :-p

    I think ordering properties (often being done by a css compressors) is a crime against humanity. In my opinion it should be divided into logic structure corresponding to the structure of the site.

  6. 17

    Christophe V.

    August 26, 2011 3:26 am

    Not sure about the “@import” usage :)

    Same thing for the internationalization of selectors (maybe if it’s really necessary if you have not the possibility to change them in HTML code), it will do too much unused and useless selectors in CSS.

    But great for the other parts, i agree with them ;)

  7. 18

    One thing often overlooked by CSS developers (and used by programmers) is the practice of splitting large chunks of code into multiple smaller files. Often it’s a necessity just to keep a code base maintainable.

    Most CSS preprocessors can automatically concatenate multiple files for you so you can use as many files as you like locally while only sending one file over the network.

    • 19

      Not entirely so:

      1. Maintainability is now best handled through preprocessors (SASS/LESS)

      2. OOCSS best-practices now state you should have a minimal amount of files

      3. By doing so there are less server requests

  8. 20

    Interesting, I never really thought about the multi-line topic that way before – something maybe to reconsider in future projects. I was definitely more of a fan of the single-line coding but can see your point…and may have to try it. good article!

  9. 21


    August 26, 2011 3:34 am


    An excellent (and in my case) timely reminder of good CSS practice…

    Just tidying up some CSS myself, and reminded me to “leave more comments!”

  10. 22

    Niels Matthijs

    August 26, 2011 3:37 am

    A decent write-up of the different styles of css coding, but the overall incentive of the article is not really reached in my opinion.

    You give a some good arguments for your preferred style, but they are hardly convincing for those who prefer a different style of css coding. You might like white-space in your css files, I for one don’t. Why do I not like it? Because it makes it harder for me to read. I absolutely hate single-line css and find it tiresome to work with.

    The biggest difference between our preferences lies with the proposed division of your css file. I prefer to group css by component. Together with single-line coding it’s quick and ease to see how a group of selectors form one visual component and how the css works together on multiple levels of html. I tend to group my css in component sections (like navigation, tables, basic frame, headings, …) and group all separate components underneath. That just doesn’t work very well with your proposed way of writing css.

    User preference is a pretty blocking issue when trying to come up with a global best practice way of writing css, which probably should and could not be solved on coder level. I think it’s more interesting to look at our coding tools and find ways to easily switch between different coding styles. Going from single line to multiline shouldn’t be all that hard to implement, having that build in to our coding tools could solve many issues.

    • 23

      Whitespace is fine for development, when you deploy your CSS you should always be minimising and gzipping it anyway so what is output isn’t the full local development version anyway.


    • 24

      Interesting proposition (ok that sounds like SPAM.)

      I’d love to see a simple text editor that has that switch between single and multi-line functionality for CSS files. I wonder how it will handle the line numbers and svn, etc.

      This should be on the to-do list of some developers. Or is there such a tool already?

  11. 25

    Very interesting article. Thank you for a nice reading. I am more a graphic designer than web developer but sometimes I have to sit down and code up a site or two ;) Since I don’t do it often and there are times when I have to go back to some previous css files, this set of advices you gathered here is also very helpful for those who commit occasional coding even if only for themselves. Believe me, opening your own messy file you wrote four months ago can also drive you bananas ;)


  12. 26

    It’s not about CSS – article is great, and there are many tools to help, so you… well, I don’t have the excuse not to do so, – but I have problem with HTML in that regard: for example, if you write every list item <li> on new line, then with display: inline-block there are spaces between them. float is unnecessary and add complications. Do I missing something?

  13. 27

    Nice article, readability of code is important for both the developer as well as anyone else who might read it .

  14. 28

    Great article. I find it useful to semantically list the colors and their hex equivalents in a comment, like /* red:#791302 grey:#5f6460 */

  15. 29

    Don’t however, forget who the code is for. The browser … well, ultimately the benefit of the user of the browser. And as such the end product seldom has direct connection to the production … look at many things we purchase without this actually being a problem: packaged food might include ingredients but not the actual recipe, clothing does not give instructions on how the fabric and peices were actually made and assembled, houses and cars don’t come with anything of the sort either … much of production is lost when it gets to the end user.

    When you stop to realise that ‘others’ in css authoring actually encompasses both end-users and developers, you will realise that different priorities are needed at the different ends. The two seldom are the same and that is fine. We can live with that, because we are.

  16. 30

    Brad Czerniak

    August 26, 2011 4:12 am


    Ordering declarations alphabetically is like ordering CDs by title alphabetically (not by cover brightness). It’s useful, even if colors/sizes/arbitrary groups are not together because firebug auto-sorts them alphabetically. By enforcing that order in the file itself, it makes maintaining the CSS that much easier.

    • 31

      @Brad Czerniak I couldn’t agree with you more, and that is exactly the reason why I order alphabetically. Chrome also does this auto-sort. The other thing you gain with alphabetizing is the enhanced readability – you can find a property of an element quicker when you know everything is alphabetized. Additionally, the other argument I have for alphabetizing is that there is no other easily-identifiable standard for sorting. The author suggests with categories such as Box Model and Color, but where does one place elements that commonly consolidate multiple properties, such as background, border and font? Each of those can contain Box Model and Color elements.

      • 32

        Bryce Pelletier

        August 26, 2011 6:46 am

        I don’t pretend to be any type of authority on css practices, but I have to agree with Brad and Adam on the alphabetical sort. Firebug (for any browser) as well as Chrome all sort alphabetically. This just makes it easier when coding to just make changes in firebug then copy paste when you get what you like. You can also identify what your looking for faster once it becomes second nature; which I found doesn’t take long at all. I made the switch from box-model order to alphabetical a few years ago and honestly I wouldn’t switch back. Alphabetical makes finding your property faster and more reliable. At least from where I sit.

        • 33

          I don’t get why you would sort your code alphabetically… When I’m looking for a certain element/selector I just Ctrl+f it. That’s even faster than searching through your alphabetically ordered code by hand ;-) By doing this I can sort my CSS in another way that’s also useful but not automated by my editor.

          • 34

            They aren’t talking about sorting selectors alphabetically, but the properties within the selectors, like font-weight, border, etc.

    • 35

      I agree with Brad on ordering declarations alphabetically. Mr. Roberts makes an apples to oranges comparison here, and ordering declarations by groups is more arbitrary than alphabetically sorting the declarations. In that context it’s not meaningless as Mr. Roberts suggests.

      • 36

        Alphabetical ordering drives me nuts. If I am working on a particular section, I want all the CSS for that section within reach. With alphabetical ordering I may have to move back and forth between line 10 and line 1417 just to get a slider and it’s overlay shaped correctly. I’m wasting half my time scrolling up and down…

        Additionally, there is so much disparity between how folks name their classes and IDs. If everyone sorted alphabetically then a header div could be located anywhere in a file: #header, #top-section, #upper-container, #etc.. There’s no consistency.

        • 37

          @ Don Elliot

          They don’t mean ordering the classes and IDs alphabetically.

          They mean naming the declarations within a class or ID, e.g. background, border, margin, width, etc.

          • 38


            Well if that’s the case there’s an argument for it. :) In my early stages when I was modifying WordPress themes instead of building my own I ran into seemingly countless stylesheets which were literally organized alphabetically by class and ID, it boggled my mind.

            Thanks for the clarifying!

  17. 39

    It’s all well using multi-line css and @imports, but if you’re building a site that needs to be fully SEO friendly then past experiences has found that @imports in CSS are not all that good and multi-line CSS gives you a slower rendering speed. I know its only fractional but if clients are looking to get good search engine results then every bit of code, html, css, regardless of whether people can read it easily; should work for what’s best for the site. But opinions are neither wrong nor right :)

    • 40

      A compromise is possible here, though – minify the beautiful multiline whitespaced CSS before uploading the spreadsheet to your live server, and keep the nice copy locally to work on…

  18. 41

    The most important skill is being adaptive. There are a number of ways to code CSS and great coders are those that can come into any project and immediatly start using whatever guidelines that business has.

  19. 42

    Comments are King, indeed. The article is spot-on, but I love that illustration! :-)

  20. 43

    “we get into our little bubbles, writing CSS with only ourselves in mind” ~ Guilty as charged (and by association too)!!


↑ Back to top