Menu

Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

No Standard for Migrating to Web Standards

by Joshua Porter
on August 29, 2002

Lately, it seems like everyone is talking about migrating to web standards, like
XHTML and Cascading Style Sheets (CSS). What’s the big deal about these standards?
Why should web teams invest the effort to learn new coding techniques and convert
all their legacy sites over to standards-compliant sites?

Time and Money, that’s why.

Let’s say you want to change the colors or rearrange the layout for a site
built with templates that use a table-based design. "It’s a nightmare," says
Eric A. Meyer, author of the books, Cascading Style Sheets: The Definitive
Guide
and Eric Meyer on CSS. "It can take days just to finish.
With a standards-designed site, you have simple markup and centralized CSS,
and changing the colors and even the layout can be a matter of an hour’s work." Eric
says that no matter whom you pay to do the updating on the website, be it an
in-house admin or an expensive consultant, the additional time it takes to
make these changes will cost you money. The time required to update a CSS-driven
site is a tiny fraction of that required for a table-based site.

Molly E. Holzschlag, author of Special Edition Using HTML and XHTML,
agrees. "Early case studies suggest that compliance probably saves money
for everyone in the web site food chain – from site owner to developer to ISP.
Those are the immediate advantages. Longer term, working with standards addresses
many technical, creative, and even social concerns. Technically, web sites
will be more easily maintained and readily available for many platforms beyond
the web. Creatively, we can apply style sheets that will easily make a site
look good on a computer screen, on a PDA screen, even in print. Socially, we
remove barriers to access by cleaning up our hacked markup and paying attention
to accessibility concerns."

One of the best things about the standards is the features that support accessibility
concerns. For instance, CSS provides for a set of properties that support voice-synthesizer
devices, frequently used by vision-impaired users. With simple coding techniques,
designers can switch between styles to support the broadest ranges of users.

Once a web team has decided that they are ready for standards, they need to
know when they should start making the move. "The best time is now, and
not a moment later," according to Eric. "If you don’t know the first
thing about the topic, then start learning. If you’re familiar with the subject,
then start planning for a conversion. If you already have a plan, then launch
it as soon as is feasible."

Eric says that building websites using old standards is like "putting
a steam engine in an automobile. The technology was great for the day, but
the state-of-the-art has moved on."

Molly is careful to stress the long-term benefits of switching to standards. "Learning
web standards on a professional level is a commitment that will take effort
now and require years of study to maintain and grow. Being a web designer or
developer is no longer novel. We have very complex jobs to do and standards
are a means of doing that job with maturity and excellence. When your team
has a good overall understanding of and long-term commitment to standards,
that’s when you can consider a switch."

After web teams convince themselves, their clients, and their management that
they should switch to standards, they need a plan. Both Molly and Eric recommend
integrating standards gradually. They suggest starting at a redesign point
or when you’re building a new web site. That way, the pain of change or additional
learning is partly expected, and the change able to be folded into the expected
budget.

What about all the content that’s already out there? Should you plan to convert
it right away? "Not necessarily," says Molly, who has been here before. "If
the cost to make all legacy documents compliant is prohibitive, then begin
to move forward from this point using standards. If, at some point in the future,
you can address the legacy concerns, do so then." There’s no rule that
says that the site has to be 100% standards-compliant on the first day.

As for techniques to help you switch, Molly suggests teams put together a
style guide for new coding practices and content, such as corporate logos and
colors. "Add sections for specific clients where necessary. Research and
try out development tools, such as very highly flexible and affordable content
management systems and visual editors that are standards-savvy. Study your
browsers-this may be the toughest part, because the platform and versioning
differences are vast." She also suggests checking out standards validators,
such as Dave Raggett’s HTML-Tidy,
the World Wide Web Consortium (W3C) validators,
and accessibility validators like Bobby.

Eric suggests an approach that he calls a support matrix. Teams should identify
different levels of user experience, and what needs drive each one. "For
example, the top matrix level could be the bells-and-whistles site with flyout
menus and juggling bears and everything. Then next level down is the same site,
but without the flyout menus and such; it’s still navigable and useful, but
it doesn’t have all the frosting. And so on. Then you determine what level
of standards support is necessary for each level, and go from there."

Even with a lot of enthusiasm for standards, developing for them can still
involve a steep learning curve. You can avoid some common pitfalls. Eric says
a common problem occurs when teams have unreasonable expectations. Web standards
are not a cure all, and won’t make all problems go away. Some browsers have
better support than others do. He notes, "I see lots of teams run aground
on nitpicky details that aren’t quite consistent between browsers, and that’s
a shame. There are much bigger fish to fry than whether or not the page title
has 10 or 14 pixels of space under it. Remember the whole forest, and that
standards offer you the best path through it."

Molly urges teams to continue doing those things that have worked in the past,
like a solid client needs analysis. It’s important to know if your users have
different needs that you must address in your choice of supported browsers
and standards. For example, you might still have to code for 4.0 browsers because
your users are on an intranet where the technology support hasn’t yet upgraded.
Molly promises, though, that most problems are solvable following standards. "It
just takes an understanding of the standards," she maintains, "to
know how they can be applied to each problem."

Because standards are always growing and changing, Molly is a big advocate
of standards education. Teams must continue to learn about evolving standards,
so they can implement effective plans for the future. She suggests going right
to the source, the W3C. However, Molly warns
that "much of the W3C’s material is very complex and exhausting for the
busy web professional to go through. The Web
Standards Project
(WaSP) is an excellent place to get information. They’re
providing an early but growing resource for learning more about standards." Molly
also says book publishers New Riders and glasshaus are "paying sincere
attention to these concerns". Eric agrees, adding O’Reilly as a publisher.
He also points to newsgroups and mailing lists as a valuable resource because "no
book or specification will cover every question you might have."

The acronym-filled world of standards can be frightening, if you let it. However,
the promise of saving time and money, while making everyone’s job easier in
the long run makes it worth investigating. •