Enterprise HTML, CSS and JavaScript explained

A while ago I posted Tips for creating enterprise-level HTML, CSS and JavaScript, where I mentioned a few examples from the Enterprise CSS, Enterprise HTML, and Enterprise JavaScript sites.
The examples on those sites are meant to be ironic, showing what not to do. Some readers have contacted me because they feel that the irony isn’t completely obvious and are worried that people getting started in front-end web development would misinterpret the “tips”. They do have a point, so I thought I’d bring up a few of the examles from the Enterprise CSS/HTML/JS sites and explain why I think they are bad examples.
This isn’t a comprehensive list, and please note that some of my explanations may be somewhat biased by personal preference.


  • Organize properties/value pairs by length. This may look neat in your CSS file but makes maintenance a hassle since each time you change a value you may need to reorganise the properties. It will also lead to properties that are logically connected to be far apart (color and background is one example).
    Instead I suggest ordering properties logically based on how they affect layout. At work we use an order we found in a Mozilla guideline years ago (can’t find it now though). The order is quite similar to the one in this comment on How do you order your properties within a declaration block?.
    Update: Found the Mozilla document I was thinking of: http://www.mozilla.org/css/base/content.css. Thanks to Christoph Tavan for the tip. I see now that we have tweaked the order a bit (unless it’s the Mozilla document that’s changed).
  • Use meticulously nested style rules including at least two ids per line. Doing this will give you inheritance problems sooner rather than later. You’ll end up adding more and more ids to your selectors to get a higher specificity, and likely a whole bunch of !important declarations as well. A better option is to make selectors as short as possible and only include ids when you really have to. And !important should only be necessary in very rare cases, if ever.
  • Coding with ie8 in mind… and ie7… and ie6… Adding some CSS workarounds for older versions of Internet Explorer is pretty much inevitable. Using conditional comments to separate the workarounds from the CSS meant for proper browsers is what I do as well, but spreading them out over several CSS files will just lead to more HTTP requests and is simply overkill. Instead put them all in the same file, tell IE 8 and below to load it (because IE 9 is supposed to handle CSS properly, right?) and use CSS hacks to target different IE versions:
    • * html h1 {} targets IE 6
    • html > body h1 {} targets IE 7 and later
    • h1 {*property:value;} targets IE 7 and below
    • html > body h1 {*property:value;} targets IE 7 only



Not just “Enterprise”

While many of the practices described on Enterprise CSS/HTML/JavaScript are indeed especially common on large sites and in “enterprise-level” CMSs, many can be found elsewhere as well. I’m sure we’re all guilty of some of them from time to time.


Copyright © 2013 Technology Effect and Blogger Templates - Anime OST.