By Meitar Moscovitz

5 Top Tips to Beautify Your HTML and Enrich Your Content

By Meitar Moscovitz

It may be surprising at first, but some of the biggest differentiators of good code and great code are actually all the little things. The absence of such “little things” can turn what would otherwise be beautiful markup into something that looks like it came from a Microsoft Word export. Here are 5 of the more-important-than-you-think things to help your markup go from decent to gorgeous.

Use the shortest URI you can

Whenever you make a link, add an image, or write anything that references a different file on the Web, should you use a relative URI, an absolute one, fully-qualified URIs, or…? Variations of URIs are so common that people rightfully ask “which one should we use?”

A simple rule of thumb is to use the shortest value you can. Shorter URIs are likely to be more portable and they have optimization benefits, too. There’s little reason to encode a link with a URI such as when /my-page/ will do. If your domain name changes in the future and you’ve used a fully-qualified URI, you’ll end up with a broken link. If you’re linking to a remote domain, then unless your own content will be published over multiple protocols (like https: in addition to http:), you can even safely omit the scheme portion of a URI.

In this sense, a URI can be thought of as a mini-language of its own. Using the shortest one you can benefits you by providing a higher likelihood of reusable code later on, a phenomenon explained by the Rule of Least Power.

Use markup patterns consistently

Patterns are an extremely powerful technique that improves code reuse, legibility, and functionality. At their core, microformats are simply well-established and widely-understood markup patterns. Their functionality is actually derived from the ability to send batches of these patterns to processing tools.

Even if you don’t use microformats in your own markup, you’ll benefit by using your own patterns consistently. For a dramatic example, just imagine the nuisance of having to deal with a site’s logo marked up differently on each page. On the home page you might have <h1 id="logo">…</h1> and on an article page maybe you have <img id="sitelogo" … />. You’ll likely end up grouping CSS rules to cover both cases and adding extra code into scripts in an effort to remain unobtrusive. That’s nightmarish!

So a pattern can begin as humbly as using the same markup for a site’s logo, but it can become more valuable to you the more conventions you stick to. If you’re going to use <div id="Header">, then you shouldn’t use <div id="ftr">. At SitePoint, for example, blocks of code are always marked up the same way (using <pre><code>…</code></pre>), making it possible to layer style and behavior on top of those elements in a uniform way, site-wide.

Minimize uses of class and id attributes

One benefit of patterns that can be easily overlooked is that—when they’re well designed—they radically improve the structure of your markup. This, in turn, reduces the need for you to use IDs or classes in elements in order to style them, which keeps your markup leaner. It also keeps your style sheets easier to understand, since your CSS selectors will use the structural context of the markup to provide the same context in CSS files.

In fact, avoiding IDs and classes all together can be a very instructive exercise. If your markup is well structured, then you can achieve a surprising amount of the styling you need to using the humble descendant combinator. As support for CSS selectors that use structural context improves (like :last-child, and :only-child), the need for arbitrary styling hooks is further reduced.

This has an inherent tension with the previous tip: if you rely too heavily on the structural context of your markup, then you may find yourself adding unnecessary elements to accommodate your style sheet. Walking the line between these two extremes is precisely the challenge of creating well-structured, semantic markup.

Add title attributes and other metadata to enrich content

Despite its limitations, HTML provides a number of mechanisms with which you can add metadata or additional content inside your markup. Few web pages take full advantage of them, but on those that do, the user is treated to rich, layered interaction using nothing fancier than core HTML elements and attributes. A prime example of this is the title attribute.

Links (that is, anchors, or a elements) aren’t the only things that can be given a title attribute. It can be applied to elements like blockquote, ul, pre, and myriad others. Just as they do for links, title attributes often show up as tooltips when the user hovers their cursor over the element, and in all cases they are intended to provide some kind of supplemental information to the element.

You can make use of this metadata in a variety of ways, including semantics of course, but also for interaction possibilities. For example, if you’re quoting a speech, consider using markup like this:

