Coding with Jesse

The Standard Web

January 31st, 2006

I'd like to talk about web standards in the future, but I realised I need to first define what it is I'm talking about. So, this is what I mean by using 'web standards':

  1. Make sure your HTML and CSS validate.

    The point is simple: if you're using a standard format, use it correctly. However, just because your page is valid doesn't mean it's perfect. For this, the W3C's HTML Validator and CSS Validator are your best friends.

  2. Separate the design from the content.

    Use CSS to describe how things should look (fonts, colours, widths and heights, borders, etc.) Also, take as many images as you can out of the HTML. Don't use images to display text. Ideally, put all the CSS in an external file, but it's up to you how you organise your code. Just be aware of the tradeoffs.

  3. Separate behaviour from the content.

    Don't use event attributes (onLoad, onMouseOver, etc.) Ideally, put the JavaScript in an external file. Like with CSS, this isn't so important and is up to you. However, it is important that your web site works without JavaScript, if possible. Again, just do your best.

  4. Use HTML the way it was intended.

    By this I'm talking about using HTML semantically. Don't use tables unless you're showing spreadsheet data. Use h1-h6 tags for the headers on your page. Use blockquote only when you're quoting, not for the indentation. Just try to use the full range of HTML tags when appropriate. Sometimes you simply need to use divs and spans, but avoid catching Divitis.

  5. Make your site accessible.

    Accessibility is a very important standard, in some places it's actually the law. If you've already taken care of the last four points, chances are your site is already very accessible. Grab an accessibility checklist, and take look at your web site through the eyes and ears of all potential visitors. What does the site sound like with a screen reader? What happens when you increase the font size? Are you using any terminology without giving definitions? This is a big topic, but it often gets forgotten.

This is what I mean by 'web standards'. These are all just guidelines, and there are obvious exceptions to every rule. Next, I'll go into the benefits of following these rules.

Update: I've chosen to go with the term 'Best Practices' to describe what I've discussed here, of which 'web standards' are only a subset. Read my discussion here.


January 27th, 2006

Continuing my discussion of microformats, let's take a look at the hCard. The hCard microformat is a way of identifying contact information in HTML. People can use tools to look into the HTML and extract this information as a vCard. vCard is a standard for an electronic business card. There are a number of values you'd expect (name, phone number, organisation, etc.). hCard takes these labels and uses them as class names around data in HTML.

