|
The Cross-Platform Browser Blues...
By Bruce Stewart,
Web Tools
(03/08/00)
As Web designers we've all experienced
our Web pages looking good in either Netscape Navigator or Internet
Explorer, but then degrading from their intended design when viewed in the
other browser. Some of us may have designed or maintain sites that serve
different versions of pages to the two main browsers. It's enough to make
you want to cry "can't we all just get along?"
While the trend is moving away from the
illogical practice of designing separate pages for different browsers, it
isn't happening fast enough for many. The
W3C
-- The World Wide Web Consortium issues Web standards, but so far the
browser makers selectively and incompletely implement them. If we ever see
Netscape's 5.0 offering, it's supposed to be the first totally
standards-compliant browser. Frankly, we'll believe it when we see it.
We'll also hope that Microsoft hasn't completely won the browser-wars by
the time it's released. At this rate it's hard to tell.
In the meantime, here's some of the
nitty-gritty, not-always-pretty details of how the two major browser
platforms differ in their implementations of HTML. If you take some time
to understand some of the basic differences between Navigator and IE, you
can considerably minimize those unhappy experiences when first viewing
your designs in the other browser.
Screen Size
Even something as simple as screen size,
or the "real estate" that you have to work with as a Web
designer, doesn't conform to any standards. Of course there are the issues
surrounding how your content looks at different resolutions as well, and
this should be taken into account in your testing methods.
| Other Browsers, Other Platforms
It's not that hard to play to the lowest common denominator
when it comes to page or screen size, if you're primarily
concerned with the two standard desktop computer browsers. But it
becomes much messier when you start figuring in other options
(Opera, Lynx, AOL, etc.), non-Windows platforms (Mac, Linux, etc),
all the potential PDA and non-desktops (WebTV, handhelds, phones,
etc.). If you're designing for those environments (and we should
all be at least thinking about them), be aware that you will have
further constraints on your design space.
|
Canvas Sizes
Some basic things to keep in mind about
your screen size are that there are different "canvas sizes,"
the actual size of the available workspace; and "page offsets,"
horizontal and vertical buffers from the edges of the workspace.
Canvas sizes range from 723x438 for the
Macintosh version of IE 4.5, to 764x414 for the Windows versions of
Navigator above 4.0 (at 800x600 screen resolution obviously). To fit into
the smallest possible canvas of any of the major browsers, at 800x600 you
should be staying within a 723x390 window.
Page Offsets
Page offsets are the number of pixels
away from the edge of the browser window your page will start. On all
Macintosh platforms horizontal and vertical offsets are 8 pixels, on all
Windows platforms the horizontal offset is 10 pixels, except Navigator 4
where it is 8 pixels. Windows vertical offsets are most commonly 15
pixels, except in Navigator 4 where it is 8 pixels and IE 3 where it is 16
pixels.
These measurements are courtesy of a
Webmonkey
article by Steve Mulder and Michael Brandt examining spatial
differences in the major browsers. They also make the important point that
the very commonly installed MS Office toolbar will eat up even more of
that precious workspace.
Tables
Tables are one of the oldest and most
widely implemented HTML features. Just about any browser (excepting AOL
2.7 and below) will display tables and understand their basic tag
structure. Unfortunately, tables are not uniformly supported by IE and
Navigator.
For instance, the <TABLE> attribute
<BORDERCOLOR> was first supported in IE 3.0, but Netscape didn't
start recognizing it until its 4.0 version. And if you have a non-zero
<CELLSPACING> attribute in a table with a <BORDERCOLOR>,
Netscape will retain the 3-D feel of the table and not color any of the
internal lines, whereas IE will change the outside lines to solid borders
of the requested color, and color the internal border lines as well.
Navigator has long been criticized for
problems rendering nested tables, which are coded in a strictly legal
manner. Any use of nested tables needs to be tested carefully in
Navigator.
Specifically, Netscape has had problems
with tables that omit the optional end </TD> tag. IE handles this
legal omission gracefully, but if you're using nested tables and have
potential Netscape users, you better make sure you close every <TD>
tag. Navigator also has problems with carriage returns directly following
table cell data, and if there was a hard return in the HTML file before
the ending </TD> tag of a table cell, additional space would be
added around the cell. This can play havoc with your design if you're
using tables for page layout purposes.
Netscape tends to be pickier than IE when
it comes to handling improperly coded HTML as well. For instance, if you
have a table that's missing the required end </TABLE> tag, IE will
still display the table, but Navigator won't.
Another important aspect of Netscape's
table rendering, relating to Cascading Style Sheets (CSS), is that table
elements will not inherit formatting instructions from parent elements.
So, if you specify text style attributes in a style sheet BODY or DIV
section, they will not be used by text within a table cell within that DIV
section.
Frames
Frames are another staple of Web
developers, which are widely supported. You have to go back to the Windows
2.0 version of IE to find a major browser that doesn't support them. Early
versions of WebTV did not support frames, but one of the advantages of
that technology is the automatic forced-upgrades of the clients, and there
shouldn't be any non-frames versions of WebTV in use anymore.
Some differences in the implementations
of frames are the differences in how you specify borders and the IE-only
<IFRAME> tag for inline frames. To toggle frame borders you need to
specify <FRAMEBORDER = 0> or 1 for IE, but Netscape originally used
<FRAMEBORDER = Yes> or No (although it currently supports the 0/1
usage as well). To set the thickness of borders within a frameset you need
to use the BORDER attribute for Netscape, but the <FRAMESPACING>
attribute for IE.
With regards to pre-formatted text, while
both browsers support the <PRE> tag, only Netscape supports a
<COLS> attribute that specifies the number of columns and a
<WRAP> attribute that indicates that the text should be wrapped at
that width.
If you're working with legal documents,
or multiple revisions, you should know Netscape does not recognize the
<INS> and <DEL> tags. IE will recognize these elements, and
renders the contents of <DEL> elements as struck-through text and
<INS> elements as underlined text (easily confused with hyperlinks).
JavaScript And CSS
JavaScript provides the power behind
DHTML, and offers some of the most useful functionality on the Web today.
Like everything else in this medium, its implementation has been varied
and inconsistent between the browsers.
Implementations of JavaScript 1.0 were
notoriously buggy, and first appeared in Navigator 2.0 and IE 3.0. A more
stable and functional version of JavaScript is 1.1, which became supported
in Navigator 3.0. Both IE 5 and Navigator 4.7 now support JavaScript 1.3 (ECMA).
A common technique when writing
JavaScript is to put the version number in the SCRIPT tag, to separate
code for different versions of browsers. One Navigator 3.0 bug will cause
it to evaluate code within a <SCRIPT
language="JavaScript1.2"> tag, when it should rightfully
ignore that and leave it for only 4.0 versions and above. To get around
this you must put JavaScript 1.2 specific code within an explicit
JavaScript version check.
The basic problem with JavaScript is that
Navigator and IE support different document object models (DOMs). The DOM
is what specifies which elements of a page are accessible for manipulation
with scripting languages like JavaScript. This has been one of the big
reasons developers have had to write different code for the different
browsers -- to incorporate each browser's DOM.
A good way to try and work around this,
and to keep from having to serve separate pages for IE and Navigator, is
to define reference variables that will hold the appropriate syntax for
whichever browser is being used. In other words, if the user has Netscape,
assign the variable the Netscape version of the object, and if the user
has IE give it the IE version. Then use your reference variable in the
script, rather than the Netscape or IE specific syntax.
Here's an IE gotcha: The browser can't
handle mixed-case event handlers when used as an object property, so it is
best to use only lowercase event handler names. For example, use "onclick"
instead of "onClick."
Another important Navigator quirk
suggests it would be best to always use only alphanumeric characters when
choosing element names. Reportedly some element names with
non-alphanumeric characters can be ignored by 4.0 versions of Navigator.
Some other things to keep in mind while
coding. Cascading Style Sheets are not supported in Windows Navigator 3.0,
and poorly supported in IE 3.0 (Windows and Macintosh). But looking ahead,
it's probably a good idea to use CSS-P for positioning elements, as it's a
W3C standard supported by both IE 4.0 and Navigator 4.0. Stop using the
Navigator LAYER tag, it won't even be supported by Navigator 5.0, let
alone IE.
An important difference in CSS
implementations is that Navigator does not support changing CSS attributes
of an element after the element has been displayed. Navigator and IE also
support different techniques for changing positioning attributes. With
Navigator you set and access the attributes directly from the element, but
with IE you must do this from each element's style object.
Netscape will act unpredictably if you
attempt the technique of using negative numbers for margin values in your
style sheets, to create overlaps. Also in Netscape, applying styles to LI
elements will result in only the associated bullet getting the desired
style, not the following text.
One last Netscape style issue. If your
styles use the LINE-HEIGHT property, and have it set in points, you may
experience problems printing your pages. If you use ems, pixels, or inches
you should avoid this problem.
Cross-Platform Testing
Try to think of cross-platform testing as
a requirement, not an option. Test until you cannot test anymore. At a
minimum try and look at every page in Windows versions of IE 3.0, 4.0 and
5.0, which all have differing levels of support for JavaScript and CSS,
and Windows versions of Navigator 3.0, 4.0, and 4.7, which also all differ
in JavaScript support.
On the Macintosh side, you should be
looking at least at IE 3 and 4 and Navigator 3.0, 4.0, and 4.7. If you
want an unpleasant surprise, try looking at your pages in 2.0 versions of
the browsers. The Windows version of IE 2.0 doesn't even support frames.
Of course, the difficulty comes in having
all these browser versions available for testing with. As you're probably
aware you cannot easily install two different versions of IE on a Windows
computer. So, this leaves you with either setting up a multi-boot system,
or dedicating several systems to just be able to test the Windows IE
permutations.
There's no easy way around needing
multiple configurations to seriously check your work. If you're low on
resources you can try enlisting friends with different systems to help,
but this can sometimes end up being more trouble than it's worth.
It can also be a trick just tracking down
some of these older browser versions. Here's a link to a repository of
older
versions of Netscape browsers. IE versions back to 2.0 can be
retrieved from
Microsoft's
main download site.
An important step in your testing
procedure should involve running your code through an HTML validator, like
Bobby or the
W3C
HTML Validation Service. These services will check your HTML code for
errors, and point out any discrepancies between your code and the HTML
standard. Bobby will also highlight compatibility issues with the various
browsers and help you make sure your pages are as accessible as possible.
Another platform you should probably not
ignore is WebTV, and other emerging set-top devices. WebTV has produced a
convenient emulator that can be downloaded from its site, so you can test
your pages without having to actually have a WebTV account and box. It
offers both Macintosh and PC versions of its
WebTV
Viewer software for free.
We haven't even discussed any of the
other popular desktop browsers like Opera, iCab, or Lynx. Of course it is
a good idea to test your pages on these browsers as well. In addition to
testing in every browser/OS platform combination you can, you should also
be testing your pages at a variety of screen resolutions. Obviously, you
have to consider your audience at this point, but you should know there
are still people out there browsing at 640x480.
Keep in mind that Mac's screen resolution
display type at 72 dpi and PC's display type at 96 dpi. This means type
will look bigger on the PC platform, and is one reason to make sure to
test cross-platform with regards to operating systems, not just browsers.
More Resources
For the lowdown on the current state of
Web standards, visit both the
W3C
-- The World Wide Web Consortium, and the
Web
Standards Project.
There's a good
browser
compatibility chart over at Web Review. If you want to know if WebTV
supports CSS, or if the Windows version of AOL 3.0 supports animated GIFs,
this is the place. They also provide an
extensive
chart detailing CSS implementations in the current browsers.
For an interesting look at transitioning
from proprietary DOMs and markup to W3C Standards, check out
this
Netscape page. There's lots of information there on what exactly won't
be supported by Navigator 5.0, such as the LAYER tags and the SRC
attribute of the DIV tag.
Navigator 5.0 is supposed to feature full
support for HTML 4.0, CSS1, XML, RDF, DOM level 1, and the "DOM level
0" (which means the JavaScript DOM features supported by both
Navigator 3.0 and Internet Explorer 3.0).
Perhaps we can all look forward to a day
when we can design our pages to one set of standards, and not get any
surprises when we first look at them in that other browser.
Bruce
Stewart is a telecommunications consultant and technical writer. His
articles have appeared on The Site, Web Review, and ZDNet.
Related Links:
Web Tools
by CMP.NET
Internet Development
Resources & Links!
|
