Category: CSS

Custom Style Sheet coding and best practices

  • 7 ways to tell your css has gone mental

    I work on big sites almost exclusively so my techniques are all about wrangling tens of thousands of lines of code into a few thousand. When deadlines loom or you work with a staff of various skill levels css begins to loose its organization.

    So here are a few things to look for to know its time to reorganize your code.

    1. When !important becomes a way of life. When the only way to get a piece of code to to work is to wrap !important to the end of every line, your css has gone mental.
    2. When you scroll through the style definitions and see !important sprinkled liberally throughout the styles. Your code has definitely gone mental. Seriously if there are so many clashing definitions that only an !important can solve it you need to look into taking a BEM and SMACSS approach and flatten your definitions.
    3. If you need to change a color and have to do a find and replace to get to them all your code has gone mental. It is time to preprocess your css. I prefer Sass just because it has super powers, but Less is almost as good. Preprocessors allow you to use variables so you can keep all your definitions in one place and reference it everywhere.
    4. If additions to classes end up in a jumble at the end of a file it has gone mental. Choose a technique that makes it easy to find the classes that you need to change. Preprocessors allow you to break your styles into as many files you need to keep your css organized. Sass to the rescue again.
    5. When style definitions are nested five levels deep you know your code has gone mental. Use BEM naming conventions and ideas to flatten your styles and give all your elements a class name.
      Distinct modules should be able to live on any page in any location and maintain their styling. Doing this will help break your code down into manageable chunks.
    6. When the the slowest part of your site is how fast it renders the styles you know it has gone mental. When styles get too complex it can slow down the site and leave it hug half broken till it finishing going through all the exceptions from the nested rules. Again flattening your rules and proper naming would go a long way toward resolving that. BEM has helped me organize my code into something a bit more manageable over the long term.
    7. using # over . will drive your site mental. Specifity will ruin your day ,but adding IDs among your definitions will just overpower any classes and make fixes that much harder. Avoid them on anything but page structure. Using IDs on modules may be moved to new pages will just confuse things when duplicate IDs start showing up on the same page. It will render but it may break js and cause conflicts when there is an ID and a class, but you are only working on the class. Consolidate styles into just the classes helps that.

    Here is a great talk about organizing CSS using OOCSS, SMACSS and BEM and SASS. OOCSS has been absorbed into SMACSS and BEM principles so it isn’t mentioned as much any more.

  • Internet Explorer 7 Compatibility Mode

    Well Internet Explorer 9 is finally here and we will now have to code for it. If you’re like me working in a production environment then most likely it is more of a hassle than a blessing since IE 6 through 9 are still out there.

    The best practice is to code for the widest compatibility which, for internet explorer, is IE 7. I left out IE 6 since even Microsoft is trying to get rid of that albatross.

    There is a piece of code you can add to your website to force later versions of Internet Explorer to only view the webpage as IE 7. It uses something called compatibility mode.

    Internet Explorer 7 Compatibility Mode.

    this is the code:

    <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" >

    place this with the other meta tags in the HEAD of the web page.
    If you want to test if the page is actually using the correct view mode type the following code into the address bar. (if you paste it some of the commands will disappear so watch for that.)

    javascript:alert(document.documentMode);
  • CSS Expressions

    I’ve come across expressions in CSS style sheets and decided to investigate if they really were as powerful as they seem. Expressions are JavaScript code that is applied as part of a class in the style sheet,  this is useful for keeping all the elements of that class from expanding beyond a specific size for instance . While it may seem like a good idea it turns out that it is more likely to cause your webpage to lag. Expressions are re-evaluated every time there is any interaction with the page, instead of when you want it too.

    The best practice is to use JavaScript. Especially with JavaScript libraries and frameworks out there the need for css expressions are gone. My recommendation is to Avoid CSS Expressions, use JQuery, Prototype, MooTools or Scriptaculous instead