The Importance of Browser Specs
This document attempts to explain why forward-compatibility matters, and why we, and our clients, should carefully consider the browser specifications of every project.
Note: This document was updated in July of 2004. The biggest change is in our browser terminology. The old scheme of “Modern” and “Legacy” has been replaced with “Modern,” “Outdated” and “Obsolete.”
Terminology
Before we proceed, we want to be clear on our definitions:
Modern Browsers:
Any browser that has robust support for web standards, even if it’s not 100%.
Examples: IE 6/PC, Netscape 7/PC & Mac, Mozilla 1+/PC & Mac (incl. Firefox), Safari 1+/Mac
Outdated Browsers:
3-4 year old browsers with middling support for web standards.
Examples: IE 5+/PC & Mac, Netscape 6/PC & Mac
Obsolete Browsers:
4+ year old browsers that do not support web standards.
Examples: IE 4/PC & Mac, Netscape 4/PC & Mac
Outdated Browsers?
The outdated browsers were the first attempts at building towards a cohesive web, with one set of rules. These browsers didn’t fully meet the goal, but evolution isn’t a one step process.
Outdated browsers, such as Netscape 6 and IE 5, came out at a time when it was becoming clear that the browser wars were being won by Microsoft, and NS 4 was quickly becoming obsolete. Somehow the WaSP (http://www.webstandards.org/) convinced Microsoft that standards were important to them, and we started to see browsers with the beginnings of acceptable support. The first browser with any significant support was IE 5 for Mac. (It’s funny to think back on that, seeing as IE Mac is usually the buggiest browser we currently develop for.)
What’s the problem?
The problem is (mostly) with the obsolete browsers. They were built during the Web’s formative years, before the technologies in question were fully developed. As a result, they ended up with incompatible support for the same technologies. Both Netscape and Microsoft tried to gain the upper hand by creating proprietary ways of developing content for the Web, which meant that developers had to bend over backward, to put it mildly, to get sites to work in both.
The outdated browsers marked the first attempts to support the standards proposed by the World Wide Web Consortium (http://www.w3.org), and the advent of modern, standards-supporting browsers took us to the next level. Modern browsers do a very nice job (albeit imperfectly), and developers who write standards-compliant HTML, XHTML, CSS and JavaScript can expect modern browsers to interpret them the same way. (The grain of salt here is that every piece of software has bugs, and CSS rendering bugs can become quite painful at times — but we wouldn’t trade them.)
Standards Mean Simplicity
Historically, client-side engineers have had to dedicate a large portion of their development time to writing redundant code to accommodate multiple browsers; quality assurance testers have had to dedicate massive amounts time to testing both design and functional issues in multiple browsers. Adopting standards and setting high browser specs can help reduce this time.
An example:
Home
News
About
To build the above example for obsolete browsers requires the following HTML:
<table cellpadding="0" cellspacing="0">
<tr height="1">
<td width="177" colspan="7" bgcolor="#cccccc">
<img src="spacer.gif" width="177" height="1" alt="">
</td>
</tr>
<tr>
<td width="1" bgcolor="#cccccc">
<img src="spacer.gif" width="1" alt="">
</td>
<td bgcolor="#eeeeee">
<img src="spacer.gif" height="5" width="1" alt="">
</td>
<td width="1" bgcolor="#cccccc">
<img src="spacer.gif" height="5" width="1" alt="">
</td>
<td bgcolor="#eeeeee">
<img src="spacer.gif" height="5" width="1" alt="">
</td>
<td width="1" bgcolor="#cccccc">
<img src="spacer.gif" height="5" width="1" alt="">
</td>
<td bgcolor="#eeeeee">
<img src="spacer.gif" height="5" width="1" alt="">
</td>
<td width="1" bgcolor="#cccccc">
<img src="spacer.gif" height="5" width="1" alt="">
</td>
</tr>
<tr valign="middle">
<td width="1" bgcolor="#cccccc">
<img src="spacer.gif" height="1" width="1" alt="">
</td>
<td align="center" bgcolor="#eeeeee" style="font: bold 12px arial;">
Home
</td>
<td width=”1″ bgcolor=”#cccccc”>
<img src=”spacer.gif” height=”1″ width=”1″ alt=”">
</td>
<td align=”center” bgcolor=”#eeeeee” style=”font: bold 12px arial;”>
News
</td>
<td width=”1″ bgcolor=”#cccccc”>
<img src=”spacer.gif” height=”1″ width=”1″ alt=”">
</td>
<td align=”center” bgcolor=”#eeeeee” style=”font: bold 12px arial;”>
About
</td>
<td width=”1″ bgcolor=”#cccccc”>
<img src=”spacer.gif” height=”1″ width=”1″ alt=”">
</td>
</tr>
<tr>
<td width=”1″ bgcolor=”#cccccc”>
<img src=”spacer.gif” width=”1″ alt=”">
</td>
<td bgcolor=”#eeeeee”>
<img src=”spacer.gif” height=”5″ width=”1″ alt=”">
</td>
<td width=”1″ bgcolor=”#cccccc”>
<img src=”spacer.gif” height=”5″ width=”1″ alt=”">
</td>
<td bgcolor=”#eeeeee”>
<img src=”spacer.gif” height=”5″ width=”1″ alt=”">
</td>
<td bgcolor=”#cccccc”>
<img src=”spacer.gif” height=”5″ width=”1″ alt=”">
</td>
<td align=”center” bgcolor=”#eeeeee”>
<img src=”spacer.gif” height=”5″ width=”1″ alt=”">
</td>
<td bgcolor=”#cccccc”>
<img src=”spacer.gif” height=”5″ width=”1″ alt=”">
</td>
</tr>
<tr height=”1″>
<td width=”177″ colspan=”7″ bgcolor=”#cccccc”>
<img src=”spacer.gif” width=”177″ height=”1″ alt=”">
</td>
</tr>
</table>
That’s not an exaggeration.
To build it for modern browsers requires this:
<div class="nav">Home</div> <div class=”nav”>News</div> <div class=”nav”>About</div>
With accompanying CSS:
div.nav {
float: left;
width: 50px;
border: 1px solid #ccc;
background: #eee;
font: bold 12px arial;
color: #000;
padding: 3px;
text-align: center;
}
Even to the non-technically-minded, the difference is obvious. Specific benefits of the second example are:
- Separation of content from style and structure
The code is easier to read, modify and integrate with server-side languages. - Consolidation of design rules
Changes to border colors, for example, only need to be made in one place. - Forward-compatibility
Future browsers will interpret the second example correctly; there is no guarantee they will do the same for the first. - Efficiency
Less code means less development time.
Standards Mean Simplicity, Part 2
JavaScript is the tool that client-side engineers use to enable functionalities that increase usability, the best example being navigational elements. For example:
Home
News
About
Return to the main page.
Breaking updates.
Who we are.
[This demonstration is only effective when viewed in a modern or outdated browser. Rolling over each nav element reveals an additional bit of information below it.]
This is very easy to build using standards-compliant JavaScript, but obsolete browsers don’t understand it. Not only do they not understand the standard method, they don’t even understand the same method. To achieve the same functionality for a project that must support obsolete browsers, an engineer has to write scripts for IE 4, Netscape 4 and the modern browsers. It will take twice as long to develop three variations, when one should suffice.
When in the project time line should we determine browser specs?
As soon as possible. I say again: As soon as possible.
Browser specs affect graphic design, they affect information architecture, they determine the client-side functionalities we can offer. They affect the budget and the timeline of the project.
Higher specs mean client-side engineers can code HTML, XHTML, CSS and JavaScript that meets standards, and — as demonstrated above — we can code less of it.
The Effect on Development
When you consider developing for obsolete browsers, keep in mind:
- Your designers will be working within the limited capabilities of the obsolete browsers, and will not have the depth of control that modern browsers offer.
- The time required for client-side development will increase by a factor of two, at least.
- Back-end integration will take longer as your server-side engineers wade through complex and redundant client-side code.
- Maintenance will require knowledge of client-side technologies; expansions will require intimate knowledge of the site’s code structure.
Conversely, if you focus on modern browsers:
- DHTML functionalities are at your disposal to increase usability.
- Front-end development time will likely decrease.
- Back-end integration time can decrease.
- Some maintenance can be done by non-technical staff; the code structure will be intuitive and will lead to easier expansion of the site.
- The client-side code will never become obsolete.
- Accessibility* becomes a reality.
* In this context, ‘accessibility’ refers to enabling the use of display devices such as text readers, braille devices, televisions, projectors, printers, etc. This is important because Section 508 of the Workforce Investment Act of 1998 requires all United States federal agencies with web sites to make them accessible to individuals with disabilities.
How do we determine browser specs?
Well, we could do what we’ve done for years now, and focus our efforts on the most widely used browsers. Historically this has been IE and Netscape, and in the Web’s most formative years it was the version 4 releases of both. As of this writing, the top 5 browsers are*:
- Internet Explorer 6 (modern — 78%)
- Internet Explorer 5 (outdated — 16%)
- Mozilla (modern — 2%)
- Netscape 7 (modern — 1%)
- Safari (modern — 1%)
* All Web usage and browser statistics are approximate. The “Unknown” data was disregarded. Data gathered from The Counter’s July 2004 stats (http://www.thecounter.com/stats/2004/July/browser.php).
As you can see, modern browsers have taken a firm hold on the market. None of the obsolete browsers show up in the top 5, and only one outdated browser is hanging on.
Setting Low Specs
If your client is leaning toward supporting obsolete browsers, does it make sense considering the client-side features the client wants us to provide? Why are they leaning in that direction? Do they have a large percentage of low-end users? If so, why? Would those users be likely to upgrade, if shown that it is a painless process? Answering these questions can impact the overall requirements of a project.
If we determine that we must support older browsers, it doesn’t mean a nightmare. If it’s right for the client, we do it, we just need to do it diligently.
As we decide functional requirements for these projects, it is very important to keep our client-side engineers in the loop. They will be able to tell us which functionalities will be available to us, and how long they will take to build. We can then decide if this fits within the scope of the project. These decisions, obviously, impact every aspect of the project — information architecture, graphic design, back-end development, etc.
Setting High Specs
Higher specs, as we have hopefully demonstrated, means more opportunity for client-side functionality, forward-compatibility for future browsers and a more client-friendly final product.
But what about the minority that don’t have a modern browser? They don’t have to be completely cut out.
In our experience, users don’t upgrade for three reasons:
- They don’t know how.
- They don’t know they should.
- They don’t want to.
While we can’t do much for the third group (fortunately they are rare), we can teach the other two groups the hows and whys of upgrading.
Users don’t always understand they have choices when upgrading. Just because IE has almost 90% of the market does not mean they have to use it. The latest versions of Netscape and Mozilla are still free, and are IE’s equal (superior, actually) in terms of rendering Web sites.
All we need them to do is upgrade once — to a browser that future standards will support, even if they hang on to it for another 5 years.
To Summarize…
When approaching browser specifications for our projects, we need to ask our clients if supporting older browsers is worth the extra time and money it will mean for development and maintenance. Is it worth the decrease in usability and functionality that older browsers require? Are clients ready to sacrifice forward-compatibility for more expensive backward-compatibility?
The outdated browsers are approaching 5 years old. That’s an eternity in Web years. Internet consulting firms are trying to help their clients build smart Web sites that maximize customer relationships, yet they are struggling with inefficient, legacy-based site-building techniques that often end up delivering unmanageable behemoths.
For the past four years, we have been developing the processes required to take Web sites to new levels of design, usability and functionality. Standards-compliant sites are easier to build, maintain and expand. Standards-based techniques increase usability, increase the options for client-side functionality, and even decrease download time for the user.
If business requirements allow it, we recommend the development of a standards-based site that modern and future browsers will support. This frees us to build user- and client-friendly sites with more features in less time.