Managing CSS Explosion

Question

I have been heavily relying on CSS for a website that I am working on. Right now, all the CSS styles are being applied on a per tag basis, and so now I am trying to move it to more of an external styling to help with any future changes.

But now the problem is that I have noticed I am getting a "CSS Explosion". It is becoming difficult for me to decide how to best organize and abstract data within the CSS file.

I am using a large number of div tags within the website, moving from a heavily table-based website. So I'm getting a lot of CSS selectors that look like this:

div.title {
  background-color: blue;
  color: white;
  text-align: center;
}

div.footer {
  /* Styles Here */
}

div.body {
  /* Styles Here */
}

/* And many more */

It's not too bad yet, but as I am a beginner, I was wondering if recommendations could be made on how best to organize the various parts of a CSS file. I don't want to have a separate CSS attribute for every element on my website, and I always want the CSS file to be fairly intuitive and easy to read.

My ultimate goal is to make it easy to use the CSS files and demonstrate their power to increase the speed of web development. This way, other individuals that may work on this site in the future will also get into the practice of using good coding practices, rather than having to pick it up the way I did.

Solution 1

This is a very good question. Everywhere I look, CSS files tend to get out of control after a while—especially, but not only, when working in a team.

The following are the rules I myself am trying to adhere to (not that I always manage to.)

• Refactor early, refactor often. Frequently clean up CSS files, fuse together multiple definitions of the same class. Remove obsolete definitions immediately.

• When adding CSS during fixing bugs, leave a comment as to what the change does ("This is to make sure the box is left aligned in IE < 7")

• Avoid redundancies, e.g. defining the same thing in .classname and .classname:hover.

• Use comments /** Head **/ to build a clear structure.

• Use a prettifier tool that helps maintain a constant style. I use Polystyle, with which I'm quite happy (costs $15 but is money well spent). There are free ones around as well (e.g. Code Beautifier based on CSS Tidy, an open-source tool).

• Build sensible classes. See below for a few notes on this.

• Use semantics, avoid DIV soup - use <ul>s for menus, for example.

• Define everything on as low a level as possible (e.g. a default font family, colour and size in the body) and use inherit where possible

• If you have very complex CSS, maybe a CSS pre-compiler helps. I'm planning to look into xCSS for the very same reason soon. There are several others around.

• If working in a team, highlight the necessity of quality and standards for CSS files as well. Everybody's big on coding standards in their programming language(s), but there is little awareness that this is necessary for CSS too.

• If working in a team, do consider using Version Control. It makes things that much easier to track, and editing conflicts that much easier to solve. It's really worth it, even if you're "just" into HTML and CSS.

• Do not work with !important. Not only because IE =< 7 can't deal with it. In a complex structure, the use of !important is often tempting to change a behaviour whose source can't be found, but it's poison for long-term maintenance.

Building sensible classes

This is how I like to build sensible classes.

I apply global settings first:

body { font-family: .... font-size ... color ... }
a { text-decoration: none; }

Then, I identify the main sections of the page's layout—e.g. the top area, the menu, the content, and the footer. If I wrote good markup, these areas will be identical to the HTML structure.

Then, I start building CSS classes, specifying as much ancestry as possible as long as it is sensible, and grouping related classes as closely as possible.

div.content ul.table_of_contents 
div.content ul.table_of_contents li 
div.content ul.table_of_contents li h1
div.content ul.table_of_contents li h2
div.content ul.table_of_contents li span.pagenumber

Think of the whole CSS structure as a tree with increasingly specific definitions the further away from the root you are. You want to keep the number of classes as low as possible, and you want to repeat yourself as seldom as possible.

For example, let's say you have three levels of navigational menus. These three menus look different, but they also share certain characteristics. For example, they are all <ul>, they all have the same font size, and the items are all next to each other (as opposed to the default rendering of an ul). Also, none of the menus has any bullet points (list-style-type).

First, define the common characteristics in a class named menu:

