 | ||
|
| ||
| ||
|
| ||
Robert Hess
Developer Relations Group
Microsoft Corporation
January 23, 1998
The following article was originally published in the Site Builder Magazine (now known as MSDN Online Voices) "More or Hess" column.
One of the most common issues that comes up for people doing Web page design is how to code the page so that it is compatible with various browsers. Often, this might arise with new Web authors who spend hours and hours working up a cool page. It looks stunning in one browser, and then they check it out in some other browser -- only to see a page that is almost unreadable. They are then faced with the challenge of trying to figure out which HTML elements and attributes are compatible with which browsers, and at what level.
In previous columns, I've talked about managing compatibility issues with tricky scripting or database methods -- or even building up different versions of a site for the various browsers that will likely be used to view it. But in truth, the more work you have to do to add compatibility to your site, the less likely you are to do it.
As a starting point, keep in mind that there is no such thing as total browser compatibility with any HTML element.
There, I've said it. It's off my chest, and I feel better for it.
What I mean is that the HTML specification only loosely identifies what any browser might do when rendering a page. Let's take the recently finalized HTML 4.0 specification 
. Here is what the specification says about paragraph rendering:
9.3.5 Visual rendering of paragraphsHow paragraphs are rendered visually depends on the user agent. Paragraphs are usually rendered flush left with a ragged right margin. Other defaults are appropriate for right-to-left scripts.
Note the terms "depends on the user agent" (just another way of saying browser) and "usually rendered." Like other aspects of the specification, this provides a lot of leniency to companies that develop browsers. If you are looking for pixel-level compatibility of your page from one browser to another, you are probably being a little too picky.
The first lesson we've learned is that we should be able to accept minor differences in page rendering from one browser to another.
Now, how about plain support for a particular HTML element?
The important thing to remember here is that two forces are at work. One is the World Wide Web Consortium (W3C), the standards body that is working up the HTML standards the various Web browsers will follow. The other is the array of browsers being developed by various companies trying to provide timely solutions to their users while they wait for the W3C. This means that often a new element might be supported in a browser before it is finalized by the W3C. It's how we got such cutting-edge elements as BLINK and MARQUEE. Okay, okay -- it's also how support was gained for really exciting features, such as table cell background colors and the FONT element.
All of this results in a rather complex soup of elements and attributes that the beginning Web author needs to track to understand support issues. Starting at HTML 2.0 might be a good thing to do. Fortunately, going back that far may not be necessary. The HTML 3.2 specification was designed to quantify not what new browsers should aim for, but what most existing browsers already support.
Our second lesson is that we need to have a solid familiarity with the supported elements and attributes of HTML 3.2 in order to have a "lowest common denominator" that we can utilize across all (most) browsers.
What if we want to push the envelope a little? What if we want to utilize some of the advanced tags that aren't in HTML 3.2, such as STYLE, SCRIPT, or FRAMESET? Sometimes those and other advanced elements might have various problems being rendered on other browsers. Sometimes they aren't recognized at all; other times, browsers might recognize them, but take slightly different spins on rendering.
My suggestion is to go slowly. Work up a simple page layout as a template, and try it on the various browsers you are expecting to be used. See how the rendering differs. Rather than try for an identical look in all browsers, keep our first lesson in mind, and simply ask yourself whether the rendering looks good. For example, the following code will render differently between Microsoft Internet Explorer and Netscape Navigator:
<table border=1 bordercolor=gray bgcolor=black cellpadding=6> <td bgcolor=red>Red</td> <td bgcolor=green>Green</td> <td bgcolor=blue>Blue</td> </table>
Internet Explorer supports the BGCOLOR=BLACK for the TABLE definition, but Navigator doesn't. (Both browsers now support BGCOLOR in the TD definition.) My original version of this code didn't turn on the border for the table -- but after looking at it in Navigator, I decided I needed some sort of framing element to make up for the missing black background. I added the border, and then looked at the page again in both browsers. Still not exactly the same, but the resulting design worked properly regardless of the browser.
Our final lesson is that we may need to do some testing and modification to resolve rendering issues unique to our design. We also need to focus on achieving pages that are functional in each browser, and not necessarily compatible.
To stay current on all Web standards, check Microsoft's Specs & Standards page, where you can find complete specifications (some downloadable in Word DOC format), a comprehensive list of standards supported in Internet Explorer 4.0, and complete working drafts now before the W3C.
Where to check
Where ARE standards?
For technical how-to questions, check in with the Web Men Talking, MSDN Online's answer pair.
Did you find this material useful? Gripes? Compliments? Suggestions for other articles? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top