The HyperText Markup Language is, surprise!, a markup language. That means it's for marking up text; that is, telling computer programs what type of information text represents. It's not, fundamentally at least, for telling them how text should be displayed to humans nor for building interactive human interfaces. (Cascading Style Sheets, on the other hand, are concerned with how information is arranged and presented in the various media.)

It does offer form controls and links, but these can theoretically be used by programs other than visual browsers - if page authors use the markup appropriately. It does provide elements which effect formatting in visual browsers, but only because formatting is how visual browsers can meaningfully render the markup. It's about meaning, not appearance. Appearance is simply the mainstream representation of meaning; HTML allows the representation to be determined by the medium (such as your car's audio system).

This chapter tries to give you the tools to build interoperable, or medium-neutral, pages, and to keep them easy to maintain. Note that you don't need all of these things to start designing Web pages, but to do it right you will need them. So it's okay if you decide to be lazy about this stuff for now, in the interest of not getting overwhelmed. But come back to it regularly to see what other stuff you can do.

A plain-text editor

To create an HTML document, you need a text editor which doesn't format text written within it, nor otherwise add any of its own markup (as rich-text editors a.k.a. word-processors do), because HTML parsers wouldn't understand that. Text-editors for some common operating systems are listed below.

For Windows users:

  • Go to your Start Menu, into All Programs, then Accessories. Find the Notepad item and click it.

For Mac users:

For Ubuntu Linux users:

  • Go to your Applications menu and into Accessories. Find the gedit Text Editor item and click it.

After you have opened the correct text-editor, save the file with a filename extension of .html; for example, first.html. That will make this document an HTML document which you can edit to make webpages. You don't need a webhost to write a webpage or view it in your browser, although you can't publish it (show it to others via the Internet) without one.

Validators and other checkers

HTML is commonly invalid, ugly, and non-semantic, even when written by experienced designers. Some of these problems can only be detected by a trained eye, but many can be caught by programs.

First of all, you should make sure your HTML and CSS are valid; the other checkers will be confused if they aren't.

Once the relevant validator(s) don't complain (or at least their complaints are incorrect), you're ready to use some of these:

Relevant blog posts:

Every major browser

The Web is a platform for interoperable documents; that is, documents (including "Web applications") which "just work" when practically any user accesses them. Unfortunately, browser vendors disagree on some finer details of what working means, and this can result in pages developed in one browser looking horrid in others. Standards organizations such as the W3C attempt to lessen this problem by authoritatively defining these details, but some behavior remains undefined and browsers sometimes fail to behave as the vendors intend, like all software.

The solution is to test documents in every major browser. Which browsers are major mostly depends on your target audience, but in general the following are essential. (A full list of browsers is available here.)

Internet Explorer

  • Trident layout engine
  • used by a slight majority
  • the only browser for which multiple versions (as old as 5, because some users fail to update) are commonly tested
  • versions 5 and earlier available on Macintosh


  • Gecko layout engine
  • the leading competitor to IE
  • an Open Source project
  • available on all known platforms

Google Chrome

  • WebKit layout engine
  • a recent upstart, now the third leading browser behind Firefox
  • mostly Open Source
  • available on all known platforms;


  • WebKit layout engine
  • the official browser of Mac OS X (and possibly their mobile offerings as well)
  • now available for Windows
  • not natively available on Linux;


  • Presto layout engine
  • market share low on workstations but high on mobile devices
  • known for strict standards-compliance
  • available on all known platforms

A debugger for each browser

This section is somewhat more relevant to JavaScript development, but it nonetheless deserves mention here. These debuggers are available for the browsers listed above, organized by supported platforms:


  • Firebug (Lite): Firebug is a Firefox extension; Firebug Lite is a cross-browser JavaScript implementation.
  • jsFiddle: A website, not exactly a debugger but nonetheless useful for testing HTML, CSS, and/or JavaScript, or sending links to pasted code.

Internet Explorer 8

Internet Explorer 6 & 7

  • Visual Web Developer: Apparently the best option according to consensus. Express editions are freeware; each of the others costs more than the one to its left.
Express Professional Premium Ultimate
2010 [2]


[5] [6] [7]
2008 [8]
  • Microsoft Script Editor: Shipped with Microsoft Office 2000-2003; see here.
  • Microsoft Script Debugger: The (non-)solution that everyone seems to hate (see below).
  • Resources: This took some digging... These probably work about the same in IE 6 and 7, and maybe 5, but none have been tested first-hand.
    • [9] - Current to IE6.
    • [10] - Current to IE6.
    • [11] - Current to IE7.
    • [12] - Written after the release of IE8 but seems to target IE7.

Google Chrome



A screen-reader and text-only browser

As mentioned above, the Web is a platform for interoperable documents. That means computer programs and disabled users can access them too. Unfortunately, the more dynamic documents (known as "Web applications" - despite all webpages being applications of the Web) can't work this way. But if you don't really need that kind of document, accessibility can be designed for.

Text-only browsers view pages as search engines do, for the most part (that is, ignoring minor JavaScript enhancements in the search engines). They also give a good idea of how a screen-reader will present a page to a seeing-impaired user, although of course they are not entirely reliable in this capacity. One approach is to test frequently in a text-only browser and save the more time-consuming screen-reader tests for final tweaking. If search engines are not a concern, frequent screen-reader testing may be substituted for the text-only browser.


[TODO: We need to fill this in for each operating system.]

Text-only browsers