Introduction

HTML authoring is notoriously poor. Why is this ? Because people can’t be bothered to set aside a relatively small amount of time to spend learning what HTML was designed for and how it is supposed to be used.

Why should I care ?

  • The vast majority of web users aren’t running the latest version of Microsoft IE with every plugin they can lay their hands on. Certainly there are many users who will have something similar to this, but if you’re smart, you’ll cater to all web users. That way, more people read your HTML and you get more customers, more downloads, more feedback, or just more wear on your webserver.
  • There are people in the world with vision problems. Yes, believe it or not, not everyone has 20/20 vision or likes reading green text on a red background. Did you know that it’s now possible to prosecute for bad HTML design ? Ok, if you’re writing your pathetic little ‘This is my corner of the web I have a dog he is called Gerald’ page then you’re probably not at risk, but if you’re a commercial entity, government department or NGO, better be careful.
  • Proper HTML authoring requires intelligence. If you can write decent HTML, your friends will look up to you and you’ll get invited to join Mensa. Probably. Not that you’d want to, because Mensa is populated by wankers.

Is this going to be hard work ?

Yes.

Start by getting the references you need. No, not HTML for stupidbastards, the actual specification of the HTML language. Here’s what you’ll need:

  • The XHTML 1.0 specification
  • The CSS 1.0 specification

What, no links ? Right. Go to the World Wide Web Consortium’s site and look for the documents on your own. On the way, you’ll notice that the W3C exists. You will need to use them again someday, so bookmark their home page.

Guidelines

  • Check your HTML for validity.
  • Do read the specification documents. Go on, read them. All the way though, from beginning to end.
  • Don’t write HTML which includes presentational markup, where you can help it.
  • Do use CSS to enhance presentation. If the user has visual problems, they can tell their browser to use a special stylesheet by default. If the user isn’t using a CSS-capable browser, your pages will still be readable.
  • Don’t put large (file size) images directly into your document. Link to them and tell the user how big they are. Lots of people are still using modems, and the percentage of people doing so will be high for years.
  • Do use images. Attractive presentation can help make your document more readable and stop your users getting bored too quickly. Long pages full of plain text get tedious after a while. Like this site.
  • Don’t tell people to ‘click’. Some people don’t click, because they don’t or can’t use a mouse.
  • Do provide links wherever appropriate. More is usually better. Navigation is what the ‘hypertext’ part of HTML suggests.
  • Don’t require browser plugins. Flash, Java, etc. are all useful but your site should work without them. Don’t tell the user they need to install a different web browser. That’s very annoying.
  • As an exception to the above, do use stuff that requires plugins if they’re absolutely necessary, e.g. for a Flash game. You don’t need Flash for a web application or a video, though. HTML will suffice for an application, videos should be downloadable so the user can watch them with their player, rather than embedded in a web page.
  • Don’t use frames. They’re not needed anymore and they break navigation.
  • Try to use a logical site structure so people can figure out how to get around without having to have a permanently-visible navigation system.
  • Use appropriate image file formats. Images with large expanses of single colours should be PNG (or GIF). Anything else should be JPEG. Use an image editor to save different types of images in different ways. Use varying levels of JPEG compression. Experiment until you understand how this works.
  • Don’t use backgrounds that make your text difficult to read. Just because you think it looks cool doesn’t mean that anyone else will.
  • Don’t use white backgrounds. Actually, I’ve changed my mind on this one. Go ahead. It used to be annoying, because pages looked really bright, but since half the pages on the web have white backgrounds, users just have to turn their monitor brightness down a little.
  • Do set up a colour scheme using CSS. This also allows you to make site (or section-of-site) -wide changes easily.
  • Don’t use image maps unless they really are for map-style navigation. If you do use them, provide an alternative method of navigation which has the same effect.
  • Do use tables of contents.
  • Don’t use proprietary tags, such as center. Don’t use center anyway, because it’s presentational markup.
  • Do use the proper tags for the structure of your document. For example, when you write an address, use the address tag.
  • Don’t use ECMAScript (JavaScript) unless your site works fine without it (‘degrades gracefully’).
  • Do use cool technologies - behind your site, where the user doesn’t have to care about whether their browser will work correctly in conjunction with them, or if you want them client-side, make sure they degrade gracefully.
  • Don’t use tables for anything but tabular data, if possible. Use CSS if you can. I know that CSS can’t give you a proper table-like layout, though. There’s always something that doesn’t quite work right, so yes, you may have to resort to tables in places.
  • Do use table headings and provide a description of each table.
  • Don’t listen to the ‘bobby’ people. They claim they know about site design, but they’re talking rubbish.
  • Do listen to me, because I’m always right ;)

Explanation of each rule

I lied, there are no explanations here. If you can’t figure out for yourself why these rules should be followed then I hope you never write HTML.

Now go and read HTML Hell.

Write comment
No comments