 | Level: Introductory Michael Russell (MikeRussell@VickiFox.com), Application Architect, Vicki Fox Productions
18 Apr 2006 Discover how to shift the priorities of your Web site from appearance to functionality and use Web standards to ensure cross-browser compatibility in this column by Michael Russell.
Does it take a long time to make simple changes to your Web pages?
Are bandwidth charges higher than you would like due to the size of your
Web pages? Have you written hundreds of lines of code just to handle
browser differences? If so, you might emphasize the
appearance of your Web pages over their functionality. Also, you probably spend far too much time ensuring backward compatibility with obsolete browsers.
In this article of my Quality busters series, I'll show
you how to shift the emphasis and priorities of your Web site [and use
W3C standards like XHTML, Cascading Style Sheets (CSS), and
Document Object Model (DOM)] to reduce maintenance time,
lower bandwidth charges, and decrease the amount of
browser-specific code you write.
A maintenance nightmare
The SHEEP Web team was assigned to enhance the SHEEP customer
sales application -- a typical e-commerce site consisting mainly of a product
catalog and shopping cart. The first thing the team noticed about
the application was that it was very attractive. It presented the company's
products in a colorful and entertaining manner. But customer
satisfaction surveys repeatedly showed dissatisfaction with the amount of
product description and details and the ability to compare products.
The Web team's task was to add more content and product
comparisons to the commercial site. As the team worked on the changes,
they ran into at least two major difficulties:
- The code was loaded with tables and small spacer images to achieve
the desired layout. It was easy to make typographical errors when adding
new rows or columns to display new content. The team only discovered such errors after testing each change on numerous browsers. The complex
table layout also increased the time required to determine where to make
a change or add content.
- The application consisted of many hundreds of lines of JavaScript code to
compensate for browser differences and add special effects.
Unfortunately, the last time this code was maintained was before the
introduction of popular browsers such as Firefox®. As a result, it took a
considerable time investment to modify the JavaScript code to handle newer
browsers.
Rethinking priorities
|
The SHEEP application
The Quality busters series uses the SHEEP application to present an
ongoing discussion of quality issues. The SHEEP application is a
fictional aggregation of sales e-commerce applications the
author has encountered at different companies. The quality issues are
loosely based on real-world problems addressed at those companies.
The first
article in this series introduced the SHEEP application.
|
|
Seeing what they were up against, the SHEEP team's architect notified
the project manager that the site's coding was very difficult to modify
and that the project would take longer than originally estimated. Out of
curiosity, the project manager looked into the history of the Web site
to see if there was a particular reason for the site being so difficult.
It turned out that the site's two major influences were compatibility
and appearance.
The first driving factor for the site was backward compatibility with
older browsers. The site was launched during the early days of the Web.
As it evolved, and as Web technology advanced, the company added new
features. To ensure the largest possible audience, the site was designed
to work with all the popular browsers of the time. To minimize the
impact of the rapid rate of change in the browser market, the company
decided to freeze the site's HTML tags at the level commonly supported
by Microsoft® Internet Explorer® 5 and Netscape® 4. It was this level of
compatibility that resulted in extra complexity in the layout of pages
and the necessity of JavaScript code to add new functionality.
The second driving factor was the consistent appearance of the pages
across browsers. The pages were carefully laid out so that a page would
appear nearly identical whether shown on Internet Explorer, Netscape,
Opera, or any other graphical browser. To achieve this, the pages used
numerous nested tables and small spacer images to enforce table cell
widths.
With this research the project manager went back to the site sponsors
and asked, "Is this compatibility necessary when less than 0.5% of your
customers use these old browsers? And, is identical appearance across
browsers necessary when you can establish brand recognition in other ways?"
Migrate to Web standards
The sales application example illustrates quality issues caused by incorrect
emphasis. The quality issues include increased maintenance time from support of obsolete browser versions and increased bandwidth costs from large Web pages that contain browser-specific markup and code. Fortunately, you can easily work around problems like this if you use the World Wide Web Consortium (W3C) Web standards.
Before 2003, the complexity of Web-page design was a consequence of
the lack of any standards or consistent HTML implementations. Browsers
competed by adding extensions to the HTML language. They also
differed in support for JavaScript code and the Document Object Model (DOM).
As a result, developers had to invent ways to ensure their Web pages had a uniform appearance across browsers. Techniques for this included
pixel-level positioning of images and text using tables, browser-specific
client and server code, programming hacks that took advantage of
features or bugs in the browser code, and more.
Around 2003, a convergence of standards and browsers that supported
those standards started to appear. Starting in 1998, the W3C released Web standards to provide specifications and guidelines intended to bring developers and browser implementations together. Many browsers, such as Netscape 4 and Internet Explorer 5, started to implement portions of the W3C Web standards. But the present-day level of standards-compliant browsers wasn't reached until about 2003, with the release of Mozilla®, Netscape 6, Internet Explorer 6, Opera 7, and Firefox. While none of these browsers perfectly and fully supports the W3C standards, each is close enough to allow developers to code based on the broad standards, instead of browser-specific
implementations.
The Web standards in use today address the three aspects of a Web page:
structure, presentation, and behavior. A quality aspect, accessibility, is also
addressed by new guidelines and legal requirements. I'll discuss each
of these in the sections that follow.
Structure: XHTML
HTML is the original Web page markup language. In present-day
Web standards it has been replaced by XHTML. With the growing acceptance
of XML, the W3C reformulated HTML to be XML-compliant. The result is
XHTML 1.0, which is based on HTML 4.0. One advantage of using XHTML is
that older browsers that support HTML documents can read and properly
process XHTML documents. Furthermore, since XHTML is XML-compliant, an
XHTML document cannot have missing tags or incorrectly closed elements
-- a problem of many HTML documents.
The Web standards for XHTML define a new mission for the Web page
markup language. In XHTML, the markup language is meant to convey
content and structure only -- headings, paragraphs, numbered
lists, definition lists, and so forth. Presentation aspects have been
moved to CSS. An example of this change is the deprecation of the HTML
<FONT> tag, among other
presentation-specific tags.
Presentation: CSS
The W3C Web standards define two levels of Cascading Style
Sheet (CSS) standards -- CSS1 and CSS2. A CSS3 standard is
under development at the time of this writing. The CSS
standards define a presentation language for specifying the format of a Web
page -- typography, placement, layout, color, and so forth.
CSS allows site designers to place the specifications of presentation and
formatting in a separate document from the Web page XHTML
document. This allows for reuse and reduces the amount of text that must be
downloaded with each Web page. Most standards-compliant browsers provide some
level of cache support for CSS documents. This also provides flexibility to
change one without affecting the other. For example, if several Web pages share
the same CSS document, then a change to that CSS document will be reflected by
all pages using that stylesheet.
Behavior: ECMAScript and DOM
The third aspect addressed by the Web standards is behavior, which is
specified using the DOM and ECMAScript. The Document Object Model
(DOM) specifies the representation of Web pages and related browser
objects so they can be accessed and manipulated by an ECMAScript
program. ECMAScript, which is a standardized version of the JavaScript language,
reduces the incompatibilities of the older browser scripting
languages such as Netscape's JavaScript and Microsoft's Jscript. With
the DOM and ECMAScript, a Web developer can add sophisticated behaviors
and processing that enhance the Web experience for users. For
example, you can perform field validation on a Web form at the browser rather than on the server.
Accessibility: WAI and Section 508
A quality aspect of Web pages has also been standardized through a set of
guidelines and requirements. The W3C established a set of guidelines to
improve the accessibility of a Web site through the Web Accessibility
Initiative (WAI). The US Government established a set of requirements for
accessibility of Web sites through Section 508 of the US Code. Many
other countries have passed similar accessibility requirements and
guidelines into their respective laws.
The purpose of the accessibility guidelines is to ensure people with disabilities can use Web pages. An interesting side-effect of designing accessible pages is that the pages are more adaptable to mobile
devices such as PDAs, cellular phones, among others.
Relax appearance requirements
In addition to backward compatibility requirements, the
SHEEP team's architect noted that the site was bogged down
with code to enforce its appearance across different browsers.
This is another example of older ideas in Web site design causing problems today.
For a variety of reasons, early Web designers and site sponsors
insisted that their sites appear identical across all browsers. This
insistence went beyond ensuring a similar appearance and page
readability. It called for pixel-identical positioning of elements and
identical font sizes on every page in every browser. Many hours and
weeks of developer time were spent tweaking Web pages to ensure this
identical appearance.
The question you should ask yourself today is why. What is the
advantage of having pixel-identical appearances of Web sites across
browsers?
Do users benefit from identical appearance? Not really.
Most users are loyal to a single browser, so they'll only see your site one
way, anyway. It doesn't matter to them how the site looks using other browsers.
Does identical appearance maintain the company brand? Not
especially. A company's brand is established through a combination of styles,
colors, use of trademarks and logos, and presentation. A company often alters
the appearance of its brand or trademark logos to suit the product. For
example, IBM's well known logo comes in a variety of forms -- single color eight
line, single color 13 line, three color eight line (as seen on many Thinkpads),
icon symbol (with the eye and bee icons), and so on.
It's sufficient to aim for close-enough uniformity across browsers.
And, one advantage of using the W3C Web standards is that standards-compliant
browsers will show the pages fairly consistently anyway. Using the standards,
you can get close enough to a uniform appearance with a minimum of coding,
thus, you greatly reduce the amount of code that you maintain.
Benefits of Web standards
Space limitations do not allow me to demonstrate everything the SHEEP
team must do to reform the sales site using the W3C Web standards.
You'll find some articles and books in Resources
that address migration to Web standards. When simply considering quality
aspects for a Web site, however, migrating to Web standards and relaxing a
site's appearance requirements can yield at least three improvements,
which I'll discuss now.
Easier maintenance
Listing 1 is a simplistic HTML example of a table-based navigation menu.
Listing 1. Simple HTML table-based navigation menu
<table border="0" align="center" cellpadding="0" cellspacing="0">
<tr valign="top">
<td width="100"><font color="blue" size="-1">Menu item 1</font></td>
<td width="100"><font color="blue" size="-1">Menu item 2</font></td>
<td width="100"><font color="blue" size="-1">Menu item 3</font></td>
</tr>
</table>
|
Now take a look at Listing 2, which illustrates the same navigation menu coded in XHTML, with the presentation moved to a separate CSS document. (I don't show the CSS.)
Listing 2. XHTML Web standards version of the navigation menu
<ul id="navigationMenu">
<li>Menu item 1</li>
<li>Menu item 2</li>
<li>Menu item 3</li>
</ul>
|
Clearly the Web-standards version involves less coding. Also note that
use of XHTML reduces problems caused by copy-and-paste editing of large blocks
of statements, such as copying an entire <td></td> clause.
Web standards definitely show a benefit for applications
that use templates (HTML fragments that are processed by the application to
build the final HTML sent to the browser). The simpler statements reduce the
chance that you forget to change a template when the HTML statements are
scattered over several template fragments.
Reduced bandwidth costs
Listing 1 and Listing 2 show that the Web standards
solution is smaller in text size. Some of the references listed below identify
a 50% to 60% reduction in Web size and bytes transmitted when migrating from
traditional HTML to a Web standards implementation. This reduction results from:
- Separation of presentation attributes from content so you only specify them once
- Elimination of spacer images and other filler constructs to achieve the desired layout
- Elimination of browser-specific coding
|
Did you know?
Even some large commercial sites have benefited from migrating to
Web standards. Two of the earliest pioneers in adopting Web standards
were ESPN and Wired.
|
|
Suppose a company used a Web hosting service that charged $1 per
month per 1 GB transmitted for the site. With traditional Web page
coding, the company transmits 100 GB per month, thus paying
$100 per month. After migrating to Web standards, the company reduces
the size of its Web site by 50%. For the same customer traffic, the
company only transmits 50 GB per month, for a $50 savings.
No more user lock-out
Another benefit of migrating to Web standards is the
elimination of browser-dependent code, and worse, user blocking. Some
Web sites today still support only a single browser, which is typically
Internet Explorer. Sadly, these sites block between 10% and 20% of their
potential audience.
Sites coded using Web standards are viewable on obsolete
and older browsers, as well as newer ones. While a site might not
look fantastic on an older browser -- more like early text-based sites
of the '90s -- the content is usable, readable, and accessible. It's
simply beneficial to make your site accessible to any user who wants
to use it, especially if it's an e-commerce site offering products
for sale!
In conclusion
Modernizing a Web site through the use of Web standards and
relaxing certain appearance requirements can yield significant reductions in
maintenance time, enhancement time, and bandwidth usage. A Web
standards-compliant site reduces the amount of data transmitted to the
browser, which results in decreased bandwidth usage. A modern site also
separates page content from presentation, which simplifies server
programming by reducing the work associated with content delivery. Using
Web standards like DOM and ECMAScript reduces the amount of browser-specific code you have to write and maintain. And, seeking close-enough appearance across browsers instead of identical appearance simplifies the formatting complexity of a Web site.
As a Web site developer, work with a site's
shareholders to determine which is more important: the appearance or the
functionality of the site. On another dimension, ask which is more important: the format and layout of the site or the ease of
making changes as needed. In most cases, you'll find that the
answers lead you to use Web standards and relax the site's
appearance requirements.
Resources Learn
-
Retrofit your Web pages for wireless compatibility (Brett
McLaughlin, developerWorks, November 2005): Make Web pages accessible to mobile
devices with standards like CSS and XHTML.
- XHTML:
The power of two languages (Sathyan Munirathinam, developerWorks,
July 2002): Explore this introduction to XHTML and learn how XHTML reformulates HTML 4.0.
- The Web's
future: XHTML 2.0 (Nicholas Chase, developerWorks, September 2002):
Stay in the know with this article on the changes in XHTML 2.0.
- Build quick, slick Web sites (Brett McLaughlin, developerWorks,
September 2005): Design fast-loading, responsive Web pages with XHTML.
- Designing with Web Standards
(Jeffrey Zeldman, New Riders Press, 2003): See the benefits of migrating to Web standards and look at an example Web-page conversion.
- Bulletproof Web Design:
Improving flexibility and protecting against worst-case scenarios with
XHTML and CSS (Dan Cederholm, New Riders Press, 2005): Improve the accessibility of a Web site with these
guidelines that use Web standards.
- Homepage Usability: 50
Websites Deconstructed (Jakob Nielsen and Marie Tahir, New Riders
Press, 2001): Delve into fifty case studies in Web page usability.
- Web
Standards Solutions: The Markup and Style Handbook (Dan Cederholm,
Friends of Ed, 2004): Sample and explore a cookbook of Web standards solutions.
- Rapid Web
development (James Lewin, developerWorks, September 2001): Create
flexible sites quickly using standards like CSS and XHTML.
- Reap the benefits of these standards in your Web programming:
- Web Content Accessibility Guidelines
Working Group: Check out these notes on the W3C accessibility guidelines.
-
Section 508: Read the United States accessibility standards.
- developerWorks Web architecture zone: Expand your Web-building skills with articles, tutorials, forums, and more that specialize in Web technologies.
- developerWorks Open source zone: Find extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
Discuss
About the author | 
| | Michael Russell has a Bachelors Degree in Physics and a Masters Degree in Computer Science. He was a logistics engineer, a technical services manager, and a certified IT architect at IBM for nearly 14 years; he is currently a Web application architect for a resort company in Orlando, Florida. He has experience in Windows, UNIX, and OS/400 environments and uses Web technology for entertainment through his own company, Vicki Fox Productions. He can be reached at MikeRussell@VickiFox.com. |
Rate this page
| |
