Write Better CSS with Less

Less I have a confession: I think parts of CSS suck. It’s repetitive, tedious, and … well, kind of dumb.

I for one find it quite counter-intuitive to specify descendants’ styles like this:

#banner { color: white; background: black; }
#banner a { color: yellow; }
#banner p { margin: 0; }
#banner ...
#banner ...
#banner ...

… and on, and on, and on. Instead, this makes way more sense to me:

#banner {
  color: white;
  background: black;
    a { color: yellow; }
    p { margin: 0em; }
    ...
}

And how about variables? They’d be cool:

@logo = #457301;

h3 { color: @logo; }
#sale { border: 1px solid @logo; }
.alert { background: @logo; }

Are you with me? Well, Less promises to make these daydreams and more a happy reality. You’d write a style sheet using the Less syntax, which is exceptionally easy to pick up — it’s just CSS with some added CSS-like extras. You then use the Less Ruby gem to convert it into regular CSS — run it on the command line, or incorporate it into an app.

Less permits you to use variables and nested selectors, as seen above, but also offers a way to include classes within classes, and some simple math operators. Sweet! Let’s put Less through its paces and see how it copes with a simpler style sheet.

Let’s say I’m making a style sheet for a reasonably common grid structure, like so:

Grid: three at the top, four in the centre, six at the bottom

Usually, I’d decide on a width for the entire page (let’s say 960 pixels — it’s a popular size) and construct various widths based on that, perhaps indeed using a grid system from a framework. I’d like the topmost boxes to occupy one third of the width of the container, the second set of boxes one quarter, and the footer boxes one sixth, so I’ll divide accordingly using my handy calculator. I have a particular favorite green, which I’d like to use as a heading color for some boxes, a border color for the secondary headings, and as a background for the footer. There’s an item that looks kind of like the footer, but with a different font. Oh, and I’d like to add some basic font specifications to each of the sections — the text should become smaller the further you go down. All groovy:

#container {
  width: 960px;
}
.box {
  float: left;
}
#main .box {
  width: 320px;
}
#main .box h3 {
  background: #450;
}
#secondary {
  font-size: 90%;
}
#secondary .box {
  width: 240px;
  border-bottom: 1px solid #450;
}
#footer {
  font-size: 80%;
}
#footer, #super {
  background: #450;
  color: #fff;
}
#footer .box {
  width: 160px;
}
#super {
  font-family: cursive;
}

All groovy, that is, until I decide I’d like to change the width of the container. Now I have to go back and edit the widths of container and each of the descendent boxes on main, secondary, and footer. Then, I decide I’d like to use purple instead of green, so I then have to change the color of the main boxes’ headings, the secondary boxes’ borders, and the footer boxes’ backgrounds. Annoying!

Let’s imagine that I used Less for this task instead. First, of course, I’ll need to install Less, which is a quick job on the command line:

sudo gem install less

Now I’ll open a new text file and start writing Less. I’ll specify a
base width in a variable, @base:

@base: 960px;

And my favorite color:

@pretty: #450;

I’ll then use the @base variable to specify the widths of the main, secondary, and footer boxes as a fraction of that overall width. To define each of the box children of each section, I’ll use nested selectors to define how I want the box children of each section to appear. The @pretty variable is used wherever I need to specify that color. Here is the rest of my Less file:

#container {
  width: @base;
}
.box {
  float: left;
}

#main {
  .box {
    width: @base / 3;
      h3 {
        color: @pretty;
      }
  }
}

#secondary {
  font-size: 90%;
  .box {
    width: @base / 4;
    border-bottom: 1px solid @pretty;
  }
}

#footer {
  font-size: 80%;
  background: @pretty;
  color: #fff;
  .box {
    width: @base / 6;
  }
}

Since super looks just like footer, but with a different font, I’ll use Less’s class inclusion technique (they call it a mixin) to tell it to include these declarations too:

#super {
  #footer;
  font-family: cursive;
}

I’ll cook up a CSS file using this simple statement on the command line:

lessc mystylesheet.less

Out pops a style sheet with much the same content as the one I made in the usual fashion above, with the exception of my footer and super declarations. Rather than being grouped, the common declarations are repeated:

#footer {
  font-size: 80%;
  background: #450;
  color: #fff;
}
#super {
  font-size: 80%;
  background: #450;
  color: #fff;
  font-family: cursive;
}