div.navi ul.menu { display: ...; list-style-type: none; list-style-image: none; }
div.navi ul.menu li { float: left }

then, define the specific characteristics of each of the three menus. Level 1 is 40 pixels tall; levels 2 and 3, 20 pixels.

Note: you could also use multiple classes for this but Internet Explorer 6 has problems with multiple classes, so this example uses ids.

div.navi ul.menu#level1 { height: 40px; }
div.navi ul.menu#level2 { height: 20px; }
div.navi ul.menu#level3 { height: 16px; }

The markup for the menu will look like this:

<ul id="level1" class="menu"><li> ...... </li></ul>
<ul id="level2" class="menu"><li> ...... </li></ul>
<ul id="level3" class="menu"><li> ...... </li></ul>

If you have semantically similar elements on the page—like these three menus—try to work out the commonalities first and put them into a class; then, work out the specific properties and apply them to classes, or, if you have to support Internet Explorer 6, ID's.

Miscellaneous HTML tips

If you add these semantics to your HTML output, designers can later customize the look of web sites and/or apps using pure CSS, which is a great advantage and time-saver.

• If possible, give every page's body a unique class: <body class='contactpage'> this makes it very easy to add page-specific tweaks to the style sheet:

  body.contactpage div.container ul.mainmenu li { color: green }
  

• When building menus automatically, add as much CSS context as possible to allow extensive styling later. For example:

  <ul class="mainmenu">
   <li class="item_first item_active item_1"> First item </li> 
   <li class="item_2"> Second item </li> 
   <li class="item_3"> Third item </li> 
   <li class="item_last item_4"> Fourth item </li> 
  </ul>
  

  This way, every menu item can be accessed for styling according to its semantic context: Whether it's the first or last item in the list; Whether it's the currently active item; and by number.

Note that this assigning of multiple classes as outlined in the example above does not work properly in IE6. There is a workaround to make IE6 able to deal with multiple classes. If the workaround is not an option, you will have to set the class that is most important to you (item number, active or first/last), or resort to using IDs.

Solution 2

Here are just 4 examples:

• CSS Conventions / Code Layout Models
• Are there any CSS standards that I should follow while writing my first stylesheet?
• What is the best method for tidying CSS?
• Best Practices - CSS Stylesheet Formatting

On all 4 my answer has included the advice to download and read Natalie Downe's PDF CSS Systems. (The PDF includes tons of notes not in the slides, so read the PDF!). Take note of her suggestions for organization.

EDIT (2014/02/05) four years later, I'd say:

• Use a CSS pre-processor and manage your files as partials (I personally prefer Sass with Compass, but Less is quite good as well and there are others)
• Read up on concepts like OOCSS, SMACSS, and BEM or getbem.
• Take a look at how popular CSS frameworks like Bootstrap and Zurb Foundation are structured. And don't discount less popular frameworks - Inuit is an interesting one but there are plenty others.
• Combine/minify your files with a build step on a continuous integration server and/or a task runner like Grunt or Gulp.

Solution 3

Don't write headings in CSS

Just split sections into files. Any CSS comments, should be just that, comments.

reset.css
base.css
somepage.css
someotherpage.css
some_abstract_component.css

Use a script to combine them into one; if necessary. You can even have a nice directory structure as well, and just have your script recursively scan for .css files.

If you must write headings, have a TOC at the start of the file

The headings in the TOC should be perfectly equal to headings you write later. It's a pain to search for headings. To add to the problem, how exactly is anyone suppose to know you have another header after your first header? ps. don't add doc-like * (star) at the start of each line when writing TOCs, it just makes it more annoying to select the text.

/* Table of Contents
   - - - - - - - - -
   Header stuff
   Body Stuff
   Some other junk
   - - - - - - - - -
 */
...
/* Header Stuff 
 */
...
/* Body Stuff 
 */

Write comments with or within the rules, not outside the block