<blockquote title="Text of Barack Obama's Inaugural Address" cite="">
    <p>My fellow citizens:</p>
    <p>I stand here today humbled by the task before us, grateful for the trust you have bestowed, mindful of the sacrifices borne by our ancestors. I thank President Bush for his service to our nation, as well as the generosity and cooperation he has shown throughout this transition.</p>

When the user’s cursor hovers over this quotation on your page, they’ll be presented with a tooltip that reads, “Text of Barack Obama’s Inaugural Address,” adding some depth to their experience. It’s as though you’re inviting them to actively explore and uncover more about your content. Further, with a CSS rule such as the following, you can extract the metadata in the title attribute and display it visually.

blockquote[title]::before { content: attr(title); display: block; text-align: center; } 

Another attribute you can use is the rel attribute. For instance, using rel="external" is a simple pattern with which you can mark links to remote sites. If you’ve written a piece that’s cut up into multiple discrete chunks, such as a series of articles, you can also use the rel attribute inside a link element within your page’s head to provide hints for correct sequential navigation:

    <title>My Fantastic Article - Page 2</title>
    <link rel="prev" href="/page-1/">
    <link rel="next" href="/page-3/">
    <link rel="index" href="/article-index/">

Using these additional elements will trigger interfaces such as Opera’s Navigation Bar.

Use comments and whitespace to help readability and ease maintenance

Regardless of a project’s size, hard to read code is one of the most demoralizing things to see. It’s arguably more important that your fellow humans can read your code than can your machines. Therefore, it’s really helpful to pay attention not just to what you code, but how you code, too.

Comments in HTML aren’t often used but they can be to great effect. One simple example is using them to denote the closing tags of elements. For instance, many typical blog templates have lots of nested div elements, like this overly simplified example:

<div id="Wrapper">
    <div id="MainContent">
        <div id="post-1" class="hentry">
            <p>Main article content here.</p>
</div><!-- Which element does this tag close, again? -->

Of course, in reality closing tags are rarely in close proximity to their opening tags, so it’s often difficult to immediately know which closing tags close which elements. To find out you might spend 30 seconds scrolling up in the file. That may not sound like much, but if you do this 100 times a day, then you’ll spend nearly an hour (50 minutes) doing nothing but scrolling up in text files.

This issue gets even worse if your templates are split across multiple files where a tag is opened in one file but closed in another. Now you’re spending even more time searching for opening tags. Such a case is a perfect situation to use HTML comments:

<div id="Wrapper">
    <div id="MainContent">
        <div id="post-1" class="hentry">
            <p>Main article content here.</p>
        </div><!-- .hentry -->
    </div><!-- #MainContent -->
</div><!-- #Wrapper -->

Consistent whitespace is also important. This isn’t a matter of tabs versus spaces, it’s another example of picking (or inventing) some convention that works for you and your team and then sticking to it religiously throughout the project’s life-cycle. Finally, remember that any whitespace you use in a source template can be compressed in a production version if you use intelligent/automated build systems.

