Wozard of Iz

The Wozard of Iz: An Electronic Odyssey
Mort Garson/Jacques Wilson
A&M SP-4156
Album cover art
Rare electronic concept album (1968)


Ziziphus Lotus

Ziziphus Lotus
North Africa
Probably the lotus described in Homer's Odyssey

Web Development: An Odyssey in Less Than 1200 Words

By Charles J. Conrad


It seemed a straightforward task: build a new web site for Conrad Consulting, Inc. Of course, things are never quite as simple as they first appear. For the benefit of those who follow, this is my odyssey.

I have never really been in the web development business. I did some development several years ago as a way to familiarize myself with the existing technology and the likely ways in which it would evolve. I then put it on the back burner for a few years. Recently, I decided it was time to develop a new web site and that now would be a good time to see how thoroughly things had cooked and what new technologies had come to fruition. That is, I decided to make it a learning experience.

Like most engineers, I prefer to build on standards and standard methodologies whenever possible. This applies to all technical design, not just software related. Normally, this approach saves time and provides a certain known level of functionality, performance, compatibility and reliability. Seems reasonable, right?

So, what standards are appropriate for a web site? I'm big on decoupling and manageability, so content separation through CSS makes sense. Stylesheets should be in separate files for consistency and to simplify updates. Broad compatibility through strict XHTML also makes sense. Scripting, if necessary, is ok, but it should be used judiciously and adhere to the DOM interface. Performance is important, so the file sizes should be kept reasonably small and free of extraneous code and HTML, but comments are ok. All files should be cleanly organized, commented and versioned.

Checklist in hand, I went evaluating (and maybe a little shopping):

  • XHTML maturity (check)
  • CSS maturity (partial check)
  • JavaScript maturity (check)
  • DOM maturity (partial check)
  • Browser compatibility (barely visible speck)

I studied several documents and web archives regarding standards based development, elements of good design (where I have seen that before?), and lots and lots of tricks and hacks (an appropriate term if ever there was one) to make various things work cross-browser. I experimented with various techniques proposed by the myriad of experts for multi-column layouts and pull-down menus using only CSS. I wrote some test scripts to acquaint myself with DOM. I even read several of the W3C standards. After a few weeks of this education, I gained a reasonable working knowledge of the relevant technologies, the most significant browser compatibility issues and developed this web site. In other words, I graduated and I am now eager to pontificate. I present the following for your digestion and edification.

Gutenberg Bible

Gutenberg Bible
Library of Congress
Washington, DC USA
http://www.loc.gov/jefftour/firstfloor.html

  1. The CSS model is flawed. Period.

    Oh muse, must you be so harsh? Humans have been printing for more than 650 years and have more than 20 years of experience with desktop publishing. It seems a reasonable expectation that we should be able to at least get the basic model right. Unfortunately, this is not the case. Basic flaws include:

    1. No intrinsic support for multi-column layouts. Newspapers have it. Magazines have it. Look at a Gutenberg Bible. Two-column layout!
    2. A broken, inconsistent coordinate and unit system. I prefer mathematically consistent systems. Where is the origin of the canvas? The viewport? Where is the origin of a box? Where is the origin of a parent relative to a child? What happens if the margin, borders or padding change? How do I establish a different coordinate system? How do I transform between coordinate systems? How do I scale? Why can't I specify a transform between canvas and viewport? Why do I specify the width and height of the content area and not the complete box? Should I use negative margins to fix everything? Which dimensions do percentage units refer to? What if I want to refer to a percentage of a different dimension? Frankly, it is a mess.
    3. No support for variables or symbolic definitions. How long have we been writing software?
    4. No support for calculations. Postscript has it. CAD systems have it. My cell phone has it. CSS? You guessed it.
    5. No support for testing and branching. Let us just say: No support for programming of any kind. Given the experience that exists, I think a much better result should have been achieved. I can hardly wait for CSS version 3 (he said sarcastically). Maybe I'll let that pot simmer a bit longer.

    What were the developers and standards group thinking? Oh, these fuzzy declarative lotus-eaters!

  2. All browsers should support simple conditional testing and branching based on type and version. The method used by Internet Explorer (IE) is fine (conditional comments). Standardize it. As long as there are competing browsers, there will be different feature sets. Get rid of CSS hacks for conditional execution. I can't imagine trying to maintain software written like that. Uugghh!
  3. Compatibility with some browsers, especially older ones, can be ignored. Really. This apparent preoccupation with providing compatibility for outdated software is amazing. Just let them read text (and eat cake).
  4. Behaviors aren't evil.

    Using behaviors to fix deficiencies and restore compliance in IE is a reasonable approach provided they are properly isolated using conditional comments. As an example, the broken hover in IE complicates menus. So, fix it. There is an available behavior that does exactly that: hover:anything.

    I also used this approach to fix IE quotes. IE 7 and earlier does not quote <q>…</q> tagged text, in case you were wondering. I like my IE quote fixer better than others I have seen because it correctly spaces alternating nested quotes. If you are interested, you are welcome to use it: fixquotes.htc

    If you are using IE 6, 7 or 8, the following should be nicely formatted. Other browsers are on their own.

    Nested quotes of various types and sorts.

  5. It is ok to use JavaScript to add functionality. Stop playing bizarre games with CSS.

    I used JavaScript for image replacement of selected headlines. I like my image replacement better than others I have seen because it still supports the use of CSS for image placement (e.g., positioning). If you are interested, see Image Replacement Revisited for a better explanation.

    By the way, I did not bother to test whether or not image loading is enabled, which is advocated in a alternate image replacement implementation. My pages generally only have one image to be replaced, two at most. Why bother with a complicated time stamped test image load for one or two images? If it fails, it fails. Just let them read text.

  6. Multi-column lists should be natively supported in CSS. I manually balanced mine, but that is not the optimal approach. Assigning each item its own class or ID, as some have proposed, is even worse. Probably more lotus-eaters. Talk about a maintenance headache.
  7. All of my XHTML, CSS and JavaScript sources are commented, if you have any interest in looking at them. I do not have a high volume web site. The bandwidth cost of these comments is noise.

I believe I implemented a pretty clean web site that uses a reasonable balance of standardized technology and optional flair. Not gaudy, but not ugly either. I also have reasonable solutions for image replacement and IE quotes that I have contributed back to the community.