First off, when you edit the script there is a 50/50 chance you'll pay attention to what is outside the rule block (particularly if it's a big glob of text ;) ). Secondly there is (almost) no case where you would need a "comment" outside. If it is outside, it is 99% of the time a title, so keep it like that.

Split the page into components

Components should have position:relative, no padding and no margin, most of the time. This simplifies % rules a lot, as well as allowing for much simpler absolute:position'ing of elements, since if there's a absolute positioned container the absolute positioned element will use the container when computing top, right, bottom, left properties.

Most DIVs in a HTML5 document are usually a component.

A component is also something that can be considered a independent unit on the page. In laymen's terms treat something like a component if it makes sense to treat something like a blackbox.

Going with the QA page example again:

#navigation
#question
#answers
#answers .answer
etc.

By splitting the page into components, you split your work into manageable units.

Put rules with a cumulative effect on the same line.

For example border, margin and padding (but not outline) all add to the dimensions and size of the element you are styling.

position: absolute; top: 10px; right: 10px;

If they are just not that readable on one line, at least put them in close proximity:

padding: 10px; margin: 20px;
border: 1px solid black;

Use shorthand when possible:

/* the following... */
padding-left: 10px;
padding-right: 10px;
/* can simply be written as */
padding: 0 10px;

Never repeat a selector

If you have more instances of the same selector, there's a good chance you'll inevitable end up with multiple instances of the same rules. For example:

#some .selector {
    margin: 0;
    font-size: 11px;
}
...
#some .selector {
    border: 1px solid #000;
    margin: 0;
}

Avoid using TAGs as selectors, when you can use id/classes

First off the DIV and SPAN tags are the exception: you should never use them, ever! ;) Only use them to attach a class/id.

This...

div#answers div.answer table.statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
div#answers div.answer table.statistics thead {
    outline: 3px solid #000;
}

Should be written like this:

#answers .answer .statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

Because the extra dangling DIVs there add nothing to the selector. They also force a unnecessary tag-rule. If you were to change, for example, .answer from a div to a article your style would break.

Or if you prefer more clarity:

#answers .answer .statistics {
    color: pink;
    border: 1px solid #000;
}
#answers .answer table.statistics {
    border-collapse: collapsed;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

The reason being the border-collapse property is a special property that only makes sense when applied to a table. If .statistics is not a table it should not apply.

Generic rules are evil!

• avoid writing generic/magic rules if you can
• unless it's for a CSS-reset/unreset, all your generic magic should apply to at least one root component

They don't save you time, they make your head explode; as well as make maintenance a nightmare. When you're writing the rule, you may know where they apply, however that has no guarantee your rule won't mess with you later on.

To add to this generic rules are confusing and hard to read, even if you have some idea of the document you're styling. This is not to say you shouldn't write generic rules, just don't use them unless you truly intend for them to be generic, and even them add as much scope information into the selector as you can.

Stuff like this...

.badges {
    width: 100%;
    white-space: nowrap;
}

address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

...has the same problem as using global variables in a programing language. You need to give them scope!

#question .userinfo .badges {
    width: 100%;
    white-space: nowrap;
}

#answers .answer .userinfo address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

Basically that reads as:

components                   target
---------------------------- --------
#answers .answer   .userinfo address
-------- --------- --------- --------
domain   component component selector 

I like using IDs whenever a component I know is a singleton on a page; your needs may be different.

Note: Ideally, you should write just enough. Mentioning more components in the selector however is the more forgiving mistake, compared to mentioning less components.

Lets assume you have a pagination component. You use it in many places across your site. This would be a good example of when you would be writing a generic rule. Lets say you display:block the individual page number links and give them a dark gray background. For them to be visible you have to have rules like this:

.pagination .pagelist a {
    color: #fff;
}

Now lets say you use your pagination for a list of answers, you may encounter something like this

#answers .header a {
    color: #000;
}
...
.pagination .pagelist a {
    color: #fff;
}

This will make your white links black, which you don't want.