Ultimately, the difference between good code and great code is that all the “little things” are so consistently well-executed that you wouldn’t even notice them. If any of these tips aren’t already habits for you when you write markup, they should be!

  • I’d suggest that you should consider surrounding content when contemplating using the title attribute. For instance with links, I see a lot of titles that say nothing more than what the link text already does, thus making it redundant. (The visual editor of WordPress is another offender giving images the same alt and title attributes).

    In your example of a quote from a Barack Obama speech, if the quote is preceded by a heading or a sentence that introduces the quote, I’d think the title attribute would be redundant, and keep in mind that while most sighted people might not be affected by such duplication if they don’t hover over the element, screenreader users might hear the same content twice.

  • There’s little reason to encode a link with a URI such as when /my-page/ will do.

    I can think of one and it’s served me in the past: if someone copies content wholesale from your site without editing it, and that content includes full links to other pages on your site, it’ll often raise a flag in the form of trackbacks to the offending pages.

  • Those are both good points, Tyssen. I think that’s why the title attribute is defined by the HTML specification as specifically providing supplemental information. It’s still a bit tricky to sometimes correctly determine what “supplemental” means in a particular context, but that’s why we humans still have jobs writing HTML, right? ;)

    And on the note of humans still writing HTML, your second point about someone scraping content wholesale from a site without editing it is also good. But if you expect people to do something like that, then I’d consider that situation to be “your own content will be published over multiple protocols.” In this case, that protocol just happens to be content-thievery://. :)

  • watershed

    Good stuff.

    The only tip that’s new to me is the first one. Your point is well made, but I’ve heard it said on several occasions that there are SEO benefits to using absolute URIs. To do so would I guess be a case of the cart leading the horse in terms of beautiful markup, but would you care to comment?

  • Connor

    Minimising the use of “class” and “id” attributes will make unobtrusive DOM manipulation slower and more processor intensive on the browser front. I’d suggest that adding these pragmatically will have a chiefly positive effect on markup in these circumstances.
    Additionally, the markup length saved by removing these are quickly offset by the additional structural markup that would be required to uniquely identify elements in a classless, id-less DOM.
    It seems counterproductive to offer this approach as a way to reduce markup, only to suggest the use of extra comments and title attributes in subsequent points. Markup, by definition, should be more machine-legible than human-legible, hence id and class attributes should be of hugely greater priority than comments when trying to shave bytes off the markup length.

  • watershed, I suppose I should preface what I’m about to say with IANASEOP (I am not an SEO professional), but in my experience, as long as the resulting fully-qualified URI of the resource remains the same (i.e., each URI references one and only one thing), then there is no difference between relative and absolute URIs. Most SEO professionals tend to prefer absolute URIs under the assumption that search engines prefer them, but I’ve never seen hard-and-fast proof that this is the case.

    Another case in which they sometimes prefer absolute URIs is when the URI itself is keyword-rich. In these cases, linking from one page of an article series to another with a relative URI might omit this perceived-as-valuable portion of the URI. Once again, I’ve never seen evidence that this is a major weighting factor in SEO results, and I’ve personally never encountered any major problems using one method over the other (and I have tried both over the years).

    Finally, I’ll say that there are many other things that SEO efforts should be focused on that will garner far greater net gains than using only fully-qualified or absolute URIs. I can make the argument that writing “beautiful” markup is like using fresh food as ingredients for your dinner. That is to say, you could spend $50,000 on an SEO campaign which would do just as much for you as spending $5,000 on getting your markup “right” from the start.

    I hope this is what you were asking, yes? :) In any event, it was a good question! Thanks for the comment.

  • watershed

    Like you, IANASEOP.

    …there are many other things that SEO efforts should be focused on that will garner far greater net gains than using only fully-qualified or absolute URIs.

    Nicely put — sounds good to me.

    There are perhaps parallels with the SEO case made for semantic markup. There are good enough reasons to markup semantically without falling into the trap of overstating the SEO benefits.

    Thanks for your answer.

  • Zapruder

    Not bad suggestions, but if I’m supposed to minimize class and title declarations then what am I supposed to use to comment the tag close with?

  • Connor, you’re 100% correct. It’s much more common to see less experienced front-end developers overuse IDs and classes rather than not use them enough, however, so I believe that urging them to minimize their use of them will actually achieve a greater overall balance. I tried to say that by discussing the tension between that tip and the tip before it. Perhaps that paragraph could have been further underscored.

    id and class attributes should be of hugely greater priority than comments when trying to shave bytes off the markup length.

    And indeed they are. My use of the word “leaner” in the section on reducing ID and class names was actually an indication not to byte size but to grouping, and upon a second reading after reading your comment I do see how that sentence could cause a misinterpretation. I could have picked a better word there.

    Zapruder, you don’t need to comment every closing tag, just the ones that are non-obvious in your document. It just so happens that these are also typically the ones you want to include either ID or class names or some other metadata about, so I find that in practice this actually works out rather conveniently. :)

  • Anonymous

    I have always been told the opposite for number 1 as well, but like a commentor above states, there has been no proof of either method being liked more by search engines.

    Thanks for the share.

Get the latest in Front-end, once a week, for free.