1In fact, it’s probably too expressive since it can also generate all sorts of output that’s not even vaguely legal HTML. Of course, that might be a feature if you need to generate HTML that’s not strictly correct to compensate for buggy Web browsers. Also, it’s common for language processors to accept programs that are syntactically correct and otherwise well formed that’ll nonetheless provoke undefined behavior when run.

3In the strict language of the Common Lisp standard, keyword symbols aren’t self-evaluating, though they do, in fact, evaluate to themselves. See section 3.1.2.1.3 of the language standard or HyperSpec for a brief discussion.

5Another, more purely object-oriented, approach would be to define two classes, perhaps html-pretty-printer and , and then define no-op methods specialized on html-raw-printer for the methods that should do stuff only when *pretty* is true. However, in this case, after defining all the no-op methods, you’d end up with more code, and then you’d have the hassle of making sure you created an instance of the right class at the right time. But in general, using polymorphism to replace conditionals is a good strategy.

7While XHTML requires boolean attributes to be notated with their name as the value to indicate a true value, in HTML it’s also legal to simply include the name of the attribute with no value, for example, **<option selected>** rather than **<option selected='selected'>**. All HTML 4.0-compatible browsers should understand both forms, but some buggy browsers understand only the no-value form for certain attributes. If you need to generate HTML for such browsers, you’ll need to hack to emit those attributes a bit differently.