When dealing with front-end stuff, we try to follow simple and sufficiently comprehensive maxims that make all our work easier — for back-end developers and for future code supporters.
Furthermore, good code allows us to sleep well and not be ashamed of the projects we release.
1. Use elements with intended applications.
This means that you should dig with a shovel but not use it to hold up the roof. We cannot just follow a “here, I fixed it” approach. For example, if you have tabular data, you may use tables rather than just cramming the data inside a bunch of divs or list-items. Assuming of course that there is not a strong need to use those divs. If you want to put form elements in a horizontal block you should use div, not paragraph. And you should not act against your better judgement by settling for an “Oh, it looks fine with paragraph anyway!” attitude.
2. Manage selectors and elements versatility.
If you have five tables and one of them is green and four are blue, you don’t have to reinvent the wheel. Similar blocks should be coded the same way and should be managed with CSS selectors. You can do this, for example, if you have two similar blocks — a news widget with 5 older news items and an interview block with 3 fresh topics — and each of them contains a few content items with title, image, text and a “read more” link.
The only difference between the two is that news items have a blue background and the interviews have green, or perhaps that the news images are floating to the left and the interview block has images floating to the right. Obviously, you don’t need to make two different blocks. A class “block” could accommodate all similarities in both elements. And by setting specific classes for each block (“block news” and “block interviews”), you will be able to accentuate the individuality of any of them (just don’t forget to use hierarchical selectors for their children, e.g., div.block.news .item img.thumb).
This kind of approach, moreover, allows you to appropriately handle various options, such as “when I click here, I want this block to expand and show additional info.” Switching the “expanded” class for the parent block (div.block) and CSS rules for div.block and div.block.expanded (yep, it’s the same for children: div.block .item and div.block.expanded .item) makes it possible to switch the block state with a single jQuery string. Furthermore, you will need only one click handler, not one for each block.
You should also attempt to make blocks as flexible as possible even if this is not necessary for your immediate task. No one knows how the layout may change tomorrow. A block with a width of 400px will demand 600px (or even full-page width) considering that 400 is too narrow, or else the right column of a two-column layout will realize the uselessness of its existence and quit, leaving the blocks in the left/center column to do all the work alone. In other words, if your stuck with a width of 400px, you’ll have to work a bit to make the page look good. But if you just widen the column, all children blocks can happily stretch out in all the new space.
3. Classes.
There once existed an agreement with devs to avoid overlaping tasks and to give them ability to rule IDs. Front-end people are not greedy, in my humble opinion, so we are fully onboard with using classes.
First, it limits namespace.
Second, it prevents the sudden appearance of a second “menu” block, which an hour ago you could not even imagine popping up on the page.
And third, it simplifies the conception of CSS selector priorities, so you just need to think about the selector length but don’t have to check if there any hidden IDs that override your recent style rule.
It is a well-established principle to use comprehensive names, and class names are no exception. I will never prefer a class name like “div.nb1” over “div.news-block.first.” Front end is not Assembler. So you don’t need to save letters. Treat all class names with respect, and remember that a class name like “nbvw23” is not going to win anyone’s respect.
4. Separate content and presentation.
As our physics lecturer used to say, “Do not put crocodiles and bus stops together.” We consider inline styles to be a sign of cowardice and a crime against the conscience (tags like “center” and other presentational tag attributes look like a deal with the Devil).
All markup should be done in a way that allows a complete change in your page’s appearance by changing only CSS/JS files without any interference in HTML. A task with 5 templates with identical content but different “faces” will be resolved with one HTML file and 5 stylesheets (or even 5 body classes for on-the-fly template switching). Inline styles (as with any visuals in an HTML file that has priority above external CSS rules) make such things impossible because you must alter the template itself to change the appearance.
5. Structural comments.
It’s a boring and thankless task to search for a closing tag in a long chain of identical closing tags and tab stops. You can rely upon a faultless eye and count down through the tab stops within the opening tag and look for the very first closing tag with the same number of stops.
But this will only work if you can ensure that all your tab stops are correct :) One mistake and you may go on a wild-goose chase: hunting for an extra closing tag in a thousand lines of code (additionally your page will look like a total mess). Adding a comment with a class name to the closing div will save you from this headache. It will ensure that you have an individual closing tag that is not hard to find. TextMate snippets will help you out with that.
6. Using reset styles.
There is a famous developers joke: “Zeroize your variables!” A pluralistic company of browsers that has majority ownership of an Internet LLC generally consists of a group of quite self-loving characters. Each of them, to varying degrees, will embody the phrase, “There are two kinds of opinion: mine and wrong!”
But we ourselves are the ones who suffer from this. To minimize our pain, we’re trying to avoid this by using reset.css. It forces us to reset all default styles, so we make a crowd first and then we paint everyone out.
7. Write less, do more ©
The slogan “Less is more” is neither new or original — but it is effective. We are trying to reach our goals with a minimum of words. As a rule there is more than one way to resolve a task, so we prefer an approach with fewer lines of code (without, of course, diminishing appearance, flexibility and functionality).
The less you write, the easier it is to comprehend. And it looks prettier :). One more quote from that professor: “The correct formula is always beautiful. If a formula has no beauty, it’s wrong for sure. But if a formula is beautiful, it does not mean that it is already correct.” So beauty and laconism must be coupled without detriment to the appearance and functionality.