Many of the documents in here are working documents that were written for a specific purpose, and are here in the hope that the information they contain may be of use to others.
These documents are designed to be viewed by any HTML-conforming browser. The original plan was to encourage users to support browsers which presented content in an attractive fashion that was appropriate to their browsing situation and to their needs (see notes below). When I'm concentrating on writing textual content, I don't expect to be continually bothered with designing the details of typography too. Unfortunately, the popular browsers from the Big Two had a dreadful default presentation, which was then perpetuated through their subsequent versions, and led many people to believe that HTML documents cannot be attractively viewed without peppering them with HTML3.2-like presentation attributes. Fortunately, we have stylesheets, designed for suggesting an attractive presentation without causing (as HTML3.2 did) more problems for accessibility than they solved in terms of presentation.
I've been writing HTML, off and on, for quite a while now, in the course of my work, and I must say I am less than impressed by my efforts, especially the early ones. I rarely write documents whose purpose is to demonstrate the power of HTML for its own sake, and I tend to use constructions rather conservatively.
When participating in Usenet discussions about the WWW, my basic tenet of writing HTML is to leverage the power of this "new" medium to the greatest possible audience. It's said that a picture is worth a thousand words, and if the message is best expressed with a picture then I'll use one, but I do not like scattering meaningless images through my textual material as a form of decoration. In my opinion if material is by its nature textual, then it can be and should be just as accessible to the sight-impaired (who need to use a large font) or to the blind (who may be using a speaking machine), so I resist any techniques that need the author to specify a particular arrangement "on the page", except where such an arrangement is inherent in the presented material (e.g tabular data). Equally I find no reason to deny information to those who, for whatever reason, may not have access to high-end platforms. Textual material displays well enough on a character-cell terminal ("VT100", for those old enough to remember what that was), so what is the point of marking it up in a way that can only display properly on an expensive graphics terminal? Contrary to popular superstition, there's no reason that making text accessible to a VT100 has to prevent it from being displayed attractively when the browsing situation is capable of an attractive presentation.
My view is that it is the job of the client rendering agent (be it a character mode browser, a graphics display, or a speaking machine) to render the material in a way that makes best use of whatever resources are available to the reader. And not to forget those other honoured visitors, the indexing robots. (Critics tend to call this "writing for the lowest denominator", and they imagine that it means avoiding all kinds of markup that don't produce the same visual result in every browsing situation: which is the opposite of what's really intended, and would in any case be impossible: in short, they don't understand what "making best use of the available resources" means!).
Only the client agent is in a position to know the resources at its disposal, the configuration choices of the reader, and the strengths and weaknesses of the available platform. Given the logical structure of the incoming material, and an imaginative browser design, it would be possible to do a better job of exploiting the available resources fully on whichever platform was being used, in a way that simply isn't possible when the presentation has to be commanded by the author, as so many authors seem to think is appropriate - why they yearn for adding this drudgery to their job of authoring, I don't know. If I had to make the choice of presentation style (e.g for a family of documents), I'd want to select it once and then forget it, along the lines of selecting a style sheet in LaTeX or in MS Word. Or along the lines of writing a book, where my job as an author is to deliver the content, and leave the task of typography to the publisher. If style sheets hadn't already been invented for HTML, it would be high time to invent them. But they already had been invented, and - after a few years of erratic and unpredictable implementations - browsers have, more or less, finally got themselves fairly close to implementing what the specifications require of them, as long as one knows how to avoid their propensity for reproducing the bugs in their earlier versions.
Anyhow, my main point was that purporting to give the author control over font names, sizes, colours etc. from quasi HTML tags, as the major commercial developers were doing at HTML3.2, simply does not work on the World Wide Web as a whole, since there is no way of knowing whether a reader's platform has font Foo Uncial 60pt available, nor whether the reader is colourblind or the terminal is monochrome. The browser might not even be displaying the text visually; quite apart from blind readers, the busy executive might set their browser to read HTML pages out loud to them. The WWW aims to address all readers, not only those who conform to the author's preconceptions of browsing situation.
The other major aspect of leveraging the WWW is the operation of robot indexers and summarisers: any technique that makes their operation difficult certainly militates against a full exploitation of the power of this "new" medium. The original concept, as explained by Tim BL in the documents now found at W3 still makes a great deal of sense to me.
Some people want to use the WWW as a delivery medium for eye-catching advertising or similar purposes: it often gets discussed whether this is an appropriate use of HTML, it being a relatively poor "page description language"; many of those people have a background in advertising, and I haven't, so I would be taking a risk if I try to analyze their approach in detail, but what I can say is this. Advertising normally aims to catch the reader's attention when they aren't otherwise interested in the product; on the WWW, by contrast, they won't be reading your page unless their attention has already been caught. One might say that advertising works in "push mode", whereas the WWW works in "pull mode". If you don't give readers, within a reasonable time and without hassle, the information they were looking for, they will likely go elsewhere. It would be a great pity if the WWW searchers got to fill their indexes with references to transient and more-or-less content-free documents, concealing the wealth of genuinely useful information of long-term value on all manner of subjects that already is available or will become available in the future on the World Wide Web.
It's pretty obvious that a thin deposit of HTML can be used as a sort of "hyperglue" to stick together an array of graphical designs, and in some situations that would be a perfectly reasonable thing to do: however, this would not then be about "making textual materials available to the widest possible range of readers", and I see no need to have a deep philosophical discussion about it in the context of HTML. It is a perfectly serviceable application of HTML for a specific purpose, but it makes no attempt to exploit the innovative features of HTML (namely, the marking up of logical structures in textual material, and making them available on the 'net for use in many different ways - viewing, summarising, indexing, printing etc.).
My documents here might well contain HTML errors of syntax or style. Although I believe I do know what is correct, or how to find it out if I don't know, I make no claims to be perfect. If and when I have time, I do check my HTML with verification tools, but documents may get worked over in the odd moment and might not always get re-checked.
In short, I make no claim to be offering you a spectacular tour of HTML's capabilities here. These documents were written for their respective purposes, and you are welcome to take them, or leave them, on that basis. "If not fully satisfied, please return within 14 days for a full refund of my fee" ;-).
The ideal browser has not yet been written. It would, at the very least, provide an attractive display of the standard HTML logical structures by fully exploiting whatever resources were available on the particular platform. I would also like it to offer an Overview mode, and various other conveniences for easier navigation within HTML documents. For example, support for the LINK tag, as is found in Lynx and emacs-w3, and was in NCSA Win Mosaic 3 etc.
Commercial browsers, while offering a wide range of associated facilities, such as hotlists, newsreaders, mail clients and such, are really very pedestrian in their presentation of logical HTML structures - even the relatively limited standard structures defined in HTML2, let alone the enhancements that were proposed in the now-expired HTML3.0 draft (not to be confused with the execrable HTML/3.2 version that was finally released by W3C). At a time when the web was exploding in popularity, the vendors stifled its technical development by rushing-in a load of presentation-based quasi-HTML tags and attributes for controlling the reader's platform: since the author can have no idea what platform the reader is using (from a low end monochrome display with a limited range of fonts, to a high-end large screen high resolution truecolor display with an extensive range of fonts, quite apart from the possibility that the user might be using a character-cell text browser or a speaking machine), this approach was neither practical, appropriate nor useful on the World Wide Web in my opinion. The vendors, whether by intention or neglect, seem to have convinced a large population of users that the web is, or should be, just an old fashioned WYSIWYG DTP application, with none of the benefits of content portability for which the WWW was originally conceived.
Only much later did it finally become practical to suggest presentation via a stylesheet, although it's still not as easy as it should be for the user to influence a choice of alternative (author or user-provided) stylesheets according to user needs.
Finally we are getting somewhere with the deployment of stylesheets, and (in my opinion) vindicating the original promise of the concept, and debunking the wasted years of presentational quasi-HTML. Text worked-over to reflect this.
Stylesheet fitted, some adjustment to the text to cover the fact that stylesheets are now working to some degree.
In 1996 I had commented favourably on the introduction of CSS support in MSIE3.0. Although that was a positive development as a principle, in hindsight the details were unfortunate, as MSIE3's CSS support was experimental and quite buggy, which can now, in the presence of a valid stylesheet, actually make some WWW documents unreadable. By 1999 my recommendation to those still using MSIE3 versions was to disable their CSS "support".
Original materials © Copyright 1994 - 2006 by A.J.Flavell