when various browsers were created, their approximate
share of the market, and the major problems they cause. However, it’s important to
note that the market is in continual change—just a quick look at Netscape’s fortunes
should be enough to prove that. Utterly dominant during the period when the Web first
started to become mainstream, its share of the market was decimated by the then-upstart
Internet Explorer, and it’s now all but vanished. The point, of course, is that you cannot
predict how the browser market will change, and although Internet Explorer is sitting
proud today, its share of the market has been hit hard in recent years by Firefox, and this
downward trend for Microsoft’s browser could continue . . . or not. Also, each year sees
new releases of web browsers, with new features and updated—but usually incomplete—
standards support.
All of this is a roundabout way of saying that you need to think hard about browsers when
you’re creating your work. Don’t only test sites in a single browser, and don’t use the most
popular for your starting point if it’s not the most standards-compliant. Instead, use a
browser with a good grasp of web standards for your first line of tests, until you’ve got
your templates working. I personally use the Gecko engine as a starting point—more
specifically, I favor Firefox as an initial choice of browser. Opera is also a decent choice,
and Mac users can probably get away with using Safari for initial tests.
Once the basic structure is up and running, I test in a range of alternate web browsers, typically
in the following order:
share of the market, and the major problems they cause. However, it’s important to
note that the market is in continual change—just a quick look at Netscape’s fortunes
should be enough to prove that. Utterly dominant during the period when the Web first
started to become mainstream, its share of the market was decimated by the then-upstart
Internet Explorer, and it’s now all but vanished. The point, of course, is that you cannot
predict how the browser market will change, and although Internet Explorer is sitting
proud today, its share of the market has been hit hard in recent years by Firefox, and this
downward trend for Microsoft’s browser could continue . . . or not. Also, each year sees
new releases of web browsers, with new features and updated—but usually incomplete—
standards support.
All of this is a roundabout way of saying that you need to think hard about browsers when
you’re creating your work. Don’t only test sites in a single browser, and don’t use the most
popular for your starting point if it’s not the most standards-compliant. Instead, use a
browser with a good grasp of web standards for your first line of tests, until you’ve got
your templates working. I personally use the Gecko engine as a starting point—more
specifically, I favor Firefox as an initial choice of browser. Opera is also a decent choice,
and Mac users can probably get away with using Safari for initial tests.
Once the basic structure is up and running, I test in a range of alternate web browsers, typically
in the following order:
1. The other compliant browsers: Typically, I use Firefox as a starting point, although
sometimes I use Safari. Whichever one you choose to start in, it’s a good idea to
test in the other compliant browsers first. Sometimes, one will pick up a coding
error the others don’t, and it’s a good sanity check to ensure everything’s working
well. If you’re lucky, everything will work fine right away in all of these browsers, on
both Mac and Windows.
2. A browser in text mode: What I mean by this is testing the site without CSS, which
is a way of somewhat figuring out if it’s usable on alternate devices. Old hands
might use Lynx for this, but I instead use the Accessibility layout option of Opera’s
User mode (see the following screenshot). The Firefox Web Developer toolbar
(www.chrispederick.com) offers similar options.
3. Internet Explorer 7 for Windows: Although this release of Internet Explorer is a vast
improvement over previous efforts, it’s not as standards-compliant as the other
mainstream browsers. Therefore, tests need to be done to ensure everything’s
working properly, not least because Internet Explorer 7 is the most popular
browser in terms of market share. If things aren’t working right, conditional comments
need to be used (see the “Dealing with Internet Explorer bugs” section later
in the chapter).
4. Internet Explorer 6 for Windows: Previously the most popular browser, this release
is still in heavy use. Fairly compliant, it nonetheless has a raft of bugs, and complex
CSS layouts will almost certainly need a little tweaking to work properly, again via
the use of conditional comments. Note that because only Windows XP users can
upgrade from Internet Explorer 6 to 7 (7 being the native browser for Windows
Vista), a fair number of users—those with an earlier version of Windows—will likely
use 6 for some time to come.
is still in heavy use. Fairly compliant, it nonetheless has a raft of bugs, and complex
CSS layouts will almost certainly need a little tweaking to work properly, again via
the use of conditional comments. Note that because only Windows XP users can
upgrade from Internet Explorer 6 to 7 (7 being the native browser for Windows
Vista), a fair number of users—those with an earlier version of Windows—will likely
use 6 for some time to come.
5. Internet Explorer 5.5 for Windows: How far you go back, in terms of versions of
Internet Explorer, depends on your target market, the client’s budget, and general
expectations. Typically, I test the most recent three major versions of Microsoft’s
browser, due to their heavy usage. Internet Explorer 5.0 can be considered almost
extinct, however. Overall, Internet Explorer 5.5 has more problems than Internet
Explorer 6, although most of them are easy enough to work around. Generally, I
don’t aim to get sites working perfectly in this browser—a few cosmetic oddities
are acceptable, in my opinion, because there’s no point in compromising a totally
compliant site to make it more compatible for an aging browser whose market
share is in rapid decline. Ensuring content is accessible in the browser is essential,
however, and the primary concern when dealing with obsolete browsers.
6. Everything—all over again: When any major changes are made, you need to go back
through your browsers and make sure the changes haven’t screwed anything up.
There are other browsers out there, but the preceding list will deal with the vast majority
of your users. However, always try to find out the potential audience for a website to
ascertain whether you should place more focus on a particular browser. For example, if
authoring a site for a mostly Mac-based audience, it might make sense to use Safari as the
basis for testing, and perhaps even wheel out the long-canceled Internet Explorer 5 for
Mac, just to make sure your site works in it.
At each stage of testing, I recommend that you save HTML and CSS milestones on a very
regular basis. If something fails in a browser, create a copy of your files and work on a fix.
Don’t continually overwrite files, because it’s sometimes useful—and, indeed, necessary—
to go back to previous versions.
Whichever browsers you test in, it’s important to not avoid the “other side.” Windows
users have long seen the Mac as being inconsequential, but at the time of writing Safari
now counts for about 4% of all web users, and the trend for Mac sales (as a percentage of
the market) is upward. Usefully, there’s now a version of Safari for Windows, but even the
Mac and Windows versions of Firefox show slight differences in the way sites are handled
(mostly regarding text). Even worse, many Mac-based designers don’t test on a Windows
PC or in Internet Explorer, which has the bulk of the market. If you’re a Windows user, grab
a cheap Mac that’s capable of running Mac OS X (such as a second-hand iBook or a Mac
mini), and if you’re a Mac user, either grab a cheap Windows PC to test with or run
Windows as a virtual machine (via Parallels Desktop or VMware Fusion) on an Intel Mac or
using Virtual PC if you have a PPC-based machine. (You can also use Boot Camp on an Intel
Mac, but that requires booting back and forth between Windows and Mac OS X, so using
a virtual environment is more efficient unless you have two computers.) Linux users also
have a range of browsers to test on. Firefox is popular on that platform, and Safari is a
rough analog for Konqueror. It is worth noting, however, that the default fonts with Linux
vary considerably from those that you’d expect on a Mac or Windows PC—so you should
always define fallback fonts accordingly, and test in Linux if possible. See Chapter 3 for
more on font stacks.
of your users. However, always try to find out the potential audience for a website to
ascertain whether you should place more focus on a particular browser. For example, if
authoring a site for a mostly Mac-based audience, it might make sense to use Safari as the
basis for testing, and perhaps even wheel out the long-canceled Internet Explorer 5 for
Mac, just to make sure your site works in it.
At each stage of testing, I recommend that you save HTML and CSS milestones on a very
regular basis. If something fails in a browser, create a copy of your files and work on a fix.
Don’t continually overwrite files, because it’s sometimes useful—and, indeed, necessary—
to go back to previous versions.
Whichever browsers you test in, it’s important to not avoid the “other side.” Windows
users have long seen the Mac as being inconsequential, but at the time of writing Safari
now counts for about 4% of all web users, and the trend for Mac sales (as a percentage of
the market) is upward. Usefully, there’s now a version of Safari for Windows, but even the
Mac and Windows versions of Firefox show slight differences in the way sites are handled
(mostly regarding text). Even worse, many Mac-based designers don’t test on a Windows
PC or in Internet Explorer, which has the bulk of the market. If you’re a Windows user, grab
a cheap Mac that’s capable of running Mac OS X (such as a second-hand iBook or a Mac
mini), and if you’re a Mac user, either grab a cheap Windows PC to test with or run
Windows as a virtual machine (via Parallels Desktop or VMware Fusion) on an Intel Mac or
using Virtual PC if you have a PPC-based machine. (You can also use Boot Camp on an Intel
Mac, but that requires booting back and forth between Windows and Mac OS X, so using
a virtual environment is more efficient unless you have two computers.) Linux users also
have a range of browsers to test on. Firefox is popular on that platform, and Safari is a
rough analog for Konqueror. It is worth noting, however, that the default fonts with Linux
vary considerably from those that you’d expect on a Mac or Windows PC—so you should
always define fallback fonts accordingly, and test in Linux if possible. See Chapter 3 for
more on font stacks.
No comments:
Post a Comment