99% of sites obsolete - so what now?

[Thomas Dowling]

I often like and agree with what Zeldman has to say (even though his
web site specifies font sizes in pixels--sigh).  In this case,
although he's on the money, I don't think he's saying anything that
this list hasn't covered repeatedly over the years.

I found myself recently trying to articulate just what assumptions
authors make today that still lead to such tag-soup markup.
Consciously facing up to them is a start to overturning them as
appropriate for your site, which is a start to a more forward-looking
site.  Here's what I came up with.


   "Backward compatibility" means making a page *look* in an old
     browser the same as it looks in a new browser.  I disagree: our
     responsibility for backward compatibility is to make pages
     continue to *work* in a reasonable range of old browser
     versions.
"Current compatibility" covers IE versions 4 through 6, and
     Netscape 4.  Disagree: I consider Netscape 4 to be obsolete, and
     merits consideration only as a special case of backward
     compatibility. The major current browsers are IE 5.5, IE6, Opera
     6, and anything built on Mozilla 1.x.  Fortunately, these
     browsers observe standards for document structure, presentation,
     and scripting to a much greater degree than we have seen in the
     past.  Not perfect compliance, of course, but there is certainly
     no reason left to expend massive effort on browser-specfic hacks
     (possible exceptions for high-end work with DOM or CSS box
     models in IE5.5).

   "Forward compatibility" is impossible because we don't know what
     future browsers will do.  Disagree: there is a very strong
     likelihood that future browsers will comply with today's
     standards better than today's browsers.

   Whatever code is created by mainstream editors must be good
     enough.  Disagree: with the apparent exception of Dreamweaver
     MX, the default output of the popular HTML editors does more to
     perpetuate the status quo of poor, non-structural markup than
     anything else.

   The user is running:

     - a mainstream graphical browser
     - in a mainstream graphical OS
     - on a desktop or laptop computer
     - almost maximized or fullscreen
     - with either 800x600 or 1024x768 monitor resolution
     - with client-side scripting, Java, and major plug-ins enabled

     I don't honestly see an onrush of people using cell phones and
     PDAs to surf the web, but I do know that the few people using
     them are doing so in circumstances where they really cannot get
     to a PC.  Likewise, people using a non-graphical browser
     (including speaking browsers or screen readers) really cannot
     just turn on images.  And while there may be many people who
     turn off client-side whizzbang technologies who *could* turn
     them on for your site, they clearly had some reason to turn them
     off in the first place, and they're at least as likely to go
     somewhere else as to enable them for you.

     The common assumptions about screen size annoy me, as a user,
     more frequently than anything else.  Depending on what I'm
     doing, it seems like my browser window is about 650 pixels wide,
     900 pixels wide, or 1100 pixels wide (usually with resized
     fonts).  In any of these cases, all those 768px-wide table-based
     pages look stupid.

   Accessibility rules don't apply to us.  Disagree: the number of
     sites that are explicitly required to meet formal accessibility
     standards is going up worldwide, and the Big Lawsuit that will
     force other sites in the U.S. to meet accessibility guidelines
     is just waiting to happen.



Thomas Dowling
OhioLINK - Ohio Library and Information Network
tdowling at ohiolink.edu