About my pages

From time to time I succumb to the temptation to write an "about my site" page. A few years ago I had one which evolved into an exposition of my design philosophy, and then into a whole sub-site of Web design tips for amateurs. I deleted it when it seemed that events had overtaken me. I was giving newbies tips for constructing lovingly hand-whittled HTML, in an age when real newbies were all using graphical tools to make bloated, garish pages covered with frames and spinning logos, and wouldn't have touched HTML code in a million years.

This is a happier time for the Web, even though it is a sadder time for Internet start-up companies and the Web design industry that supports them. People still don't like to code and shouldn't really have to, but they are getting interested in things like standards and accessibility, browsers are getting a lot better, the stupidest Web companies are actually dying of their stupidity, and if there is any justice in the world, Web development tools may actually get better.

There have already been some really interesting developments such as Blogger, which I don't personally use, but which seems to have sparked a revival of highly personal, text- and link-heavy amateur Web pages with things to say. Flash notwithstanding, it's as if the Web is starting to shrug off some early pathologies and to find out what it's good at.

On the other hand, I don't need to bring back my long screed about Web design because there is actually much good advice out there already for beginners. So I'll just talk about my pages and put a few opinions at the end.

First experiments

I wrote my first HTML files almost immediately after discovering Mosaic in 1994. I had played around with the CERN line-mode browser previously via Telnet, but there wasn't much to the Web at that time. By the summer of '94 there were more sites to visit, and along with inline pictures, Mosaic added something else: it had a drop-down menu that took you directly to resources on HTML. The message was that creating your own pages was easy.

I immediately made a little private home page that functioned as a fancy hotlist; it was the direct ancestor of my links page. I didn't have access to a public Web server, though, until I got my World account. Then I started adding more content. I learned how to do many things by looking at the source of other pages, so my HTML was the barbarian mess common to the era (it was some time before I learned that there was such a thing as the <HTML> tag). The appearance of the page changed wildly, with the usual weird-looking background patterns and color changes; some old images are here.

Cascading Style Sheets

I've always found it slightly galling that the graphical browsers used by most people have a default text rendering style that is uglier than what the non-graphical browser Lynx does. At the dawn of the era of Web Design, David Siegel used to tell people to abandon structurally correct HTML and use nasty, labor-intensive tricks like invisible spacer GIFs and hard line breaks to make pages look better. More from laziness than from a will to standards compliance, I didn't particularly want to do that. Nobody's paying me to do this.

When the first crude Cascading Style Sheet implementations appeared for the Mac, I started playing with CSS on my Web site. In theory, with CSS you could write plain, universally accessible HTML that would be readable on Lynx or Mosaic, yet still make the page look fancy and beautiful on a supporting browser. I saw the great potential of the standard and wanted to do my little bit to support it, if only by using it.

Unfortunately, playing around with IE3 and Netscape 4 on my Mac, I soon discovered how inexcusably bad their CSS support was. I had to settle for fairly conservative CSS use. There was no W3C online CSS validator then, so I made some mistakes that I didn't catch for years. Nevertheless, it was then that I established the essential look of the pages you are now reading, and subsequent changes have been refinements to that design to make it slightly prettier and more elastic.

In any event, for a while I had one of the few pages on the Web that actually used some CSS. Style sheets had a reputation as a dangerous, broken technology, and people who knew something about Web design kept telling me to get rid of them. Now I'm happy I hung on to them, since CSS is coming into its own, now that browsers with half-decent CSS support are widely used. I do still have to use some ugly hacks to get around browser bugs.

I have lots of opinions on CSS design philosophy, but you probably don't want to hear them. (If you do, here's a page about my CSS decisions.)

I've started specifying alternate stylesheets on a few of my newer pages in the Kibology section, just for fun. Currently Mozilla/Netscape 6 is the only browser I know that has real support for these (View->Use Stylesheet). On Internet Explorer, they can be accessed through scripts that could be activated with links on the page; some people have even constructed elaborate cookie-based mechanisms for making the user preferences persistent. However, I really don't want to clutter up my pages with that stuff just because IE has missing pieces.

HTML 4

Most of the pages here are in HTML 4.01 Transitional, with a DOCTYPE bearing a DTD URL, tailored to put IE5/Mac and Mozilla/NS6 into "obey standards" mode rather than "emulate old bugs" mode.

A few pages are in XHTML 1.0 Transitional, just so I could see how well it worked. Currently I don't think that there is any great advantage to migrating pages to XHTML en masse, but it doesn't seem to do any harm either, except that some HTML tools have not caught up with it completely.

I'm reluctant to go to Strict markup quite yet, since it would involve a lot of recoding, and I'm not quite ready to eliminate things like background color for the non-CSS crowd.

I use a few HTML tricks in these pages that are less widely known than they deserve to be.

