The authors are not responsible for the content of any external sites linked to from webdesignbook.org
©2006–2012 MacAvon Media.
Answers to Exercises, Chapter 3
Buy Chapter 3, Markup, in PDF format: now available from the MacAvon Media Downloads Store.
- Web pages must be processed by computer programs, in particular browsers. Programs do not have people's ability to perceive the visual appearance of the page and infer the relationship between its different parts from properties such as similarity, proximity and contrast. (Possibly, programs incorporating artificial intelligence will be able to do this one day, but progress in that field is slow.) On the other hand, extracting the structural information that is necessary for displaying the page or extracting information from it can easily done by a program if explicit markup has been used.
- The sample fragment violates the following restrictions:
- Element names may not include spaces (
- Start and end tags must match in case (
- Attribute values cannot be assigned in an end tag (
- Elements must be properly nested (second
emphelement starts inside first paragraph and ends in the second)
- Attribute values must be enclosed in quotation marks (
>signs must be replaced by the corresponding entity references
- Character references include a ; at the end (
- Element names may not include spaces (
- A well-formed XML document may include a DTD. A valid XML document must include a DTD.
- The first three lines (as the document is laid out in the book) comprise the document type declaration, which identifies the language used as XHTML, declares the root element to be
html, and provides the public identifier and the URL for the XHTML Strict DTD. The next line is the start tag for the
htmlelement, which sets the default namespace to the XHTML namespace, by assigning a URL to the
xmlnsattribute, so that elements do not need a namespace prefix. It also identifies the natural language of the document as English, using
xml:langfor processors that treat XHTML as XML, and
langfor those that treat it as HTML. The compulsory
headelement follows immediately. It contains a
metaelement which tells browsers that the document's Internet Media Type is
text/html, in case the server has not sent the information in the HTTP response. It also explicitly declares that the character set being used is UTF-8 encoded Unicode. Next, the document title is set (or rather, here it is not set, since it has been left as
Untitled) and the
headelement is closed.
An XML declaration may precede the document type declaration but rarely does in practice, because it forces IE6 into quirks mode. Other browsers that don't understand XML may simply display the XML declaration, so it is best omitted to ensure that the document is displayed correctly by the largest number of browsers.
After the code displayed will come the
bodyelement that contains the page's content. The
htmlelement's close tag is needed after the
- The answer to this question depends on the DTD being used, but assuming you use XHTML 1.0 Strict, as recommended in the text, the document must have the following elements:
body. Strictly speaking, the
bodymay not be empty, but any element that can appear within it is sufficient to make a document valid. In fact, the W3C validation service pronounces a document with an empty body to be valid – but this may be a bug in the validator.
- A block element is usually displayed so that it is visually separated from other block elements, by default by having a blank line above and below it. Technically, block elements are those that can appear as children of the
bodyelement. There are about twenty block elements, including
divelements. An inline element is run in with neighbouring elements, and cannot appear directly inside the
bodyelement. There are about thirty inline elements. Commonly used examples include
span. As we will show in Chapter 4, we can use stylesheets to change whether any particular element type is displayed as a block or inline.
- The pragmatic reason for not using
preelements to lay out pages is that it won't always work. You cannot be certain that any user will actually set up their browser to use a fixed-width font for these elements, and if they use a proportional font, characters won't line up where you want them to. The next reason is that, inside a
preelement you cannot apply any additional formatting, so you cut off most possibilities for controlling the appearance of your text. The deeper and most compelling reason is that you also lose any meaning and structure that you could apply with conventional markup: everything is part of a
preelement, and only distinguished, if at all, by its position. Hence, you are even worse off than using the sort of visual formatting we dismissed in the answer to question 1.
- The three list element types are
ol(ordered list) and
dl(definition list). Unordered and ordered are actually poor names: all lists are ordered, but the items in an
olelement are (by default) numbered. Hence
ulelements should be used for bullet points,
olelements for numbered items, where the numerical sequence is important and you may need to refer to individual points by their numbers. Although
dlelements are suited for lists of definitions, as in a glossary, they can be used for any sort of list consisting of terms with an associated description, or even for setting out the dialogue of a play or film script.
- (This is too easy.)
/index.html -> ../index.html
/feedback.html -> ../feedback.html
/TF/index.html -> ../TF/index.html
/TF/configure.php -> ../TF/configure.php
/TF/Resources/techspec.pdf -> ../Resources/techspec.pdf
- Frames cause usability problems, because a URL is no longer associated with a single page. This causes problems with bookmarking and using the history list. It also leads to the likelihood of a document designed as part of a frameset being displayed in isolation (for example, if a user reaches it via a search engine) and losing context, such as a navbar which was in a separate frame. This may mean that the visitor cannot navigate to any other part of the site.
Discussion Topics: Hints and Tips
- This question was suggested by the fashionable topic of microformats, which you might investigate as a starting point. The microformat enthusiasts seem to take their superiority to XML for granted, so you will still need to think about whether XML might do the job better, and if so, why it isn't being used in this way.
- Compare your answers to this question with the ideas embodied in both XHTML2 and the alternative HTML5 proposals.
Practical Tasks: Hints and Tips
- We will emphasize again: always use a validator to check your markup. The W3C offfers a validation service; some Web authoring tools have validators built in. Think carefully about what constitutes appropriate markup. XHTML does not have a set of elements specifically suitable for CVs, so what is the best way of using the elements it does provide? In the case of headings and sub-headings, the answer should be clear, for other parts of the document you may have to make a choice between paragraphs and different types of list. As we say in the question, don't worry too much about the appearance of the resume. You will have a chance to improve it later on. Concentrate on getting the markup right.
- Your table should be part of a document, so that you can see it in your browser, of course. Once again, check that the markup is valid.
- Don't omit to test the usability of your form by filling it in, even though you can't submit the data at this stage. If possible, get other people to try to use it. If they find it confusing in any way, refine your design. Try to keep everything simple for the user; don't try to be clever.
- There are bookmarklets (also known as favelets) freely available, which allow you to submit the page you are currently looking at to the validation service. The Firebug add-on for Firefox allows you to examine and modify the structure of Web pages inside the browser. Similar facilities are available in all the latest versions of the main browsers (Internet Explorer, Safari and Opera.)