More on that small annoyance later.

Now, since Less created much the same style sheet, you might be wondering where I’m going with this. Well, here’s where we come to the part where it’s time to change my mind about the width and color, and this is where Less really comes into its own. This time, I only need to change two lines in my style sheet. First up, let’s adjust the value of the base variable, like this:

@base: 720px;

Now, let’s change the green to purple:

@pretty: #619;

Now, I can leave the rest of the declarations alone and generate a new CSS file. The boxes’ width recalculations and color replacements are done for me:

#container {
  width: 720px;
}
.box {
  float: left;
}
#main .box {
  width: 240px;
}
#main .box h3 {
  color: #619;
}
#secondary {
  font-size: 90%;
}
#secondary .box {
  border-bottom: 1px solid #619;
  width: 180px;
}
#footer {
  font-size: 80%;
  background: #619;
  color: #fff;
}
#footer .box {
  width: 120px;
}

#super {
  font-size: 80%;
  background: #619;
  color: #fff;
  font-family: cursive;
}

Of course, this is a very simple example. In the real world, a complex grid-based template could contain dozens of declarations based on a single figure; a color scheme could revolve around two or three basic shades. Using Less, we can treat these base definitions as true variables, and spend less time maintaining them.

Less’s inclusion method could be tidier if it was clever enough to group the common elements of the mixed-in declarations. On the other hand, I kind of like the way it comes out here — I like to organize my style sheet into sections according to purpose:

/* heading styles */
...
/* main content styles */
...
/* footer styles */
...

If there’s a style I like the look of in the heading area, and I want an item in my footer to resemble it, I’d prefer to avoid storing that footer item in my headings section. If you want to be clever and use grouped selectors, you’ll have to put both those styles somewhere. The convenience of the feature outweighs this small nuisance for me, and of course using mixins is absolutely optional.

I love it when clever folk come up with great ways to save time on CSS, and I can see I’ll be making good use of this nifty tool in future. You can check out Less at its web site.

Win an Annual Membership to Learnable,

