Web Design Small Cover

Buy the PDF of
Web Design:
A Complete Introduction

See the book at amazon.co.uk or amazon.com

Related Site

Web Security Topics

Related Books

Secure Communication Cover

Securing A Server Cover

Teaching Notes for Chapter 3

Download the end-of-chapter questions. (Zipped plain text files, UTF-8 encoded.)

While there is nothing intrinsically hard about anything in this chapter, it will demand a considerable readjustment from experienced design students, who will be accustomed to thinking purely visually and having precise control over every pixel. The idea of describing a document using markup, and later stylesheet rules, may seem unnatural. There is no point in trying to disguise what's going on by using visual authoring tools. It may be necessary to reiterate the differences between Web and print from Chapter 1, and emphasize that the Web needs a different approach, but that visually appealing pages can still be made, just in a different way. (Show some examples.) Some design students may begin to struggle at this point with their first introduction to the technical material, and the best thing to do is take it slowly and give them time to absorb it and get used to working with markup.

Markup provides the essential structure on which all other aspects of page design hang. It is therefore vital that all students have a good understanding of the material in this chapter. It cannot be denied, though, that it is pretty dry stuff, because the pages we can produce without stylesheets look ugly and dull, and the semantics of XHTML is too limited to allow any interesting structures to be developed, so students may get bored and frustrated.

We chose to present all the material in one chapter, so that it would all be in one place, and later chapters could refer freely to any aspect of it. We still think this is the best way to present the material, but if you think your students will find it hard to swallow in one go, it would be feasible to intersperse material from this chapter with some from the next, introducing some document elements and immediately showing how they could be made to look nicer. However, this would require you to introduce the fundamentals of both XHTML and CSS at the same time, which might prove as indigestible as this chapter as it stands.

There isn't really much material in this chapter that can be omitted. If you don't expect to have to deal with tabular data, tables could be left out. (Never use tables for layout.) Frames have only been included so that students are aware that they exist and have usability problems. We advise that they should not be used, and do not refer to them again, so they could be omitted entirely, unless you think students may come across them elsewhere and become confused.


We introduce elements, tags, attributes and so on in a pure form as XML. For students who are going on to more advanced work in Web development, or who are likely to need SVG, SMIL, MathML or some other XML-based languages, it will be useful to deal with XML on its own like this. We believe it would be helpful for all students to understand where the rules are coming from, and find it easier to explain DTDs and namespaces with reference to XML. However, it is entirely feasible to talk only about XHTML, simply describing the rules about document structure, syntax of elements, and the other features in the section on XML as if they applied to XHTML alone.

There is a school of thought that holds that as long as Web pages are served with the Internet Media Type text/html, designers shouldn't use XHTML but should stick with HTML4. This argument makes little sense: XHTML enforces stricter checks which makes documents more robust, it can be mixed with other XML-based languages and manipulated by any tools that work with XML. It is also the way forward. It's true that browsers are treating XHTML as malformed HTML, but that need not concern the designer, provided that the XHTML is validated before being uploaded, and the compatibility guidelines in Appendix C of the XHTML 1.0 Recommendation are followed.


Students should get used to routinely validating their markup as soon as they start creating complete documents. Validation can catch many errors, and it is often the case that the reason a document that is not displaying the way it was intended to is invalid markup. Validation can prevent you wasting time trying to find errors in a stylesheet, when the problem really lies with the markup. Tell them about the W3C Validation Service. Encourage them to install validation bookmarklets in their browsers.

If a student comes to you for help with a page that isn't working, your first question should be, have you validated it? You should make it a requirement that all code submitted for assessment must be valid.


At this stage, students will begin creating Web pages, so they will need to start using software to do so. For vocational courses, it may be necessary to use Dreamweaver. Experience using the nearest thing to an industry-standard tool will be valuable. However, if Dreamweaver is being used, students should be encouraged to use its code editor, to make sure they can see what code is being generated; they should be able to change it where necessary. Unless it is necessary to teach Dreamweaver on vocational grounds, it should be avoided, so that students are not tempted to try to design pages visually in Design mode. (On no account use Microsoft HomePage or any other tool that generates invalid markup. Microsoft Expression Web should be OK if your department uses MS tools, but it is still in beta and we haven't tried it.) Ideally, every student should have created at least one non-trivial Web page entirely by hand.

Appendix A describes some alternatives and other software that students will need for their practical work. Don't risk alienating them by forcing them to write code in a simple text editor like NotePad. If it suits the style of your course to have code written by hand, make sure that decent HTML editing tools (BBEdit, TextMate, emacs, or whatever fits in with your systems) are available.