Keeping your css and xhtml code clean
So I just got done reading Smashing Magazine’s post on ’12 principles of keeping your code clean’ and I must say its spot on. Obviously, there are hundreds of ways to keep your code clean, organized, structured, and hack free (*cough IE*), but its a great starting list.
I can’t say I fully agree with #1 though.
#1 – Strict DocType
If we are going to do this, let’s just do it right. No need for a discussion about whether to use HTML 4.01 or XHTML 1.0: both of them offer a strict version that will keep us nice and honest as we write our code. Our code doesn’t use any tables for layout anyway (nice!), so there really is no need for a transitional DOCTYPE.
I personally have used Transitional in all my projects, simply because it “does” give me additional leeway if needed when dealing with IE at times. When it comes to getting all major browsers to visually reflect the same result, Transitional has always worked wonders for me.
#2 – Character set & encoding characters
Actually this was a surprise for me, I never looked at switching up the order between Title and the Meta fields.
In our
section, the very first thing should be the declaration of our character set. We’re using UTF-8 here, which is swell, but it’s listed after our. Let’s go ahead and move it up so that the browser knows what character set it’s dealing with before it starts reading any content at all. While we’re talking about characters, let’s go ahead and make sure any funny characters we are using are properly encoded. We have an ampersand in our title. To avoid any possible misinterpretation of that, we’ll convert it to & instead.
So I will be implementing that change in sites I work on going forward.
#3 – Indention
Indention is often neglected by developers (sometimes by myself as well),and is extremely important when debugging hundreds of lines of code as to why an element isn’t floating correctly, or padding is off, etc…
All right, we are about three lines in and I’m already annoyed by the lack of indentation. Indentation has no bearing on how the page is rendered, but it has a huge effect on the readability of the code. Standard procedure is to indent one tab (or a few spaces) when you are starting a new element that is a child element of the tag above it. Then move back in a tab when you are closing that element.
#4 – Keep your CSS and JavaScript external
Keeping your css and js external for small to medium sites is spot on, but with my experience at ChaCha, there were many times we had set the styles within style blocks, or JS inside script blocks within the <head> because it helped the page render slightly faster, or we were linking too many script/link files causing more then enough http requests. Limiting the http requests is just as important to the user experience as code cleanliness is.
We have some CSS that has snuck into our
section. This is a grievous foul because not only does it muddy our markup but it can only apply to this single HTML page. Keeping your CSS files separate means that future pages can link to them and use the same code, so changing the design on multiple pages becomes easy.
#5 – Nest your tags properly
Properly nesting your tags properly is just web standards common sense 101. Sure, flukes happen from time to time, but if you have a habit of improperly nesting your tags such as block elements inside inline elements, or not closing tags properly (i.e; self closing tags like IMG or BR), then you need to see the Dr., take 2 pills, and call me in the morning.
The title of our site, “My Cat Site,” is properly inside <h1> tags, which makes perfect sense. And as per the norm, the title is a link to the home page. However, the anchor link, <a>, wraps the header tags. Easy mistake. Most browsers will handle it fine, but technically it’s a no-no. An anchor link is an “inline” element, and header tags are “block” elements. Blocks shouldn’t go inside inline elements. It’s like crossing the streams in Ghostbusters. It’s just not a good idea.
#6 – Eliminate unnecessary divs
I agree, and disagree at the same time. Again, to my first point that to get browser friendliness across the board, I have found adding a wrapping div to various pieces on the page, because padding or margin will be applied, ends up making my life that much more easier. There have been plenty of times I try and remove any uncessary code, and then I find I need to adding padding or margin in regards to code, and sure enough the spacing gets thrown off, or floats fall to a new line, etc… You get the drift. Believe me, I will be first in line to tell people say away from using div’s and spans too much, and sticking to proper document structure such as headings, paragraph tags, unordered lists, definition lists, and more.
I don’t know who first coined it, but I love the term “divitis,” which refers to the overuse of divs in HTML markup. Sometime during the learning stages of Web design, people learn how to wrap elements in a div so that they can target them with CSS and apply styling. This leads to a proliferation
of the div element and to their being used far too liberally in unnecessary places.
#7 – Use better naming conventions
This is something I actually have struggled with, because often times I am under a tight deadline or a project was due yesterday, so I rush to get it done. Often times, naming conventions get sacrificed. I try and adhere to what is recommended by Smashing Magazine as best I can…it really is good advice.
This is a good time to bring up naming conventions, as we have just talked about that unordered list with an id of “bigBarNavigation.” The “Navigation” part makes sense, because it’s describing the content that the list contains, but “big” and “Bar” describe the design not the content. It might make sense right now because the menu is a big bar, but if you change the design of the website (and, say, change the website navigation to a vertical style), that id name will be confusing and irrelevant.
#8 – Leave typography to the CSS
Guilty as charged. Plain and simple, they are completely right that typography in the code should be left to the CSS, not the keyboard. If a word is going to be all caps, set the style appropriately in CSS, not by holding the caps lock key down for every keystroke.
The design of our menu calls for all-caps text. We just dig how that looks, and more power to us. We have achieved this by putting the text in all-caps, which of course works; but for better, future extensibility, we should abstract typographic choices like this one to the CSS. We can easily target this text and turn it to all-caps with {text-transform: uppercase}. This means that down the road, if that all-caps look loses its charm, we can make one little change in the CSS to change it to regular lowercase text.
#9 – Class/id the <body>
This is good advice, but not a game changer by any means. If the layout calls for it, go ahead and properly apply an ID and respective class to the body tag. As you can see on my site, I have 4 themes, and I do not touch the body tag, except in the individually themed CSS files. But I understand where they are coming from.
By “class the body,” I literally mean apply a class to the body, like <body class=”blogLayout”>. Why? I can see two things going on in this code that lead me to believe that this page has a layout that is different than other pages on the website. One, the main content div is id’d “mainContent-500.” Seems like someone had a “mainContent” div at one point and then needed to alter its size later on and, to do so, created a brand new id. I’m guessing it was to make it larger, because further in the code we see <class=”narrowSidebar”> applied to the sidebar, and we can infer that that was added to slim down the sidebar from its normal size.
This isn’t a very good long-term solution for alternate layouts. Instead, we should apply a class name to the body as suggested above. That will allow us to target both the “mainContent” and “sidebar” divs uniquely without the need for fancy new names or class additions.
#10 – Validate
Yep, 100% agree. Validate, validate, and validate…but guess what. There is a solid chance you will have at minimum warnings on your site, but any crystal clear errors should always be cleaned up. Like the article says…valid code will outlive invalid code, especially as web browsers get more advanced and adhere to standards better.
Kind of goes without saying, but you should run your code through the ol’ validator machine to pick up small mistakes. Sometimes the mistakes will have no bearing on how the page renders, but some mistakes certainly will. Validated code is certain to outlive non-validated code.
#11 – Logical Ordering
I try and follow logical ordering as best I can. In fact, as I build a site, I literally treat it like I am reading a book from top to bottom, left to right. However, I do realize there are times when a layout takes on an unconventional approach and the ordering of some sections have to be adjusted. It happens, but its still good advice to follow.
If it is at all possible, keeping the sections of your website in a logical order is best. Notice how the footer section lies above the sidebar in our code. This may be because it works best for the design of the website to keep that information just after the main content and out of the sidebar. Understandable, but if there is any way to get that footer markup down to be the last thing on the page and then use some kind of layout or positioning technique to visually put it where you need it, that is better.
#12 – Just do what you can
As long as you are taking the proper steps to get things in place, organized, and clean…you are 10 steps ahead of the next guy. Practice makes perfect, so whether the site is fresh or old, just do what you can.
Web standards evangelists would probably tell you that even if you worked on a clients site that is 3 years old and it is coded bad…you better get in there and fix it free of charge, but those of us in the real world do realize time is money, and what you knew 3 years ago isn’t what you know now.
We’ve covered a lot here, and this is a great start to writing cleaner HTML, but there is so much more. When starting from scratch, all of this seems much easier. When trying to fix existing code, it feels a lot more difficult. You can get bogged down in a CMS that is forcing bad markup on you. Or, there could be just so many pages on your website that it’s hard to think of even where to begin. That’s OK! The important thing is that you learn how to write good HTML and that you stick with it.
The next time you write HTML, be it a small chunk in a huge website, or the beginning of a fresh new project, just do what you can to make it right.
Tags: character, code, css, Design, doctype, html, indention, javascript, LinkedIn, principles, review, smashing magazine, strict, tags, transitional