{Motivation} {HTML Tips and Issues} {Images} {Misc.}
Style sheets are wonderful! Hmmm, that could have been the case much sooner, if there hadn't been so many different flakey browser implementations. The browser makers only had several years to get used to the idea, which they seemed to have spent in the main devising short-term hacks to avoid actually having to implement style sheets.
Well, a muted welcome to the fact that they are finally Doing the Right Thing, and a massive vote of thanks to those victims who have collected up lists of what works and what doesn't. Sue Sims's collection of CSS links is a most valuable directory to a range of excellent resources.
Todd Fahrner clearly knows a hell of a lot more about typography than I do, and, although (or maybe "because") his motivations were often very different from mine, I felt I learned a lot from studying his pages. He since seems to have withdrawn from this activity and his pages are now frozen, but this classic quote stands firm:
The font size chosen by the user as a comfortable default (1 em) provides more truly useful information about the rendering environment than all the resolution-sniffing, window-querying, "open-this-wide" logic you can throw at the problem.
You want to get pixel-exact control over your web pages? A lot of people think that way, but read Web Pages aren't Printed on Paper, by John Allsopp, and then think it over.
See my HTML Internationalisation (i18n) for a briefing on how things are supposed to work on the WWW, and some resources to help exploit it without falling foul of known bugs.
Related to this topic area, quite some time back I prepared an HTML4-compatible character map for use with an earlier version of rtftohtml, now to be found at LOGICTRAN. A version of the map got incorporated into the package.
Way back, I noticed a regular procession of newcomers popping up on comp.infosystems.www.authoring.html offering their amazing comprehensive/ one-stop/ authoritative/ whatever guide or tutorial to HTML; mostly, these folk had never posted on the group before, nor ever responded to discussion. Noticing that these would-be guides routinely disregarded HTML syntax rules and generally-accepted good practice, I got into the habit of feeding their URLs to a validator and commenting on the results.
History (Google Groups, to be honest) records that in a Usenet posting on 11 Aug 1997, Stan Brown first used the phrase "Flavell's Law", and this seems to have taken on a life of its own. I've seen several versions quoted of just what my "law" is supposed to have said. Dejanews found reference to it on sfnet.aloittelijat.kysymykset:
"Snif, sääli vain, että tuohonkin pätee ns. Flavell'n laki"
I've since seen it quoted in Norwegian and Dutch too. However, Matthias Gutfeldt takes me to task for subjecting youthful enthusiasm to such scrutiny.
Many of the resources linked from this section are now several years old. But, you know, the principles of good communication haven't suddenly changed, although the detailed landscape has certainly shifted: the writeups I'm pointing to seem to me to be based on some fundamental principles that don't suddenly get overturned just because a new version of one of the mass market browsers comes out. In truth, recent browser versions (albeit their initial implementations have been dreadfully flakey) have amply vindicated the principle contained in the original promise, of a content-based logical markup in HTML, decoupled from suggestions for presentation contained in separate stylesheet(s), just as was hinted at in the HTML/2.0 specification (RFC1866), and negating the short-termist but ultimately counterproductive overloading of HTML (3.2) with presentation-specific markup attributes, which are now (HTML4.0) for the most part deprecated.
There's a kind of perversity in the way that some of today's pages are increasingly bloated with multiple versions of Javascript, misguidedly intended to make the document available to versions of only two browsers, in ever-narrower ranges of browsing situation, when all observation shows that the trend is towards increasing diversity of browser and browsing situation, which can be beautifully reached by an appropriately flexible WWW-oriented authoring approach.
Hints for Web Authors - I commend this view by Warren Steel.
A good writeup called Composing Good HTML was written by J. "Eric" Tilton, back when HTML3.0 was still a live issue, and the depredations of HTML3.2 still lay in the future: it sets out some principles which the careful author can apply to whatever level of HTML they aim to write.
Jahn Rentmeister's article This page optimised for... arguing with customers". Another way of looking at the same issues is Morons in Web space, written to ridicule "stupid tricks" used by authors who seemed to be writing for self-gratification rather than to communicate with their users.
For a collection of good sense coupled with practical studies of user behaviour, Jakob Nielsen's site would be hard to beat, especially the consistently readable Alertbox articles published twice a month. What's that you say? - you don't care for the hair-shirt visual design of his web pages? Yup, I've heard that criticism often enough before, but it doesn't change the fact that his message about communicating effectively with users is based on sheer good sense as well as on real practical studies. I feel sure you'd have enough imagination to work out how to apply the principles to your own preferred visual style in a WWW context.
An excellent resource for those who want to make content accessible to a wide audience is the WDG's website (or its mirror at Stack).
If you want to go into great detail on the minutiae of vendor extensions and browser support levels, Brian Wilson's Blooberry site has what looks to be a very well-researched and documented HTML Element Index.
While I would certainly want to discourage authors from writing HTML that relies on any of this flakey detail, Brian Wilson earns kudos for making this comprehensive research available. And his authoring style is also exemplary: the page works well on a wide range of browsers and browsing situations, with or without CSS enabled; the HTML passed syntax validation, and the CSS passed the W3C's checks with only a couple of kinds of warning, one of which was I think a justifiable attempt to overcome differences in browser support.
To counteract some of the tedious "Straw Man Arguments" that keep cropping up on the usenet WWW groups, I put together a Straw Man Argument Collection.
I'm not aiming here to offer a primer or tutorial for beginners. What you find here are tips and issues on selected topics, aimed at readers who are presumed to be familiar with at least the elements of HTML and the WWW already.
Some hints for Layout Diagnosis in CSS etc.
Text-friendly authoring techniques: IMG ALT, imagemaps, etc..
Public Transport web site accessibility (1997/8, jointly with Iain Logan)
Beware the Dreaded Click-here Disease: In Opera, you can ask to see a list of links on a page (shortcut: Ctrl+J). Other browsers may have similar features. Review your link texts: do they make sense out of context, or do they all say "click here"?
Caches and cacheability:
An old discussion paper on (HTTP/1.0) Negotiated Content and Caching
CSS and the Decorative HR, in the spirit of "graceful degradation".
An amusing exercise in TABLEs; the original was too wide for many readers' browsers
How to mimic form submission with HREF correctly
See also *DRAFT* about FORM submission and i18n
An evolving document Language Negotiation Notes.
To tell the browser to stay on the same page - send HTTP status 204 - but does it work? (the answer is nowadays probably "yes", but with older browser versions there were problems).
In an HTML context, it's useful to keep in mind the distinction between "Validators" and "Checkers". "Validators" (properly so called in an SGML context - and HTML is an SGML-based markup) apply strictly the syntax rules set out in the DTD that is nominated in the DOCTYPE, nothing more and nothing less, without fear or favour. "Checkers" apply checks on both the syntax and some other issues, such as common mistakes of authoring style or known shortcomings in browser support. Both kinds of software are useful to have, but to understand better what they are doing you should know which is which. Beware: some heuristic checkers misleadingly call themselves "validators".
There's fuller discussion on my separate page on Validators and checkers.
Above all, for images to be used on the WWW you need to understand the distinction between JPEG formats on the one hand, and palette-based formats (GIF, indexed PNG) on the other. A great place to start is Tom Lane's justly famous JPEG FAQ.
After that, you might find my article on palette use helpful.
For some purposes, it may be useful to specify image size in em size units so that they scale with the user's choice of text size. My images em sized page has a few samples and commentary.
I've also collected a few resources about image gamma
A small Ruby Annotation demo, for glossing text in a foreign (and in this case, rare) language.
There are basically two ways to put counters on your page: the wrong way, and the very wrong way.
Original materials © Copyright 1994 - 2006 by A.J.Flavell