[Theforum] evoltspotting

rudy r937 at interlog.com
Wed Jun 12 12:18:18 CDT 2002


matt (metafilter) haughey, in an extremely active thread on Webdesign-L
resulting from the wasp2 launch --


-----Original Message-----
From: Matthew Haughey <matt at haughey.com>
To: Web Design <list at webdesign-l.com>
Date: June 12, 2002 12:46
Subject: [WD]: The top myths of Web standards

Coming back from a long vacation and catching up on the 300+ messages I
missed in the past week, I noticed a recurring trend in postings that
warrants mention, as I think it could really help out the Webstandards
project and the web as a whole.

I'm surprised to see a few people I respect as designers and developers
that are showing some reluctance to embracing standards, or incorrectly
assuming any number of misconceptions about standards, such as "if site =
100% standards code, then site doesn't work in every browser and looks
ugly."

A suggested remedy: in addition to communicating the clear benefits of
writing standardized code (we've gone over almost all of them in the past
two days) on this list and elsewhere, it is imperative to speak to the fear
that designers and developers on this list feel when they are told it is in
everyone's best interests that they re-learn how to do things. I've seen it
in all sorts of vocations and I'm seeing it now in web design. Even the
most seasoned web veterans will approach a call to read up on new
developments and rethink how they've done things for years with some
caution (and in some cases fear they may fall behind).

Laurel W. LaFey's message from 24 hours ago echoed what I hear from
developers I've worked with that don't understand web standards, the
benefits of it, or why they should go to the trouble of following
standards. Frankly, I'd put myself in that group, circa 1998. Back then I
thought that web standards did equal ugly sites (for a variety of reasons,
mostly because the sample content I saw was quite simple and CSS support
was terrible back then). I was also erroneously convinced that coding to
standards was "extra work" for me to do (I quickly learned that coding to
standards usually required less code and once I learned how to do it, I was
much faster). There was also a stigma attached to standards back then that
was very close to zealotry; the people that shouted about web standards
back then seemed like anal-retentive freaks that spent far too much time
arguing about attributes that didn't matter in the latest windows IE
browser of the day (I eventually learned why this was both short-sighted of
me and a bad interpretation of what I read, and what benefits sticking to
standards offered; I also hope that's not how people like Steve Champeon,
Eric Meyer, and Scott Lepera come off today).

It took me about a year of experimenting to come around to the other side
of things, and I'm surprised to hear people holding the same views today,
but I can certainly understand the point of view. Perhaps what is needed is
an all-encompassing document that speaks to the common myths and
misconceptions we're seeing repeated on this list. Something to the effect
of the following:

* Coding to standards means older browsers get left out.
There may have been a time when browser support was so poor and screeds
from impassioned developers stated that they didn't care about old browser
support, but the fact is that coding a site to HTML 4.01 or XHTML today
will function quite well in older browsers (including text-only browsers).
While this might leave out something like IFRAME use (which is in the 4.01
spec, but not supported in NN 4), the vast majority of web page
functionality is supported and exists both in the standard and most any
browser.

* Standards-compliant sites are ugly.
With CSS support in everything that came after Netscape 4 improving close
to 100% support for CSS-1, this is no longer the case. In 1998, the sites I
saw that demonstrated full standards support were boring documents that
looked like they were designed in 1994. Today that is not the case. I would
hold Evolt.org up as one of the most elegantly designed, standards
compliant sites around. It has a lot of things going on (forms, sidebars,
dynamic content, long blocks of content, directory sections, search
engines, etc) that could translate to any number of real-world websites and
it looks good doing it (it's also incredibly customizable through custom
display settings for members). Although running through a list of a dozen
tableless, CSS-only weblogs doesn't exactly equate with a commerce store's
interface or a general news site, there are certainly beautiful things out
there being done with standard code. Also, sites may not be pixel-for-pixel
perfect in browsers new and old alike, but that's OK.

* You will have to redo every site you've ever done and spend months
figuring out how to do this correctly. This one might have some truth to
it, but the benefits far, far outweigh the weekend you'll spend learning
how to use CSS for text-styling instead of <font>, and how a basic site can
benefit from CSS margins and widths and lose the spacer gifs. You won't
necessarily have to recode old work (especially if it's a client that's not
paying for it :), but it's a Good Idea to code every page you can from here
on out as close to standards as possible. My own sites (mostly older) lag a
bit here, but current client work is close to, if not at full, 100% support
for at least HTML 4.01 standards.

Steve and others here, you've seen a lot of opposing opinions and
misconceptions bandied about here, what other myths exist out there that
keep people from coding to proper HTML standards today?

Matt




More information about the theforum mailing list