Many of my links now have TITLE attributes that give supplemental pop-up information (appearing as tooltips or help balloons in Internet Explorer). These don't work in old Netscape versions, and many people are under the false impression that they're a proprietary Microsoft feature, but actually they're part of the HTML standard (iCab also supports them in the form of status bar rollovers). They are just right when you'd like to give the user more information about where a link goes, but it won't fit in the flow of the sentence.

Another thing that iCab and Lynx users may appreciate is the use of the standard HTML navigation links (home, toc, prev, next, etc.) on many of these pages. This is a standard that has been around for some time but is, for some insane reason, still not supported by the Big Two, so only users of minority browsers will get to enjoy this. My use of these links is somewhat haphazard, but they're particularly evident in the Lem pages and the blue sky pages. Unfortunately since most browsers don't support them, I have to provide some redundant navigation-bar links on the pages themselves.

Tools

My pages are mostly hand-coded in BBEdit on my Macintosh (I used the free version for years, but recently upgraded to the full package) and then checked and cleaned up with the excellent HTML Tidy plug-in. Since I'm using Mac OS X now and tend to upload things with scp in the command shell, I sometimes do quick edits (like this paragraph) in GNU Emacs.

I learned a little Perl and wrote a primitive script that turns my alt.religion.kibology posts into HTML. (It is pretty bad Perl and probably not of general utility, so I won't post it here.) I used it to do most of the collections of my a.r.k posts and Samantha's posts. I wouldn't have been able to convert so many pages otherwise. With BBEdit you can run Perl scripts as filters right inside the editor.

Most of my hand-drawn images start out as drawings in Adobe Illustrator. Sometimes I make them pretty in Painter (Fractal Design Painter-- my copy is that old) but usually they end up being processed in the superb Graphic Converter, the Swiss Army knife of cheap Mac graphics shareware. I have a Wacom ADB tablet; I have to boot into Mac OS 9 to use most of its features, because Wacom seems to have no definite plans to produce an OS X driver for the old thing. Oh, well, they have to pay the rent somehow. My creaky old graphics software works better in OS 9 anyway.

I made the 3D effects on the Lem pages (such as Trurl) with a very old version of Adobe Dimensions. The mathematical illustrations on the science pages were generated in Graphing Calculator.

Lately I have started taking many photographs, especially of our cats. Kitty photos are the stereotypical bad Web content, but people seem to like mine, so I'm keeping them up. My camera is a Nikon Coolpix 2500, a little and (relatively) inexpensive digital camera that I heartily endorse, though serious photographers would probably want more. I use an unholy combination of iPhoto and GIMP (the latter running under XDarwin on Mac OS X) to manage and edit my photos. Graphic Converter still beats GIMP for format conversion, but GIMP is a much more powerful photo editor.

Bad browsers and backwards compatibility

OK, I'll express ONE opinion on Web design philosophy. Well, maybe two or three.

One question that has caused me a lot of grief is: just how much is a Web developer obliged to sacrifice to make pages completely inclusive?

I try here to make my pages readable in any browser that is widely used, and in most that are not widely used. I follow standards; my code validates unless I've slipped up somewhere (or am making a joke about bad Web pages); the site looks good in Lynx.

But one of the tricks I do will actually crash some very early and buggy variants of Netscape 4. (To add insult to injury, the trick is a work-around for other Netscape bugs.) These versions are not very widely used any more-- in the admittedly questionable stats pages that are out there, their share is in tenths of a percent-- but, on the other hand, they are still more widely used than some of the niche browsers that I do try to support. I'd have to give up much of the look and feel of the pages to avoid this crashing bug, or do browser-sniffing JavaScript garbage that I refuse to do on the grounds that, durn it, you have to draw the line somewhere. So I'm excluding a few users, in a rather catastrophic way. Is this a sin?

Here's my attitude: lack of features is one thing, bugs quite another. If you make a page that only works on some specific browser, or isn't readable without Flash or JavaScript or CSS or frames or graphics, you should be prepared to lose a significant part of your audience. There are people who use unfancy browsers, or intentionally turn off those features, for very good reasons. When it's easy to support these users, in my opinion, it's a bad idea not to. (Some types of artistic or entertainment content might not be translatable in any sensible way into text. In some cases you can still make such content downloadable for offline use.)

Also, a search engine's spider bot acts much like a non-graphical, non-frames Web browser. If you don't let them read, you can forget about getting hits through Google or Altavista.

If the problem, on the other hand, is that the browser has a stupid bug that makes it croak on perfectly good HTML/CSS, then at least it's not your fault, and other considerations come into play. How many people use the buggy version (granted, all statistics on such things must be taken with a grain of salt)? Is a fix for the bug widely available, without switching to an entirely different browser? How likely are people to have gotten the update by now? Can a work-around be done without breaking the rendering in other, better browsers? There are no easy answers; it's a judgement call. You can probably get away with more on your personal home page than on an e-commerce site.

This has become a controversial issue again in the wake of the Web Standards Project's Browser Upgrades Campaign. After some consideration, I don't think I agree entirely with the Web Standards Project's approach to this problem. They suggest using DOM and CSS sniffing tricks to display messages to users of buggy browsers asking them to upgrade, or (as a hard-line option) even to withhold content from them entirely.

In most cases this would take as much effort as the workarounds to make the page degrade gracefully. Also, I'm not convinced that the CSS-based tricks are all immune to false positives, particularly in the presence of arbitrary user stylesheets. Some of the tricks depend on "display: none;" working as intended on the user agent; what if the user has "display: block !important;" on the same element?

I'm feeling a bit better about their "kinder, gentler" approach following recent revisions to the suggested phrasing!

I do hope that standards-compliant browsers become more widespread, and the WaSP people have done a great job haranguing browser manufacturers to get them to come about. I also think that it's good to educate users about standards and browser support for them, but not to pester or exclude them if it is easy to avoid doing so. After all, many of the folks being pestered will inevitably be people who know perfectly well about standards, and, for some reason or another, don't have a choice.

On the other hand, if we had to work around every off-by-one and memory stomp in every build of every browser in the world, Web development would become impossible. We'd have to test every modification on every browser, since, when considered as a black box, any complex computer program will have some more or less unpredictable failure modes. The strategy that has worked for me so far is to build to standards first, with an eye toward graceful degradation on older browsers that work correctly, and then to hack around the bugs that are likely to be major problems (without abandoning the standards if I can possibly help it).

It's also worth making sure that a bug really is a bug. When Internet Explorer 5 for the Macintosh came out, a lot of the "bugs" that people complained about were really just badly written Web pages that broke because the browser actually followed standards. It did have some real bugs, but they didn't get much attention. Now I'm hearing the same kind of whining about Netscape 6. Again, it has some real bugs, but many complaints are about unreal ones.

If you're even at the point of having to worry about the stuff I'll mention next, you're way ahead of the game; the most common difficulty that novices and even pros get into is that instead of starting with standards, they start with machine-generated HTML of dubious quality. They then repair this by trial and error until it works in a couple of browsers, and complain when it inevitably doesn't work in the next one. Validate your code, folks... or at least use HTML Tidy. Embrace the future.

DOCTYPE sniffing

There is much confusion about DOCTYPE sniffing. The designers of a couple of very modern browser engines (IE5/Mac's Tasman and Mozilla/NS6's Gecko), faced with the fact that W3C standard rendering will break many existing, badly coded pages, decided to examine the page's DOCTYPE in an elaborate way and go into a "bugwards-compatibility" mode for some DOCTYPEs and a "standards" mode for others. The details of the sniffing behavior are described elsewhere, and I don't want to go into them, but the DOCTYPE on these pages puts both of them in standards mode.

Some descriptions of DOCTYPE sniffing confuse the distinction between Strict and Transitional syntax with the distinction between standards and bugwards-compatibility rendering modes. This has led some authors who use Transitional markup to use bugwards-compatibility DOCTYPEs just because they think that otherwise their pages will be "misinterpreted as Strict" by Netscape 6 or IE5/Mac.

This is a misconception. It so happens that these browsers apply standards mode to pages with Strict DOCTYPEs, but they also apply it to pages with certain specific Transitional DOCTYPEs, and this is by design. (Whether or not this strategy was a good idea is a separate, hotly debated, moot question.) The true purpose of Transitional markup is to allow some presentational tags for older browsers' sake, and standards mode still allows this. Whether you are using Strict or Transitional markup, if you care about the rendering of your pages at all, standards mode is what you want. Bugwards compatibility mode is for people who are not as careful as you are.

Accessibility

I'm in the process of recoding many of my files to improve accessibility, particularly for blind users, beyond the fairly simple measures I've already taken. The worst offenders are the Kibology pages, which are full of superfluous headers, preformatted quoted text with quote characters, and ASCII art. There are also some others that need lots of work, cleaning out things like preformatted ASCII equations (I wish that MathML were really usable). It may be a while before I figure out how best to revise those and do all the manual labor.

The W3C accessibility guidelines and tools like Bobby are a big help, but I'm encountering some interesting contradictions. For instance, W3C guidelines say that any navigation bar of links at the top of your page should have an initial link to skip past the others (so users of audio browsers won't have to wait through them all the time), and non-link characters between links (to help some screen readers along). They also say to use the standard links already mentioned. But in Lynx, a browser used by many blind people with a screen reader, the standard links appear as a top-of-page navigation bar with no extra link to skip them and with no non-link characters between links!

The author can get around the first problem by putting in a special bookmark link, and the user can get around the second by selecting numbered links, but these are both of the nature of presentational hacks, not the sort of thing the W3C generally wants page authors to have to worry about. As is often the case on the Web, the problems with the browsers people actually use can do damage to ideals and standards. In this case, it isn't so much a problem with the browser itself as with the sub-optimal strategy of using a screen reader with a text-based Web browser instead of using an audio Web browser that could read the markup directly and style it with audio CSS. With luck the technology will get better.