The incorrect way to fix it is:

.pagination .pagelist a {
    color: #fff !important;
}

The correct way to fix it is:

#answers .header .pagination .pagelist a {
    color: #fff;
}

Complex "logic" comments don't work :)

If you write something like: "this value is dependent on blah-blah combined with height of blah-blah", it's just inevitable you'll make a mistake and it will all fall down like a house of cards.

Keep your comments simple; if you need "logical operations" consider one of those CSS templating languages like SASS or LESS.

How do you do I write a color pallet?

Leave this for the end. Have a file for your entire color pallet. With out this file your style should still have some usable color-pallet in the rules. Your color pallet should overwrite. You chain selectors using a very high level parent component (eg. #page) and then write your style as a self sufficient rule block. It can be just color or something more.

eg.

#page #header .description,
#page #categories .description,
#page #answers .answer .body
{
    color: #222; background: #fff; 
    border-radius: 10px;
    padding: 1em;
}

The idea is simple, your color pallet is a stylesheet independent of the base style, which you cascade into.

Less names, requires less memory, making the code easier to read

Using fewer names is better. Ideally use very simple (and short!) words: text, body, header.

I also find combination of simple words is easier to understand then having a soup of long "appropriate" words: postbody, posthead, userinfo, etc.

Keep the vocabulary small, this way even if some stranger coming in to read your style-soup (like yourself after a few weeks ;)) only needs to understand where words are used rather where every selector is used. For example I use .this whenever a element is supposedly "the selected item" or "the current item", etc.

Clean up after yourself

Writing CSS is like eating, sometimes you leave a mess behind. Make sure you clean up that mess, or the garbage code will just pile up. Remove classes/ids you don't use. Remove CSS rules you don't use. Make sure everything is nice a tight and you don't have conflicting or duplicated rules.

If you, as I suggested, treated some containers as black-boxes (components) in your style, used those components in your selectors, and kept everything in one dedicated file (or properly split a file with a TOC and headers), then your work is substantially easier...

You can use a tool such as the firefox extension Dust-Me Selectors (tip: point it to your sitemap.xml) to help you find some of the junk hidden in your css nukes and carnies.

Keep a unsorted.css file

Say you are styling a QA site, and you already have a stylesheet for the "answers page", which we will call answers.css. If you now need to add a lot of new css, add it to the unsorted.css stylesheet then refactor into your answers.css stylesheet.

Several reasons for this:

