Semantic HTML Design and Development

I have developed for the web since the mid-90’s from the first version of HTML that became HTML 1.0. There was only a rumor of CSS then, tables were the only way to get a layout to play nicely and the <font> tag was king. A lot of HTML/CSS I’ve done can be viewed in the legacy site I keep around as a reminder how far I’ve come. I code HTML and CSS with an obsessive drive for clean and efficient code.

  • Appropriate document type. We declare a document type not for the user or visual rendering, but to provide information to the device reading it – browser, screen reader, search engine, or other device – about what to expect from the document. Today that is almost exclusively HTML5, but before the rise of HTML5 I always used an appropriate document type. If I was publishing HTML documents, I would use HTML 4.01 strict or transitional (before the specification was finalized,) if I was extending the HTML, I would use XHTML.
  • Semantic HTML. Since we are building documents to be read by devices (as well as viewed by users,) one of the primary considerations when I code are the semantics. Here is a simple example: 
        
      <strong><em>I am bold italic text!</em></strong>
      <span class="bold italic">I am bold italic text too!</span>
      <b><i>So am I!</i></b>
    All of these render to a user exactly the same but given the choice I will always code using the first. The reason is that <strong> tells the reading device this is meant to be STRONGER than the surrounding text, and <em> tells the device the context of EMPHASIS. The <span> tag gives the text no semantic meaning, it is a generic element that is intended to be used when no semantic element is appropriate. This is also why I never use <b> for bold or <i> for italic. These are presentation tokens and don’t tell a device you are providing the context of STRONG EMPHASIS. Coding semantic HTML allows me to provide richer documents for devices reading it with no detrimental effect on end users.
    This is a largely ignored concept in today’s web, a future article will discuss the infectious disease seen across the web, divitis in which semantic elements are ignored for usage of heavily nested generic <div>’s. There is a time to use generic elements, and there are times when you shouldn’t.
  • Code to the natural document flow. What I mean by this, and what it means to my clients, is discussed at length in the blog post Code to the Natural Document Flow. Many developers will disagree, I do not use a global CSS reset (gasp!) Here is why.
  • Validate all output. Whether it’s a static web page or output from a PHP/Perl script, I always put special attention into validating all output. I discuss this at length in the blog post Why Validation Matters.
  • Relative url’s for internal resources. I always code with domain relative URL’s when creating links. What that does for a page is makes it portable. For example, given the page about-us.html a common approach is often implemented in one of two ways: 
      
     <a href="about.html">
     <-- or . . . -->
     <a href="http://www.example.com/about-us.html">
    The problem with that is if you want to move the page to a different site or into a different directory, you have to go in and find all instances and modify it. By making it domain-relative (note the slash,) 
      
     <a href="/about.html">
    It can be moved without having to modify the code. This gets even worse if you’re coding in something like WordPress where the content is stored in a database. When you develop offline in localhost (web server on your local computer,) you have to find all instances of your links in the database and swap them out for the live site, and keep two database copies active, one for localhost and one for the live site. I discuss this in Add Basic Functionality, where I swap out all the WordPress full URL’s for domain-relative URL’s.
  • SEO (Search Engine Optimization.) I built web pages/output with SEO in mind from the ground up. Too often a publisher hands over a site to an SEO company only to find it has to be rebuilt and optimized to really do well in search engines. By building in SEO-friendly content as I develop, most of the work is already done. I expand on this in the SEO Services page.