SitePoint's Learning Platform

  • dusoft

    I don’t think this will catch up as Ruby is way behind PHP in popularity.

    BTW: most of the ideas Less uses had been proposed way back to be included in CSS (I proposed CSS aliases – the very same thing Less uses as “variables”), but they weren’t accepted.

    Generally, Less brings good ideas, but any required pre-processing hurts usage.

  • http://www.cemerson.co.uk Stormrider

    There’s a PHP version of this that I’m using on a project at the moment, css pre processor, and I hate the nesting part of it. Line numbers don’t match up with the original source file making declarations harder to find.

    CSS really should have support for variables though and expressions. Someone even mentioned regular expressions before in a blog post here, which would be neat.

  • http://www.lopsica.com BerislavLopac

    I don’t understand why is everyone trying to fix something that isn’t broken? Instead of looking for new and convoluted ways to cram CSS to something it was not made for, they should try learning what CSS is and how to properly separate your content from your layout.

    I keep getting into arguments with my designers when I tell them that the design is secondary, and I don’t mean that only as a matter of importance: on the Web, the design works best when applied after or on top of the semantic structure, not the other way around. The example in the article — the “reasonably common grid structure” is symptomatic of that design-centric pathology, as it makes no notion of the content: what goes into that boxes? Which are the main elements of the page?

    In my ideal world, the designers are given a page HTML structure, optimized for content, and then apply styles to it with no — or at the very most with absolute minumum of — modifications to the underlying structure. I know that the designers might argue that this is limiting, but I counter with the argument that it isn’t — at least no more than any other medium is, and in some ways much less (a Web page doesn’t have physical borders; you can put sound or animation in it, which you can’t on paper). And a good designer will certainly be able to smartly use the specifics of the medium to do wonders — if you think that this approach limits your creative freedom, go browse CSS Zen Garden for a while before coming back here.

  • Andrew

    This is awesome! Is there anything PHP based that can do this?

  • Molte

    SASS provides some of the same things as you describe Less does.

    And when you say variable, don’t you mean constant?

  • Anonymous

    This solution is rubbish, I think.. If you want to create CSS faster, having to ‘compile’ after every edit only slows you down…..

  • http://blog.afterlight.net.au AussieJohn

    @BerislavLopac:

    This isn’t a “fix” for CSS – this is an enhancement that allows you to easily write your CSS.

    Variable for example, can save you a lot of time – instead of having to type a colour like:
    color: #0067ea;
    You would be able to type
    color: @brand-color;

    I do feel your pain where designers are concerned – especially when dealing with ones who come from a print industry background. I often find that I have to explain over and over again that the web isn’t the same as print and all those reasons why. (Including answering questions like “why can’t you just use Helvetica [or insert other non web font] everywhere, don’t you guys use sifr or something?” *shudder*)

    In an ideal world, indeed we would be able to use a given HTML structure and put pretty much any design (that incorporates the elements in that structure) to it. Unfortunately we can’t always take such a simplistic approach as many sites have unique elements to them that require different markup. I will concede of course that I do use layout tempates with the most basic of elements present in them. (header, footer, content area, navigation, etc.)..

  • W2ttsy

    @BerislavLopac – I totally agree with you here. When I’m presented with PS comps I build the structure first and then add the CSS on top afterwards to give the structure “look and feel”. The less div’s or other HTML elements that I have to add afterwards (to compensate for poor design decisions), the more proud I feel of my result…

  • Martin

    it would be interesting to see if its easily possible to combine LESS and css-development-pattern like OOCSS.

    the nested stuff is bullshit as stormrider said.
    you could use the generated file but thats all extra work..

  • Marcel

    SRLSy Berislav is totally right. If you LEARN Css thouroughly you don’t need stuff like this. I agree: CSS is good the way it is. We – as developers are just not too happy with it, because our Clients still use IE6. The problem is not CSS, it’s the browser.

  • Arlen

    There’s a lot to like in Less, but it’s fatally flawed.

    Look at the mixin syntax. Now, tell me how someone reading the CSS file is supposed to tell that from a class.

    Nope. Not good enough. Next, please.

  • <a href+’http://www.juanitachronowski.com’ target=’new’>Juanita</a>

    @BerislavLopac: I think you miss the point. In this latest incarnation of web on the fly you are entering a theme based world. When you can change that theme as often as your mood then little ‘helpers’ like the variable within the CSS can be a great timesaver.

    I get it. I like it.

    I do want to ask if there is a browser compatibility list for CSS with Less. Or is it just a variety of features already cross browser tested.

  • http://www.heyraena.com raena

    @BerislavLopac, I’m not even convinced you read this too closely. What is it about this blog post that suggests anything opposite to the idea of separating content from layout?

  • http://www.lopsica.com BerislavLopac

    @raena, I think I probably wasn’t very clear in my comment, as I wrote and posted it in one go, without much editing. I didn’t intend to say that your article is opposite to that idea, but that the problem with solutions like Less is that they’re trying to solve the wrong problem, actually one that doesn’t even exist.

    Specifically, it is not about the separation of content and layout, but about the separation between content, structure and layout.

  • Mrcl

    You know, if only Microsoft would simply add the CSS variables and nesting in IE, just support it, because they can. Just do it. Mozilla and other browsers would swiftly follow even IF it’s not a W3C-standard. It’ll quickly become one.

    Just the variables alone would make life a lot easier. Additional functions to calculate colors would be quite nifty, too. Such as being able to take a color and substract a color from it in the RGB-spectrum:

    CSS:
    @pretty = RGB(50, 50, 100);
    @darkpretty = RGB(@pretty, -20, -20, -20);
    @transparentpretty = RGB(@pretty, 0, 0, 0, 50%);

    With that you could take 3 or 4 base colors, and determine all different shades of each color without having to think about it. Basically: Specify your base palet; the CSS will take care of the rest.

    Also, I’d love to be able to use inline comments.

  • RobertK

    @Arlen: Less’s syntax isn’t fatally flawed. Mixins are different, yes, but when the file’s extension is “.less” people will know, or quickly discover, this difference. And since the extension wouldn’t be “.css” it should be immediately evident that the code will differ in some capacity.

    Frankly, I like Sass’s way of doing mixins, by preceding the mixin with a plus sign.

  • Bryan Williams

    If you’re developing with Ruby on Rails, there is already an even better solution for this problem. It’s called Sass (Syntactically Awesome StyleSheets – go google it).

    I’ve been using it for about 6 months now and I must say, it’s hard to go back to regular css. If you mix it with Haml(another Ruby on Rails gem that does the same for markup) it’s really a powerful combination. You get rid of so much redundancy and usually cuts the lines in your markup by half.

    I admit though, I wish I had something like Haml & Sass for non-ruby on rails projects.

  • Theresa

    Correct me if I am wrong but isn’t {less} only available if you’re using ruby? That was the impression I got when I read their website and if this true then we are talking about a very specialized application that cannot be used for the majority of developers.

  • http://www.heyraena.com raena

    @Berislav, I’m still not sure what the issue is.

    This is just a different way to write CSS. You run Less-syntax code through Less, out comes regular old CSS. Whether you choose to write decent markup and impose a good structure on that markup is still entirely up to you.

  • aemciv

    Nice, was not aware that you could put a style right inside another style. Thanks for the tip!

  • Ziad

    First of all, use Em’s (!). This will enable you to change the total width, font-size or whatever size in one single place in your CSS. E.g. assign:

    body {font-size: 62.5%} /*Equals to 10px (.625*16px=10px) which means 1em in child is equal to 10px, 1.2 in child equals 12px and so on…*/

    Now all Em’s used for width and height in div’s are also based on that 10px. This implies that you can set:

    #wrapper {width: 96em} /* Equals to 96*10px=960px */

    Now make classes for the boxes:

    .box {float: left}

    .boxThird {width: 32em;} /* Equals to 32*10=320px; */
    .boxFourth {width: 24em;} /*etc.*/

    If you change the #wrapper now the latter classes will alter the sizes of the inner boxes accordingly.

    NB. This techniques makes use of multiple classes.

    #wrapper=

    Why not use multiple classes instead? Classes are variables in a sense. E.g.
    .widthThird=320px;
    .widthFourth=240px;
    etc

  • Hudson

    I’ve been experimenting with dynamic CSS for a while now using PHP.

    I’m sure there are all sorts of loopholes and security issues with the following, but if you save your stylesheets with a .css.php extension, you can do stuff like…

      <?php $baseWidth = ‘960px'; ?>
      #wrap { width: <?php echo $baseWidth; ?>; }

    As I said, I am by no means saying that’s a bulletproof way of doing things, but it seems to work.

    Just playing around really.

  • http://logicearth.wordpress.com logic_earth

    @Ziad font-size: 62.5% does not equal 10px. Only when the browser is using a set default font size will it equal 10px.

  • mschutz

    I agree that variables/aliases would be great for things like colors. (But really, a simple Find/Replace in your favorite text editor isn’t that difficult.) And as some have already said, why not just use relative units like ems and % for things like widths?

    While there’s nothing bad about this, it just seems to be a complex solution to a problem that has simpler solutions. Sorry, I just don’t see how it really would save all that much time.

  • sitehatchery

    In PHP, all you need to do is place this at the top of a php file:
    header("content-type: text/css");
    Then, you can write whatever CSS you want, create variables with PHP, etc.

  • Fuji727

    In case anyone is looking for a PHP-based alternative, Shaun Inman released CSS Cacheer last year. I think the only things it lacks compared to Less are math operations and mixins (which are a great idea).

  • http://www.calcResult.co.uk omnicity

    Things like this always give me the impression that whoever wrote it was more proficient with the host language (Ruby in this case) than with the target language (CSS) which inevitably means that features that could be done one way get implemented like they are in the host language, which is almost invariably a bad idea.

    For me, the number one missing feature in CSS is the ability to calculate widths. So many times I have wanted to have an element be “full-width minus 120px” but no pre-compiled CSS is ever going to be able to help with that.

  • Leialoha

    Aloha,

    I think the idea is great, would be nice if CSS would develop into such a direction. love the idea of haven variables so that you can change stuff on one spot, what css already is doing…

    But I would prefer if CSS would be altered in future this way in general so I can use it with out compiling it.. this is a step to much for me, copy & pase, find and replace works well too.

    I think some people here are loving their ways, I think we all can think flexible and try to make it a better programming world. There are many ways to Thank you for sharing, I love the idea and your article.

    Much Love from Hawaii

    Be the change you wanna s

  • Michael

    Sitepoint is about 2 weeks behind the rest of the internet. LESS has already come up in my Google Reader about 4 times by now.

  • Arlen

    @RobertK

    Yes, it’s fatally flawed. Take this example straight from the article:

    .box {
    float: left;
    }

    There is no way to tell by looking at it if this is a class (named “box”) or a mixin (named “box”). It’s legal for either one to be in the Less file. The only way you can tell what you’re looking at is to read farther in the document and see how it’s used.

    BTW, I agree that Sass is better than Less, if for no other reason than it avoids this type of confusion.

  • http://blog.afterlight.net.au AussieJohn

    @Anonymous:

    This solution is rubbish, I think.. If you want to create CSS faster, having to ‘compile’ after every edit only slows you down…..

    You can set Less to “Watch” a css file using the following command:
    lessc style.less --watch

    Less will now compile the CSS file any time there is a change to the file.

    @Arlen I’m going to have to disagree with you there – Less isn’t fatally flawed, especially for it’s mixin functionality.

    The idea with the mixins is that you take an existing “base” class and mix it in with other ones, the other class can then inherit the styles from the mixin.

    So you define:
    .box {
    float:left;
    }

    Now you want to make a particular other div also be a box:
    div#somediv {
    .box;
    }

    Of course if you want to not be confused you could prefix all your mixin classnames with something. If someone is reading your CSS file they don’t need to know about which classes are mixins, because it will be a compiled file.

    Another thing that should be cleared up is that you do not need to build your website using Ruby. You only need to have Ruby installed to use this program when you are developing your CSS.

  • Nasty Hobbit

    This is a great idea, I would start using this right now. But the ruby … it burns :(

  • http://www.heyraena.com raena

    @Arlen, isn’t that what comments are for?

  • http://www.tyssendesign.com.au Tyssen

    I admit though, I wish I had something like Haml & Sass for non-ruby on rails projects.

    Same here. I haven’t ventured into either of those yet because of the Ruby factor.

    I agree with BerislavLopac about his approach to writing HTML/CSS but I certainly don’t agree that something like LESS wouldn’t be useful.

  • Nathan Weizenbaum

    It’s perfectly possible to use Sass with non-Ruby projects. The Compass project can watch an entire directory of Sass files for updates and dump the CSS to a stylesheet directory – this works right from the command line, no Ruby required. This functionality is going to be merged into Sass in the future as well.

  • Arlen

    @raena, In a word, no. Comments are not for explaining away the ambiguity of the language. Languages should be unambiguous without comments. Comments are not for what the code does, comments are for why the code is doing it. Think of variable names: comments are not for explaining what the variable is (that’s what the variable name is for).

    If you were writing php, and named every variable $i, you’d be guilty of bad coding practice, even if you explained in the comments which $i meant what. The problem we have in Less, is that the language gives you no choice but to write bad code.

    @Tyssen, try phpHaml; it’s the PHP-based version of Haml. (Haml isn’t limited to Ruby, unlike Less.) There’s also a version of Sass for php on github. Have a look and see about it. While Ruby is a far more elegant language than PHP, it’s not selfish; it doesn’t keep *everything* for itself. (Yes, I’m teasing the PHP fans. A little good-natured rivalry keeps us all on our toes.)

    @AussieJohn, I don’t think the mixin functionality is flawed, just the syntax. It’s always a bad idea to take the same syntax and make it mean different things in different situations, because it causes confusion. That’s why the comparison operator is == instead of =, among other things (the fact you can then assign inside of an if is an effect of that syntax, not the cause of it).

    Your example would be handled by a better language with creating a mixin (with unique syntax) and then using it within both the class and the id you provide as examples. The problem with Less is it doesn’t permit you to create a mixin that is at all distinguishable from a class. If I were to create a unique class for that mixin, then another person on the team might look at the html files, think the class is now unused, and trim it out of the file. With this mixin syntax, not only do you have to check the (x)html files, you have to check the less files as well.

  • Alexis Sellier

    @Arlen, mixins *intentionally* use the same syntax as classes, that’s what makes it powerful: any class/id can be mixed in any other class, and still used as a standard class in your html.

    I’m not changing what a class means, I’m giving the user the ability to use any class as a mixin.

    Regarding Sass, I of course know about it, but didn’t enjoy using it because of its awkward syntax and picky indentation rules.

    cloudhead (author of less)

  • http://www.papayasoft.com/ rundmw

    For a PHP version of a CSS preprocessor, take a look at DtCss.

  • Wukfit

    This might be slightly off topic but considering all the talk of website performance and writing faster code I though I should point out that writing css rules like this:

    #banner a {...}
    #banner p {...}
    #banner p a span {...}

    will slow down a browsers rendering of the page due to how they perform css selector matches (right to left).

  • http://www.calcResult.co.uk omnicity

    @Wukfit
    Do you have any figures to say how much effect that has?

  • davidcroda

    Cool info. Can that command be run to dynamically generate perfect stylesheets based on the users screen width? That’d be neat

  • http://www.calcResult.co.uk omnicity

    @Davidcroda
    How do you expect a pre-processor to know how wide a users screen is?

    I would love to have that in native CSS, but LESS isn’t going to be able to provide it.

  • davidcroda

    @omnicity

    Sorry I guess I’m not too familiar with the way ruby works. I was assuming you could get that information via javascript or php and then pass it to the function to generate the stylesheet and link it before the page is rendered.

  • http://www.heyraena.com raena

    @Arlen, I’m utterly baffled as to how Less actually *gives you no choice* (seriously?) to write bad code. Seriously? There’s NO possible way to write decent code using this?

  • Arlen

    @cloudhead OK, so your “mixins” are simply another way of doing what we’ve been able to do for years without ever involving the CSS file in the first place, namely assigning a class to an element that has another class or id already assigned to it?

    I’m afraid the clarification doesn’t change my assessment of it. There’s still no way to tell from looking at it whether this is a class that was written for the purpose of styling an element, or a class/mixin/codechunk that was written solely for the purpose of being included in other ids/classes. And it still means that cleaning up after a development sprint will still require looking for that class/mixin/codechunk will require looking in not only the content files, but the less/css files for where it’s used.

    @raena, What I meant was that, like using the same variable name over and over, the Less mixin syntax leaves you no way to write it without having to leave commentary or other documentation behind to explain what you’re doing (“class A is a real class, but class B here is a fake class that only exists because I want to use it as a mixin”). And code is like humor. When you *have* to explain it, it’s bad code.

    While I think all attempts to turn CSS into a programming language are misguided (it’s a design language, it shouldn’t take a developer’s approach — object oriented inheritance, and all that — but rather a designer’s approach) Less’s mixin syntax bothers me more than others because it doesn’t even get the programming approach right. That’s the “fatal flaw” that will keep me from using Less.

    @cloudhead makes a good point later in the post. While I can certainly empathize with @cloudhead’s view of it (I don’t use Sass, either) designers “get” picky indentation rules more easily than they “get” most standard development concepts.

  • YahyaAziz

    Raena, thanks for an interesting (and obviously provocative!) article.

    I agree with Molte, who said: “And when you say variable, don’t you mean constant?”

    I also agree with Arlen – right up to the point when she or he (rather contentiously) implies that designers don’t get the reusability of heritable class attributes. I think that any designer worth her salt understands the principles of modularity and of design integrity very well indeed.

    Why not campaign for the kinds of simple improvements to CSS that would make all these preprocessor-type tools unnecessary? It wouldn’t take much:

    1. Include named constants eg:
    @logo-color = #abcdef;

    and invoke them with:
    color: @logo-color;

    2. Allow run-time arithmetic on constants, eg:
    @base = 960px;

    invoked with:
    width: @base / 3;

    3. Allow class inheritance, as per Less’ mixin in Raena’s example:
    #super {
    #footer;
    font-family: cursive;
    }

    Designers, just as much as programmers, would welcome the chance to (a) defer and (b) readily change, the decisions they take. We all know that most design changes are customer-driven, and adding flexibility to respond quicker to customer requests makes everyone look good.

    We’re not talking an insurmountable extra run-time load involved in these kinds of changes (unless used to baroque excess).

    Just my 5c. worth (Anyone seen two cents lately?)

  • http://www.lopsica.com BerislavLopac

    @YahyaAziz: The last item is completely unnecessary, as it can already be easily done as .footer.super.

  • http://blog.afterlight.net.au AussieJohn

    @BerislavLopac: Don’t forget that it’s not always practical to add classes to elements, not to mention that it certainly isn’t semantic in a lot of cases. With, as you suggested – a different syntax to indicate that a class is a mixin (something like %mixinClassname or +mixinClassname perhaps?). I think this could be a very successful feature of CSS.

    @YahyaAziz Don’t leave out the nested rules :-)

    #banner {
    2 color: white;
    3 background: black;
    4 a { color: yellow; }
    5 p { margin: 0em; }
    6 ...
    7 }