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).

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:

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.

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.

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).

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.