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.

CSS

• 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

HTML

• Writing all tags and attributes in uppercase for readability. While this is not strictly wrong if you’re using HTML instead of XHTML, it’s extremely unusual to see front-end developers use anything but lowercase for tags and attributes. Just follow the convention and stick to lowercase. Also see my HTML5 syntax guidelines.
  
• Store your application’s state as a hash in a single hidden input on the page, because page-weight is not my problem. ViewState is just one of the things that ASP.NET gets wrong about HTML. Adding dozens of KB (I’ve even seen ViewState hashes that are several MB in size) of nonsense that gets roundtripped to the server each time a user clicks a link (because if you’re using ViewState you’re also likely to be using postback, another ASP.NET abomination) will slow down your site.
  Get rid of the ViewState and postback madness and store the state server-side if you really need it.
  
• Bullet-proof rounded corners that work all the way down to netscape 4.79. Besides using tables for layout, adding this much markup to achieve a visual effect in ancient browsers is just punishing everybody. Use progressive enhancement instead to create the rounded corners with CSS and let older browsers get square corners.
  
• Never leaving an img tag unclosed. Void elements (elements that do not have content) cannot have closing tags in HTML. See Void (empty) elements and self-closing start tags in HTML for a more detailed explanation.
  
• Saving bandwidth with unclosed li tags. Technically valid in HTML, leaving out optional closing tags is markup geekery that will only make maintenance harder. Always explicitly include all closing (and opening) tags in your markup. Again, see my HTML5 syntax guidelines.
  
• Creating forms without the need for cumbersome label elements. If you do not use the label element to associate each form control with its label text you are reducing accessiblity. More details on how to use the label element can be found in Use the label element to make your HTML forms accessible.
  
• Liberally using documentation to describe sections of content. I’ve never understood why some people put comments to label the start and end of elements in their markup. If you indent your markup properly it’s self-evident, so just do some de-cluttering and remove the comments.
  
• Every single tag gets an id or class, because how else would you style it?. By using descendant selectors, that’s how (see CSS 2.1 selectors, Part 2 for details). Adding class and/or id attributes to everything increases page weight and adds clutter, so get rid of most of them.
  

JavaScript

• A fully dynamic layout management framework and Initializing your layout. JavaScript should not be used to create layouts. That’s what you use CSS for. Using JavaScript for some workarounds (like equal height columns) can be OK, but never rely on JavaScript for the main layout.
  
• Use HTML5 to link links to functions that link to links. Let links be links. Do not make links JavaScript-dependent (unless you also use JavaScript to insert them).
  
• Always add more comments, especially where they are most important… in the middle of statements. Commenting your code is generally a good idea, but don’t overdo it. Comment things that aren’t obvious, and do not add comments in the middle of statements since that makes reading the code much more difficult.
  

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.