I Am Eric's Colophon

Up Front

This site is laid out with a combination of styles and tables-based layout. I've tried to do the layout with styles alone; we just ain't there, yet, though, so this display uses a hybrid of styles and tables to get the best compromise feasible between display flexibility and stability across browsers.

The general structure is entirely tables-driven. The layout structures are defined in a separate include file which can be swapped to support "skinning" with different layout schemes. For maximum rendering speed, table structures are only one layer deep, and include:

  • A top section, including site-wide navigation and identity elements.
  • A middle block, including body copy, right-side and left-side columns which can contain navigation or secondary content elements.
  • A footer section, which primarily contains a copyright statement and an additional contact link.

Specific aspects of layout (such as borders, colors and background colors, background images (where appropriate), fonts, and the display of menu and list elements) are controlled by a stylesheet. Information elements, such as menus and content blocks, are segregated into a separate include file, and are not modified from scheme to scheme. All information elements (and sub-elements) are contained within appropriate, labeled DOM containers.

In the baseline scheme, the design uses no graphics to construct navigational or display elements, though such elements could be added without editing the information elements.

To improve readability in situations where styles are not available, most elements are separated by horizontal-rule tags which are rendered invisible in the stylesheet.

I Feel So Degraded

Rendering degradation is a fact of life in web design. Any who deny as much, delude themselves.

Once you decide to drive display on a site using stylesheets, you must make a decision about how much of the visual presentation you need to be available on non-CSS browsers. If it is terribly important to you that, say, the page background color be lime-green, then you'd best set the appropriate hex-triplet in the body tag. Simple.

On this site, the degradation can appear to be harsh: Anyone viewing with a non-styles browser (which includes Netscape 4.x with JavaScript switched off) will see no formatting that is not controlled by the simplest of document-level controls. It's a question of cost-effectiveness: I don't view it as cost-effective for me to take any effort to make the site look beautiful for something less than one percent of my viewing public.

On the plus side, you will see all actual site content and be able to use all site functionality. In other words, you will be able to use all features of the site. So while the site might degrade in a visually unappealing fashion, it will remain usable.

A special note regarding Netscape's version 4 browsers: Thanks to their frankly bizarre stylesheet support, it's very, very difficult to achieve true compatability with Netscape 4 when using such marginally complex style attributes as "border". For example, span containers without borders are character-level elements; span containers with borders are block-level elements. The background-color attribute has similar issues. For that reason, this site uses a JavaScript routine to switch off any troublesome attributes when the pages are displayed in Netscape 4. (Since JavaScirpt and stylesheets are essentially the same feature in NN4, this technique works rather nicely.)

Degradation will be with us for the forseeable future, regardless of what people say. While the current leading-edge browsers are as close to having common rendering as they have ever come, rendering issues remain. This site was originally designed primarily using Mozilla; and looks best in Mozilla variants (such as Mozilla, Phoenix, Netscape 6/7, Galeon, etc.); it also looks pretty much the same in Safari. But it should look pretty close to the same in Explorer 5-6 (it's hard to test sites using earlier versions of Explorer, since you can't very easily have two versions installed on the same hardware).

In any case, rendering degradation is the nature of the medium. Those who don't like it, should be designing everything in Flash. It's really that simple. (end of sermon)

Down Back

Antikoan.com is hosted on a FreeBSD system at ADDR.COM; I can't recommend them, and will be leaving them as soon as I can locate a host that suits my future plans. Dynamic pages are served via PHP, using an evolving system based on work originally done in ASP for the Xelus.com corporate website.

That said, I'm in the process of moving all content on this site to Dreamweaver templates -- not in the least part so that I can force myself to use them effectively. There's a good possibility that this site will be moved to an open-source content management system (most likely Drupal), but that's not going to happen very soon.

All development is currently done on a Macintosh Mini, running PHP 4.3.x and Apache 1.3.x under OS X 10.2.x. So far, I have found no cases where this poses a problem for development, which speaks highly to me of the PHP team's committment to cross-platform operation.

Around the Edges

In the trivial department, here's a litany of tools used non-exclusively in production of this site.

Versions of this site have been edited using everything from the TextPad text editor on Windows to web forms loaded in a browser to Dreamweaver on a Mac.

Since there are no graphics here, I can't say I've used anything in particular. But in the past I've sworn by PaintShop Pro, and I do own a copy.

Currently, I'm driving almost all of my uploads through Dreamweaver; anything I can't do through the site-management features in Dreamweaver, I do using Fire-FTP on Firefox (since I haven't bothered to look for an OS X ftp client yet...).

I have a couple of PHP references, both of which are OK in their way, but I've relied most heavily on the on-line manual at PHP.NET.

HG