Everyone has their own philosophy of how markup should be written, and I am no exception. Over time, I have strived to make sure that what I write can be described as follows:

• Browser Agnostic
• Semantically Correct
• Forward Thinking
• Well Documented
• Self Contained

Clearly, these are ideal qualities that always seem to be challenged on every project, mostly around the existence of a requirement or technical decision that supercedes all. However, it should never be said that there is no other way to make something work than writing cludgy, quick-and-dirty markup.

Browser Agnostic
Markup that is specific to a particular browser (ahem, Internet Explorer) should be avoided at all costs. Now, this is difficult, considering that the browser profiles to which you are coding, combined with the complexity of an approved design, may tempt you to use a certain browser-specific CSS declaration or HTML element. Resist this temptation and find another way. What I’ve tried, with some success, is informing your client that pixel-perfection is unachievable and potentially costly in the long run, because the time spent making a design work in multiple browsers can be a timely (not to mention, excruciating) task. Pixel-precision — making sure that the elements are arranged so they appear where they should be without having to measure to the pixel — is a more achievable and maintainable goal, because, if done correctly, then there would theoretically be fewer issues with regard to compatibility with future versions of or completely new browsers.

Semantically Correct
Properly-structured markup is important, not only for human site visitors, but also search engine robots, who often assign importance to words wrapped in structural markup (e.g., h1, h2 elements). Think of it as though you were writing a Word document: a properly-structured document contains sections and subsections, with appropriate headings and subheadings, and viewing an outline of the document would reveal hierarchical importance.

Forward Thinking
Adhering to a particular W3C specification — XHTML 1.0 Transitional, for example — ensures that future versions of browsers will render the markup appropriately. Browsers will try to interpret unspecific markup to the best of their abilities, using a default DTD that most likely isn’t what you intended to use. Choosing your DTD now may eliminate future maintenance to rework markup that doesn’t meet a W3C specification.

Well Documented
Any markup that is written should also include some documentation that explains what a particular page or section does. The level of documentation depends on the audience who’ll be consuming this markup, but, for me, this usually includes back-end developers who are tasked with inserting logic into markup rendered in interpreted languages, such as PHP and JSP. The audience may also include other site owners who may need to maintain the site long after you’re gone. The format for your documentation may vary as well. If comments inline with code aren’t enough, then you may also want to write a UI pattern library.

Self Contained
Snippets of markup that make up an entire page or site should be written such that they can stand independently. For example, if you have markup for a table, then you want to ensure that you’ve included every open and close tag for each element. Introducing dependencies to other elements of a page reduces flexibility and scalability. Again, you may want to consider a UI pattern library for components that are often repeated.