• it's faster to refactor in after you're finished, then it is to search for rules (that probably don't exist) and inject code
• you will write stuff that you will remove, injecting code just makes it harder to remove that code
• appending to the original file easily leads to rule/selector duplication

Solution 4

Have a look at 1. SASS 2. Compass

Solution 5

The best way I've seen to counter CSS bloat is using Object Oriented CSS principles.

There's even an OOCSS framework out there that's pretty good.

Some of the ideologies go against a lot of what's been said here in the top answers but once you know how to architect CSS in an object oriented fashion you'll see it actually work at keeping code lean & mean.

The key thing here is to identify 'Objects' or building block patterns in your site and architect with them.

Facebook hired the creator of OOCSS, Nicole Sullivan to get a lot of savings in their front end code (HTML / CSS). Yes you can actually get savings not only in your CSS, but in your HTML too, which by the sound of it, is very possible for you as you mention converting a table based layout into a lot of div's

Another great approach is similar in some aspects to OOCSS, is to plan and write your CSS to be scalable and modular from the start. Jonathan Snook has done a brilliant write up and book/ebook about SMACSS - Scalable and Modular Architecture for CSS

Let me hook you up with some links:
5 mistakes of massive CSS - (Video)
5 mistakes of massive CSS - (Slides)
CSS Bloat - (Slides)

View more solutions

Comments

[G-Wiz]

This says nothing about the asker's concern about having "a separate CSS attribute for every single thing".

[Pekka]

@Alix Axel, very good point. I'll see whether I get around to elaborating some more on that later. @Jason you're welcome - actually it's a good thing for myself to actually put this into words.

[Pekka]

@Alix Axel and @all, I tried to elaborate a bit on what I believe is sensible building of classes. Feedback very welcome, also on whether it is understandable at all. It's quite tough to put into words. Also, is it too much?

[Joe Dargie]

One day (when browsers that don’t support :first-child and :last-child are a distant memory in our log files), we can get rid of item-first and item-last. Not yet though. (Hello, IE 6.) I sometimes call these first-child and last-child, just to make it clearer what they’re filling in for.

[Pekka]

@Paul cheers for mentioning the proper CSS syntax and IE6, because IE6 has trouble with multiple classes assigned to an element, so my example won't work out of the box. Added caveats.

[Joe Dargie]

Oh yeah — sometimes I pop in a multiple class selector because it’ll work in IE 6 with the way the code is now, then later I’ll change something and suddenly IE 6 is shot to hell because the assumption that made the multiple class selector work isn’t there any more. It’s such a useful selector. ie7-js works great whenever I’ve used it (I haven’t used it extensively).

[Pekka]

@Alix Axel thanks!! @Paul good to know it works well, it's not always the case with IE6 band-aids.

[JasCav]

@Pekka @all - Excellent answer and very well thought out. Thank you for taking the time to give all the input!

[hojberg]

a little bit off topic. you might want to check out stevesouders.com/blog/2009/06/18/simplifying-css-selectors on simplifying css selectors for a little better performance

[Pekka]

@hojberg this is an interesting link, I will see whether I find the time to work aspects from it into the answer over the next couple of days. Thanks!

[alpav]

Using IDs is bad just like using global variables in your Visual Basic code.

[Robusto]

@alpav: Sorry, that's incorrect. IDs are a terrific way to make like elements appear differently in different parts of a page without going nuts making up new class names.

[alpav]

@Robusto: Why making new ID name is harder than making new class name ?

[alpav]

@Robusto: making new class names is actually easier than ID names because with IDs you have to worry about global scope and with class names you need to worry only about uniqueness in local scope, same benefit as with local variables.

[Robusto]

@alpav: Write it the way that suits you. I, for one, enjoy tremendous benefits from using IDs, and I don't mind that they have to be unique on the page. In fact, I count on it. If you think they are just an alternative to a className, you may not be ready for serious CSS yet.

[Drew]

I'm curious as to why you advocate giving body tags a unique class rather than just an id?

[Pekka]

@Andrew mainly because in a dynamic environment (like a CMS) using an ID could easily lead to collisions (say, a user renaming a page to "contact", leading to that name being used as the body's ID, colliding with the contact form also named "contact"). I generally recommend using IDs as sparingly as possible for that reason.

[Zuul]

Good to Know that I've been working good regarding css files ;) One of the nicest answers that I've seen!! Keep Up the Good Work.

[Joe Dargie]

@alpav: it’s now months later, so this is probably a bit irrelevant, but in CSS, classes are just as global as IDs, in the sense that they’ll both affect any HTML element that has the ID or class.

[alpav]

@Paul D. Waite: No, they are not as global as IDs. You can't have different elements with same IDs, which requires you to maintain uniqueness of IDs, which is hard and bad. But you can have different elements with same classes, so classes don't have that BIG disadvantage. If you suggest that you can use only IDs because they are better than classes then you inherently suggest that it's good to write programs in C#/Java/C++/... where all variables and methods (private,public) are unique. That defeats the purpose of encapsulation - to be able to name locally without thinking globally.

[Joe Dargie]

@alpav: “You can't have different elements with same IDs, which requires you to maintain uniqueness of IDs, which is hard and bad.” Entirely correct, but that’s in HTML. It doesn’t really affect CSS considerations.

[Joe Dargie]

@alpav “That defeats the purpose of encapsulation - to be able to name locally without thinking globally.” Right, but CSS selectors are inherently global: when you write .myclass, you select everything with the class myclass. In CSS, classes are identical to ids in that respect.

[alpav]

@Paul D. Waite "but CSS selectors are inherently global": You don't have to use .myclass, you can and should use tag1.class1>tag2.class2>tag3.class3 which makes it safe to have different meaning of class3 under different tags, which makes it private. The difference between C# and CSS is that C# enforces privacy and in CSS you have to enforce it with your own coding standards.

[Joe Dargie]

@alpav: sure — entirely correct, but you can use descendant/child selectors to give IDs different meaning in CSS in just the same way. My point is that within CSS, classes are just as global as IDs. There are restrictions on how you can use IDs in HTML, but within CSS, they’re the same as classes. (Although now that I think of it, they are given higher specificity than classes in CSS.)

[alpav]

@Paul D. Waite: I see what you mean about CSS, but what is the point to consider CSS separately from HTML if CSS is never used without HTML ? When we say CSS we always imply "in conjuction with HTML", when we say HTML we imply "in conjuction with CSS". Do you agree with my original point considering CSS+HTML ?

[Joe Dargie]

@alpav: still not really. Your original point was “Using IDs is bad just like using global variables in your Visual Basic code“. You said using ids “ defeats the purpose of encapsulation - to be able to name locally without thinking globally”. You still have to think globally when using classes. Even if you universally use descendant/child selectors like you suggested, there’s still a class at the root.

[alpav]

@Paul D. Waite "there’s still a class at the root": as well as .Net framework namespace has word System at the root, jQuery library has $ at the root, HTML has BODY at the root. There is no problem having one class or one global variable at the root, but having everything at the root like with IDs is the problem that everybody should avoid. It's called namespace pollution.

[Joe Dargie]

@alpav: Equally you could have one id at the root, and it wouldn’t make the blindest bit of difference.

[Moin Zaman]

@Pekka you should check out www.oocss.org a lot of it goes against what you've mentioned here but its the best way I've seen to manage CSS bloat. See my answer below too: stackoverflow.com/questions/2253110/how-to-manage-css-explos‌​ion/…

[Alan H.]

A million times this. Using Sass has made me a more organized & powerful css wrangler than ever. It lets me organize styles across multiple files, nest styles, use variables, etc., etc., etc.

[Miguel Ping]

non-tag selectors are much slower that tag-based ones. All browsers have native methods to get a 'div' for example (or any other tag). If you let it be too generic ('.class'), the rendering engine will have to walk all elements of the DOM to see if a match exists.

[srcspider]

@Miguel Why would the rendering engine not have to walk all elements in the DOM to see if they are a DIV? If there is some special a optimization why isn't it applied to classes/ids? Do you have a source? The only visible performance killer I've noticed with CSS was due float spam -- it can cause the rendering engine to lag horribly on some browsers when scrolling the page (probably too many calculations).

[mwilcox]

I was going to vote this up for saying not to target tagNames (yay!) but then there was the part about not being generic (boo!)

[mwilcox]

@Miguel, it doesn't work that way. Browsers read a CSS string backwards, so it would take: "div .myclass" and find all ".myclass" classes, and then check if it is an ancestor of a div.

[srcspider]

@mwilcox I did not mean don't write generic ever... more along the lines of: don't be generic if it doesn't make sense to be, or if you can avoid it. Basically avoid the lazy tendency to write the shortest selector possible, and instead try to write a readable (or unambiguous) selector, when possible. I agree there are unique pros/cons to both approaches. Just considering the topic of maintainable/readable code this approach has worked better for me. :)

[gblazex]

Comparing generic rules to global variables is the greatest misconception I've ever heard about CSS.

[Moin Zaman]

sass, compass and less all produce normal CSS at the end of the day which could still be ugly and exploded. Its not a solution to CSS bloat in and of itself.

[Miguel Ping]

@srcscpider My bad. That only applies to js selectors, not css rendering

[Sam]

I would like to line up in this comment list to buy some DIV soup please! awesome post @Pekka wish I had read this earlier!

[Pekka]

@Sam thanks! I like it quite well, although I occasionally find these guidelines very hard to follow myself. CSS style sheets are so easy to screw up over time - a colour change here, a font-weight: bold there .... discipline is the only medicine :)

[bzx]

@Moin_Zaman In my humble opinion, sir, your statement is pure humbug. you write in sass/compass/less and organize your code in their files. you don't care about how the output css looks like. also, at least less (via less app) can minify the output which is great.

[Moin Zaman]

@bzx you're proving my point :) A browser does not understand sass/compass/less. all of these need to be compiled down to plain old CSS either clientside, or as part of your build. Using tools like these without knowing what they produce as CSS in the end makes it very easy to abuse them unknowingly and end up with larger than optimal CSS files.

[Istiaque Ahmed]

@Pekka, may I request you to have a look at this css, jquery related question : stackoverflow.com/questions/11728001/…

[Zach Lysobey]

"Sass/Less/Compass will only get things worse" - thats pretty subjective and project dependent. I would put forward that using one of these in conjunction with OOCSS would really benefit the maintainability of many large projects (especially those whose styles may be changed frequently)

[madr]

Zach L: OOCSS (or for that matter, SMACSS) used correctly makes Compass/Less/Sass needed for vendor prefixes only.

[Zach Lysobey]

I won't try to argue this too much (esp. since I don't currently use a pre-processor), but I'm pretty sure there are a bunch of people who DO find such things to be useful, even in combination with OOCSS/SMACSS outside of vendor prefix issues

