Recently I’ve been taking a look at, and offering improvement tips and suggestions for bad trends that appear in code, specifically HTML and CSS, written by web developers who are new to this practice.
I thought that, rather than offering similar advice each time, I would write a little something on here that acts as a starter to point others towards who wish to improve their code standards. Not to say that there is one ‘gold standard’ of quality when it comes to doing anything in this area, nor are any of the techniques suggested below necessarily better than anyone else’s. I’m sure a lot of web developers may read this and dissect everything written, adding their own further improvements, and they are more than welcome to of course!
It seems that a lot of the ‘mistakes’ that slightly lesser experienced writers of HTML and CSS make are actually extremely similar to ones I remember making only a short while back (as let’s be honest, I haven’t been doing this forever!), and thinking were perfectly correct for a while, until someone working with me pointed something out. Most of the ‘better’ ways of writing code for certain scenarios are actually more like useful shortcuts – that save time for yourself and anyone else using the code during or after the initial production of a website – than simply better ways just because someone says they are.
If you’re more experienced at writing front-end code and reading this, most of the stuff below will seem really obvious, almost to the point where you might wonder why I’m even pointing it out. This article is not particularly for you.
Tips for writing a clean HTML code
1. Separate content from style
2. Use as few <divs> as possible
Something that stands out a lot, because people do it a lot, is the use of as many divs as seems fit to place elements on the page. Quite often web developers will write something like <div class=”border”>, just to be able to style it up as a vertical border. In reality it is easier just to add this border onto the bottom of another element (say an <article> tag for example) or even as an :after pseudo class. This avoids having any unnecessary, meaningless code on your website.
3. Think about what you’re doing
This follows on from the last one really. There is as much design involved in the development of a website as there is in, well, the design. Just like you would write a sitemap before starting to populate and publish pages and menus, it’s worth taking some time to plan exactly how your code structure is going to work. Think about the patterns you wish to use in your code, rather than just mixing a load of stuff together. And remember that less is more, always!
4. Class or ID?
The difference between these is that a class is a generic element which can be used as many times as you like, for example a class called ‘icon’, used whenever you need to show an icon as a background image in the CSS. IDs can only be used once and make sense for things like ‘content’, an advantage being that you can link to them on the page (like a ‘skip to content’ link.) However, generally, I would advise that classes are more appropriate most of the time unless you have a significant reason to use an ID.
5. You’re probably not using lists enough
If you think that writing any kind of navigation bar or menu as a long line of links, maybe each item separated by vertical bars, stop. Anything that has the vague form of a list, should be written as an unordered (<ul>) list, then styled up in the CSS. This includes horizontal and vertical menus, breadcrumb trails, lists of features and anything you can think of that makes sense in this format. CSS can be used to make a standard unordered list look like anything you like.
6. Put things in the right order
If you’re building say a blog – which visually has a sidebar on the left and the content on the right – you should still put the content first and the sidebar last in the HTML and achieve the desired visual layout by floating the sidebar to the left and the content to the right. Bearing this sort of thing in mind will mean that the site is more accessible, say for users with screen-readers or even those who can’t see the site with CSS for some reason (perhaps on mobile phones.)
7. Just write cutting edge code
If you’re not already using the new HTML 5 structural elements, like <header>, <section>, <article>, <aside> and <footer> in your code, please start! It’s a pretty big (and stupid) misconception that web developers should avoid using newly emerged features like these in their work, as they’re not as established as more traditional elements such as <div> and <span>. There’s now more than enough compatibility in modern browsers to be able to use these effectively, and very straightforward fixes for older browsers that simply inject these features into them.
8. Only use stuff that you REALLY need
There’s no point in adding IDs and classes to things unless they’re really necessary, which goes back to the less is more thing again. For example; if you can, try to style all the H2 elements on the site using 1 set of CSS rules, instead of making lots of classes for those H2s, seems obvious – but you’d be surprised. This applies to everything pretty much.
If the file you’re working on is quite long, it’s a good idea to comment things where necessary. Some web developers go crazy and comment the start and finish of everything on the page. Personally I only usually use comments if there’s a lot of closing </div>s where they have been nested inside each other, this just helps when someone else wants to take out, or add bits at a later date.
10. Read a book
Or at least skim through one. “Classic” books like Designing with Web Standards and Bulletproof Web Design are a really good starting point for making sense of some of these decisions, and drum home the point that any code that isn’t practically written in this sense is obsolete and that you’re only wasting your time and “harming” the internet.
Follow these tips, and maybe create your own processes for a more optimised web development workflow and you’ll hopefully notice improvements on each project you do, and possibly on a day to day basis!