CodeBitch : click here to go to MacEdition Homepage

Eleven reasons it’s your fault

13 November 2000

I’ve been complaining about the lack of standards support in browsers for a while now. However, browsers will only render the code they’re given, and as responsible Web designers we have to realise that part of the problem is our fault.

I’m not the kind of markup purist that insists you use only those tags that work in Netscape 1.0 under Windows 3.1. Occasionally I’ll resort to coding hacks to get a particular effect when nothing else will work, like putting a block-level P tag inside a SPAN tag (but only on our company intranet, where nobody else will see it). But as much as possible, I try to stick to valid code.

Writing valid code is not hard. You do have to pay more attention to detail. But in my view, it’s easier in the long run to learn how to do it right than to screw it up. And if you can’t do it right by yourself, you can always throw your pages through HTML Tidy or one of the validators. Even the code checkers in page-editing software like Dreamweaver would do. And if you do the productive thing and build yourself some templates, you don’t even have to do it on every page – just the templates.

So what are the mistakes most often made? The list below is not at all scientific, but has been built up from my experiences of looking at other people’s sites, including those of luminaries such as, ZDNet and Apple.

Letterman plus one


    HTML pages require a DOCTYPE, usually the Transitional Document Type Definition (DTD). But almost no Web page editors put these things in for you, perhaps on the logic that if you need a graphical editor, you won’t know what a DOCTYPE declaration is to put the right one in. They should at least allow you to assign the DOCTYPE without manually editing HTML, but they don’t. Most validators will assume HTML 4.0 Transitional by default. However, this can get you into strife if you want to do something different, like use frames. Do yourselves a favour and add this line to the top of all your templates and default pages.

  2. No quote marks in the attributes that need them.

    The rule is simple, folks: if it’s not straight letters and numbers, put quote marks around it. This includes colour directives like #003333, and especially URLs. In fact, it’d be best to quote all attributes, so there’s no confusion.

  3. No ALT attribute in images (IMG tags).

    The W3C mandated this attribute for a reason. Accessibility to users of text-based browsers, including the visually impaired, is an important issue. It can also be a costly one to ignore, as IBM, the designers of the Sydney Olympics site, found out. I find it particularly amusing that the folks who use FONT tags “because they’re supported by older browsers” are also the ones that make this mistake. If you are so worried about Lynx users, give them something that tells them what the picture they’re missing contained.

  4. Bad nesting of tags

    Believe it or not, you see this sort of kiddie mistake all the time. No wonder browsers crash! HTML tags should nest properly. For example, <div><p><a ...><b> should be followed by </b></a></p></div>. Every Web editor package will flag this. So why do I see this error so often on the Web?


    These attributes are used because Netscape doesn’t draw a background picture or full-page table all the way to the edge otherwise. However, they’re not in the HTML 4.0 standard. What you have to ask yourself is whether a couple of pixels is such a big deal, and how you trade them off against completely valid code. If the pixels are more important than the validation, so be it. Having said that, I’m yet to see a page with this as the only code error, so I don’t think that designers are calculating that trade-off.

  6. Missing # in color directives.

    It’s a silly typo, easy to make, easier to fix. Why don’t graphical Web editors flag this? Why don’t users of graphical editors use those programs’ code-checking features? Why do birds come out of the sky every time you walk by?

  7. Proprietary tags and attributes.

    Whether it’s NATURALSIZEFLAG in PageMill or Netscape’s SPACER or GoLive's CSACTION, these scream “amateur!” louder than “Welcome to my kewl site!!!!!!!” does. (As does a page containing
    <META name="GENERATOR" value="Microsoft Word">.) If you must use those canned CSACTION scripts, stick them in a separate JavaScript file and link to it, so you can access the same file once instead of adding code bloat to every page. SPACERs don’t work in most browsers, so unless you really want to restrict yourself to about a third of all Web users, don’t use them. And as for NATURALSIZEFLAGs, here’s a tip – they don’t do anything in any known browser; they exist only to make PageMill’s life easier. Once you’ve finalised your page, you can rip them out with no ill effects.

  8. Block-level tag inside an inline tag.

    This error is a bit more technical. To show what’s wrong with it, I will have to explain somehing about HTML: some tags – like DIV, H1 and P – are “block-level” tags that start a new line at their beginnings and ends. Others, like SPAN, A and FONT, are “in-line” tags that don’t start a new line. You can’t put a block-level tag inside an inline tag. Well, you can, but then it’s not valid HTML and you might find that your page doesn’t render reliably in newer browsers.

    This error is most commonly seen when designers try to wrap a table inside a FONT tag, to avoid having to put the FONT tag inside every cell in the table – yet another reason to hate font tags. You already know my response: use stylesheets already!

  9. Raw characters not entities in URLs.

    Almost nobody realises this, but most browsers expect to see entities like &amp; instead of the raw character & in URLs. Of course, when you click on the link in a page, the browser translates this to & and the user is none the wiser. But it’s important to get this right if you want to send your readers to the places you intended.

  10. BASEFONT problems.

    The BASEFONT tag was intended as a way of setting the font attributes for a whole page, instead of sticking in a bunch of FONT tags. It is deprecated in HTML 4, but if you must use it:

    • only use one per page;
    • put it in the body, not the head, or the validators will think that the BODY tag has already been inserted;
    • make sure you have a SIZE as well as a FACE attribute.
  11. Comments with too many hyphens.

    HTML comments can contain any text except pairs of hyphens. Which means this is completely wrong:
    <!-- ---------- my attempt to draw a rule in the comment tag ------- -->. Use underscores, pounds (#) or asterisks (*) instead.

Of course, these aren’t the only errors you find in supposedly professional pages. The number of code stupidities you see are astonishing, including in supposed “HTML references” and “Web design guides”. Surf around with iCab some time and prepare to be disgusted: it will report all these errors, and also flag all FONT and CENTER tags.

Blaming the tools

So why all this crud code if HTML is such a simple language? Part of the problem can be sheeted home to bad code by uninformed coders. But I think the problem goes deeper than individual ignorance. When a site gets bigger than a few dozen pages, people look to automated tools to generate pages, whether it’s the Slashdot-style conferencing software, Vignette StoryServer, or some other method.

Guess what? Most of these tools spray out FONT tags, spacer GIFs and all manner of improperly nested junk. StoryServer has a tendency to add extra hyphens in comments; Slashdot is a FONT tag breeding ground, and most others will take whatever garbage you give them without complaint or question. Ad banner servers are particularly bad with things like ampersands in URLs (this caught the Web Developers’ Virtual Library, whose pages would otherwise validate). This is simple stuff that should be fixed.

I’m sure a lot of those problems relate to the way the templates and boilerplate code used in these tools is set up by the client Webmaster, so once again individual designers might be responsible. But script publishers can help the situation by generating default HTML that is compliant. They could also make it easier to change boilerplate code or use stylesheets.

Web editing tool manufacturers could also do more to stop designers making those mistakes, like validating on save. They could easily add options to allow users to allocate a DOCTYPE to their page without having to manually edit the code. The editor could then validate according to the assigned doctype. But instead, many of the editing tools – particularly the graphical ones aimed at the rest of us – actively add in proprietary code, or ignore your desires to write compliant code (Adobe lost me as a GoLive customer for exactly that reason).

No wonder Web designers everywhere spend more time chasing down bugs and glitches than exercising their creativity. Tool developers need to make it easier for their customers to do the right thing by their customers. But we designers need to keep our side of the bargain, too – and that means writing HTML that validates.

— CodeBitch ( is the grumpy cow who does the HTML production for MacEdition.

E-mail this story to a friend