Here are the more common values you can use in hCard (for the complete list, see the wiki:

  • fn (family name)
  • nickname
  • url
  • email
  • tel (telephone)
  • adr (address)
  • org (organization)
  • etc...

Every hCard starts inside a block that has class="vcard". So, a very simple hCard might look like this:

<div class="vcard">
   <span class="fn">Jesse Skinner</span>
   <a class="url" href=""></a>

Some of these types have subproperties. For example, the 'tel' value contains 'type' and 'value'. This way you can specify separate home and business phone numbers. The 'adr' type has a lot of subproperties (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value). An address might look something like this:

<div class="vcard">
   <div class="fn">Jesse Skinner</div>
   <div class="adr">
      <span class="locality">Berlin</span>,
      <span class="country-name">Germany</span>

The class names don't have to mean anything within your page. However, you can always take advantage of them to style your contact information. You could also style them in your browser's User Style Sheet, so that you can find them while you surf the web.

The hCard standard is very flexible. It doesn't matter which tags you put the classes on. It certainly doesn't have to be in nested div tags. You could just mark up your contact information any way you like, and then wrap the data in span tags to tie the data together. For example, it can be within regular text in a paragraph:

<p class="vcard">
  My name is <span class="fn">Jesse Skinner</span>.
  I live in <span class="adr"><span class="locality">Berlin</span>,
  <span class="country-name">Germany</span></span>.
  I work for <span class="org">Strato AG</span>.
  I have a web development blog at
  <a class="url" href=""></a>.

There's lots of tools already, and more on the way. If you don't want to install a browser plugin, or if you want to give all visitors to your site a way to download your hCard as a vCard, X2V is a service that does just this. Just link to:[URL with an hCard]

For example, click here to download a vCard of this simple hCard:

My name is Jesse Skinner. I live in Berlin, Germany. I work for Strato AG. I have a web development blog at

hCard, like other microformats, is wonderfully simple yet incredibly powerful. You can begin using it right away with very little work, without waiting for the standard to be widely used. As more people start looking for hCards (and your contact information), your web site will already make things easier for them.

Predictable design

January 24th, 2006

Jonathan Snook just posted a nice example of why you should stick with what's predictable. When designing, there's a lot of temptation to go against the grain, to do something a little different than everybody else does it. Except, it makes your interface less predictable. And predictability is key for user friendliness. Whether it's underlines on hyperlinks, or simple navigation titles, you'll usually end up winning more points for usability than you ever will for creativity.

Element dimensions on QuirksBlog

January 23rd, 2006

Peter-Paul Koch just announced that he's put up a new test page comparing the JavaScript dimension and positioning variables (offsetWidth, scrollHeight, etc.) across multiple browsers.

As a quick side note, QuirksMode is my favourite JavaScript and CSS reference, when it comes to figuring out browser support and differences. His examples are so clean and to the point. Thanks, Peter-Paul!


January 18th, 2006

Microformats are a way of defining new data formats using existing standards and languages (ie. HTML and XML). It's a very exciting area of web development. The concept is relatively new, so there are really only a few formats out there (currently nine formats plus ten draft formats). There's also a lot of room for new formats to be created and used.

The idea is to use simple, easy, and predictable ways of defining new standards, rather than defining some complex impossible new standard. This way, the standard is something people can start using and benefitting from very easily and quickly. There's no need to go and change existing structures. Rather, microformats tend to be subtle adjustments to the way people tend to do things anyway.

The ultimate source of everything microformat-related is currently the the Microformats Wiki, and if it's your first time looking at microformats, I suggest you read the microformats entry. Since it's a Wiki, anybody can add new microformats, or contribute to existing ones.

I can't mention microformats without mentioning Tantek Çelik. He can be credited with the concept, and he still plays a very active role in defining and promoting new standards. He's the editor on the Wiki, and from what I can tell, he's co-created most if not all of the current microformats.

You may be familiar with the rel-nofollow standard. Google came up with the idea of adding rel="nofollow" to links in blog comments. This tells the Googlebot to ignore these links when calculating PageRank. This is intented to prevent comment spam, because spammers won't gain a higher PageRank by sticking their URL in comments.

The idea is perfectly simple. It uses an attribute built into HTML, the rel attribute, in a way that is consistent with its intended purpose. The HTML 4.01 spec says:

This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types.

They give a list of link types, but afterwards they state:

Authors may wish to define additional link types not described in this specification.

As a result, the rel-attribute is a common method of implementing link-related microformats. Another example of a rel-attribute microformat is the Technorati rel-tag format. Technorati scans blog posts looking for links with rel="tag". The word or phrase within that link is used as a tag to describe the post. This blog uses such tags, and you can see them at the end of this post.

In the future, I'd like to discuss some more of these microformats and show more examples. Until then, I suggest you check out the Microformats Wiki and see if there's any microformats you can start using today.

Multiple classes in Internet Explorer

January 16th, 2006

I recently discovered the power of using multiple classes. That is, using more than one class on a single element. The class attribute simply accepts multiple classes separated by a space. For example, you can do something like this:

.box { border: 1px solid black; }
.small { width: 400px; }
.large { width: 800px; }

<div class="small box">
<div class="large box">

This is a great way to organize your CSS. For example, you can have a set of classes to define font styles and another set of classes to define box sizes. Then you can use them together in different combinations.

The class names "small" and "large" aren't totally clear, since they refer specifically to small and large box sizes. It'd be great if I could write "large title" and have it affect the font size instead of the width. So, I tried to change the definition by combining multiple classes in a single selector:

.box { border: 1px solid black; }
.box.small { width: 400px; }
.box.large { width: 800px; }

.title { color: blue; font-family: Arial; }
.title.small { font-size: 10px; }
.title.large { font-size: 20px; }

When I tried this in Firefox, everything worked great. Unfortunately, Internet Explorer doesn't support this. In fact, Internet Explorer will just look at the last class in the list. So, it will interpret the last example as if we had written this:

.box { border: 1px solid black; }
.small { width: 400px; }
.large { width: 800px; }

.title { color: blue; font-family: Arial; }
.small { font-size: 10px; }
.large { font-size: 20px; }

Small boxes will have small fonts, large boxes will have large fonts, small titles will be 400px wide, large titles will be 800px wide. Very unfortunate.

Once again, Internet Explorer ruins all the fun. Well, there's an up side to this. When we use "small" to affect the width in one place, and the font size in another place, we make it harder to understand and maintain the CSS. And isn't that supposed to be the point of using CSS?

Besides, not all is lost. We just have to come up with better names. We can still do this:

.border { border: 1px solid black; }
.small-box { width: 400px; }
.large-box { width: 800px; }

.title { color: blue; font-family: Arial; }
.small-text { font-size: 10px; }
.large-text { font-size: 20px; }

It sure isn't as pretty to write something like class="border small-box". But at least then we can use our "small-box" class in places that don't have borders, or use the "border" class to give a border to something without a fixed width.

In conclusion, avoid the .class1.class2 syntax altogether. It's not supported by Internet Explorer, and it makes code harder to read and manage. However, using multiple classes is completely supported and will make your CSS cleaner and more reusable.

5 things every web site can learn from blogs

January 14th, 2006

Blogs are here to stay. However, I don't believe every web site needs to have a blog to benefit from the way blogs have changed the Internet. Here are five things blogs have taught us that we can use to improve all web sites:

  1. Update regularly

    Many web pages have some kind of "News" or "What's New" section. Most of them never seem to change. Blogs essentially took this section and made it the centre of the entire web site. Things are always changing and events are happening. The best part of the web is how up-to-date it can be. If something important is happening, and there is nothing about it on your web site, your visitors won't trust your web site as a source of information.

  2. Let visitors subscribe

    Blogs didn't invent subscriptions, but they've certainly proven they work. Long outdated are the phrases "Bookmark this site", "Under Construction" and "Check back soon". Every web site is changing and being updated. Visitors don't have the time to check back. You need to offer a way for them to subscribe. RSS feeds are certainly the new standard for subscriptions, though E-mail updates are still relevant for those who don't use RSS.

  3. Speak with a human voice

    Blogs aren't written in buzzword-filled meaningless marketing speak. They're written in the same language people use to talk to each other. The kind of language that people actually want to read. By changing the language of web sites, you not only make your web site more friendly, you make it easier to understand. If you really have something worth saying, be direct and clear about it. If not, why would you bother writing anything at all?

  4. Get personal

    Blogs don't hide the people behind the web site. In fact, that may be their strongest attraction. The Internet is changing the voice of companies whether they embrace it or not. For example, Robert Scoble's blog has become the voice of Microsoft. His blog is honest, admitting where Microsoft fails, where it needs to improve, and what its true motives are. It's time for the people behind web sites to come out and tell their stories.

  5. Let visitors discuss

    People need a chance to respond and add to things they read on the Internet. Most blogs give visitors a chance to discuss in comments and trackbacks. Where comments and trackbacks aren't appropriate, wikis and forums fill in the void. If your web site doesn't give a chance for visitors to contribute and share feedback (whether it's positive or negative), they will do this on their own blogs. Offering a place for the visitors of your site to come together and share feedback builds community, trust, and lets your site evolve in response to what people want.