[Pekka]

Consider building a style guide describing the tone of the site and use that to define the style sheets. Then, the intent of the content will be represented by the styles and using the typographic conventions should map through into the user-visible layout and styling.

[emik]

i use sass and it might be that this is a difference between sass and less, but i'm pretty sure it will compile as ` #parent { width: 100%; } #parent #child1 { background: #E1E8F2; padding: 5px; } #parent #child2 { background: #F1F8E2; padding: 15px; } `

[thirdender]

That's where gzip compression comes into play… Most web servers and browsers will communicate with gzipped content when possible. If you end up repeating a selector fragment multiple times, that will be zipped into a single hash table entry. The only real issue then is the amount of RAM necessary to parse the CSS rules in the browser.

[Mohamad]

@Pekka I would add that we should avoid specificity, as it makes for brittle CSS, and lack of reusability. For example, .nav and .content is better than nav.nav or div.content.

[Toni Leigh]

in 2015, the use of IDs is pretty universally avoided in CSS, and using several classes is definitely preferred

[Robusto]

@ToniLeigh: What I said in 2010 still applies today: an ID carries more weight than a class. This is true whatever current practices may be.

[Toni Leigh]

@Robusto - what's moved on is how those things are applied, which is what's happened with how it's suggested that we use IDs for styling

[Robusto]

That is not germane to this discussion. Nevertheless, let me point out that it is still good practice to use an ID for "name-spacing" styles: for example, #myId .myclass overrides a .myclass style for all .myclass elements contained within the #myId block. This way you get to reap the general benefits of .myclass (which could be 20 styles) while overriding certain ones you want to be different in the block.

[Robusto]

BTW, look at the page source for this site and count the instances of "id=" and then start searching all.css for a look at how nobody uses the id for styling anymore.

[ari gold]

Speaking as someone new to the study of css explosion, the phrase "unique class" is confusing. I'm getting the feeling that that isn't an id but it sure sounds like one. Maybe the concept could be clarified?

[Pekka]

@ari you're right that that could technically be an id, too.

[Daniel Sokolowski]

CSS pre-processors are the cause of the problem rather than the solution. Master the cascading concept truly and you'll reduce bloat.

[Andy Ford]

@DanielSokolowski any improperly used tool can be a problem rather than a solution. But 100% agree on the point of mastering the cascade.