Which browsers should I use to test my pages?

Browser Testing

[rcshield]

Hello Friends:

Which browsers should I use to test my Web pages?

Blessings, RS

[lethal0r]

if you test in firefox or opera and ie 6 you can be sure your site will work fine for 99% of people. if its a really important site i check in ie 5 too.

[Robin_reala]

Well, for my sites I test in IE5.0/5.5/6 on windows, IE5.2 on mac, safari 1.0+, Firefox 1.0/1.5, Netscape 7.0+, and Opera. But even I think that's a little excessive :)

At the end of the day you should look at stats from your area to determine which browsers are still in common use. If your projected audience is 'hardcore' computer users who are more likely to upgrade then you can probably get away with dropping IE5. On the other hand...

[kk5st]

Personally, I take a staged approach. First, I do all development in Firefox, as it is the most css compliant at this time. Stage two is to apply patches or work-arounds to make IE6 look decent. The third stage is to check Opera, Safari, and IE5.x for breakage. I do not sweat small differences, as I am not a pixel perfectionist, and the first user to change the font-size, turn off images or disable javascript screws up that idea anyway.

Throughout the process, Lynx is consulted on any html changes, and everything is constantly checked without images or scripting.

Before the Opera fans go off on me, it's just not stable enough to use as a testbed. Support for various css properties changes from build to build. A property will work one way in v.6, differently in v.7, back again in v.8 and different, still, in v.8.5. That's not good enough for development work.

cheers,

gary

[kkobashi]

I test and support these as they make up the majority of my website viewers:

IE 6.x, 7 beta
Firefox 1.x
Opera 8.x
Netscape 7,x, 8,x

I'd rather help the cause asking users to move forward to newer releases. IE 5.x I'd rather not support any longer.

[BillyS]

I test in:

IE 6.0
Firefox 1.5
Opera 8.5

I was shocked when I first looked at my site with browsers besides IE. I had to do lots of CSS work to make it all look good.

That being said... I would think that Firefox covers Netscape too. Is that true?

[Robin_reala]

To a certain extent. Netscapes 6, 7 and 8 share the same core as Firefox (Gecko) but obviously in differing degrees of development. If you're using CSS in anything more than a mildly complex way and want to make sure it works in older versions of Netscape you still should e testing in them.

[twist]

IE, Firefox and Opera typically tell the majority of their users when it's time to update. So I test in the lastest non-beta versions of,

Firefox
Opera
IE6

As for beta testers, their using betas, if websites don't look right, they know why.

To test in all three use Firefox with "IE View" and "Opera View" extensions, saves a lot of time.

As for the rest of the browsers, just make sure you run your pages through the W3C validator and you shouldn't have to many problems. At this point your time would be better spent creating content than testing in obscure browsers.

[ssqp]

I like firefox

[JAB Creations]

You need to test by two requirements; rendering engines, and which rendering engines you (or your employer values; or that people visit with if it's conditional based on visitor's desire for choice).

There are various rendering engines, but in general you'll want to test with Gecko, KHTML, Presto, and Trident.

I use Firefox for Gecko.

Can't get any decent access to Safari browser for KHTML.

Opera (of course) for Presto.

Internet Explorer (of course) for Trident.

IE6 is not too different from IE5 but if you're running a business with a lot of traffic and a decent share of people using legacy browsers or older versions of legacy browsers like IE you'll want to test them out as well.

For fun I sometimes test my site with Opera as far back as 2.12 but (being serious again) if you get it working 7+ you should be good to go.

The Gecko rendering engine is usually pretty good (Gecko and Presto are hard to compare in many cases if you're trying to tell which is better). You should design for the latest version of Gecko as people are very good about updating their browsers. You will want to test for bugs on your site with Gecko 1.7 though unless you're willing to bend over backwards with a bit of serverside UA conditional code it's not really worth it.

The KHTML is ~NOT~ like Gecko and that will even throw off a lot of serverside coding. It has a lot of bugs and should be your second concern after Internet Explorer about screwups. While I don't hear much complaining about it I've found KHTML to not support lots of things (that even Trident does) but it's still years ahead of Trident right now.

When you are testing your site which browsers you first and which browser you lastly check with will depend on the same factors.

Is your site personal and you're trying to learn good coding practices or are you getting paid and trying to maximize usability on legacy browsers?

If you're trying to code correctly test with both Gecko and Presto at the same time. As long as your code validates and you're decent at coding you should not have to worry about much.

If you can test with KHTML rendering engine then it would be the time to do so as your third browser.

IE is a synch to clean up (and you WILL have to clean it up). Throw in some conditional comments that link a stylesheet (IECCSS - Internet Explorer Conditional Comments Style Sheet) and adjust IE's rendering until it matches the other engines. Keep in mind you can detect any specific version of IE so you could (if you really wanted to) have an IECCSS for every single minor version of IE ever to ensure they all work and simultaneously ensure your fixes for IE 5.0 (if say you cared about that version) would not effect 5.5 or 6.0.

If you're working for someone you'll want to do a quick validation and quickly work within Firefox. You'd then switch over to IE once your layout is complete and edit your IECCSS. You'd probably be much more restricted in time so you'd have to assume KHTML and Presto will hold their own (and in most instances they will) as IE and Firefox have the greatest shares of the market.

John

[bwelford]

That's a very complete answer, JAB Creations, and I'm in complete agreement. Your final paragraph, as you imply, will do most of the job for you.

Perhaps another thought to throw in is whether your audience will all be using Desktops. Do you want your web page to give a satisfactory viewing experience in a PDA? A Palm TX has a 320 x 480 resolution: do you want to give its users a good web page experience. If the world picks up the Microsoft Origami project, when it comes out, does that suggest you should be catering to the 800 x 480 resolution crowd.

[encyclo]

I would add that it is important to test in both Firefox 1.0 and Firefox 1.5 - there are subtle differences which can catch you out. Both of these browsers still have a significant market share, unlike some older browsers such as Netscape 6.x, IE4.x and Netscape 4.x which are no longer in use.

[Robin_reala]

Yep, the differences between Fx1.0 and 1.5 caught me out the other day :) Definitely worth testing in both.

[twist]

The best way to make sure your site is working cross browser is to learn what causes the browsers to have problems in the first place. Problems typically happen in the same type of situations. You just have to start thinking like the people creating the browsers think. The more specific you are, the less chance a browser programmer has to second guess on what your intentions are.

Some examples,

"<hx>" tags looks different in FF1.5 compared to IE6 and Opera8.x with a defined "text-size". FF1.5 gives some extra padding that the other two don't. By defining a "line-height" that is slightly larger than the "text-size" you can make sure the text looks the same in all your browsers. "text-size" is a gray area. This leaves the browser programmer to decide how large the container for the text should be. Don't leave the decision up to some programmer, define the container size yourself.

If your going to use padding, do it inside an area with a defined width or height.

wrong -> <div style="width:100px;padding-left:10px">text</div>
right -> <div style="width:100px"><div style="padding-left:10px">text</div></div>

IE6 will pad the 100px container 10px to the left.
Opera and FF will pad 10px left inside the 100px container.

You can see how the "wrong" example isn't specific. It says to create a container and add padding. It doesn't say whether to pad inside or outside the created container. This means that where the padding is applied is left up to the people who coded the browser. The "right" example leaves no doubt that the padding belongs inside the container.

[jtara]

Throughout the process, Lynx is consulted on any html changes, and everything is constantly checked without images or scripting.

Most of the suggestions here have omitted Lynx, and that's a shame.

Testing against Lynx is a good sanity check. What will search engines see? What will disabled persons, or tools used by disabled persons see? Is your site reasonably coherent and navigable with a text-only browser, or is a jumbled, incomprehensible mess? Or worse, nothing at all?

[tedster]

One factor that really helps cross-browser design is understanding Quirks Mode and Standards Mode -- the importance of your DTD (doctype declaration). Here's a library thread on the topic:

[webmasterworld.com...]

If you have this knowledge under your belt, you will have many fewer surprises as you test in the various browsers.

Also, I like to test in Opera's "small screen" mode to get an idea what the site might do on a PDA or advanced mobile phone.

[bedlam]

Can't get any decent access to Safari browser for KHTML.

There are several free online Safari page testers [google.com], and even if you don't have access to a Mac, it's relatively simple to set up a dual-boot [google.com] linux/Windows system so you can test in another browser that uses the KHTML rendering engine [google.com].

The KHTML is ~NOT~ like Gecko and that will even throw off a lot of serverside coding.

Jab, this must not mean what it looks like it means. Server-side code is not executed in the client...

If your going to use padding, do it inside an area with a defined width or height.

wrong -> <div style="width:100px;padding-left:10px">text</div>
right -> <div style="width:100px"><div style="padding-left:10px">text</div></div>

IE6 will pad the 100px container 10px to the left.
Opera and FF will pad 10px left inside the 100px container.

You can see how the "wrong" example isn't specific. It says to create a container and add padding. It doesn't say whether to pad inside or outside the created container. This means that where the padding is applied is left up to the people who coded the browser. The "right" example leaves no doubt that the padding belongs inside the container.

Hoo boy. Twist, this post is seriously misinformed. I don't want to take the thread too off-topic, but it might be useful to have a read through the css forum library [webmasterworld.com].

There are two things that can contribute to the problem you're describing:

1. Quirks Mode -vs- Standards Mode [google.com] and how they affect the box model [google.com]
   
2. Default padding and margins
   

For the first, the problem will absolutely disappear if you simply force your pages into standards mode by using a full doctype [google.com]. Once you do this, all modern browsers--except the IE 5 Win series--add padding and borders to the declared width of an element.

For the second, the CSS [w3.org], HTML [w3.org] and XHTML [w3.org] specs leave the amount of padding and margins on elements such as h1, p, ul, ol, li etc up to the user agent, so you're right there is built-in inconsistency in how elements are rendered. Fortunately, there is a very simple solution--

Simply add the following to the beginning of your stylesheet:

* { /* Set all padding and margins to zero! */ padding:0; margin:0; }

Then define the padding and margins for the various elements yourself. This takes a bit of time, but having done it once, you can re-use it as your default stylesheet on every subsequent project. This simple (though slightly tedious) task resolves about 90% + of non-quirks/standards rendering problems when testing.

This leads me to the comment I wanted to make in this thread--and to reiterate Twist's perfectly correct recommendation:

The best way to make sure your site is working cross browser is to learn what causes the browsers to have problems in the first place.

This is exactly right. The more rendering decisions you take out of the hands of user agents, the less testing you need to do. If:

• your html is valid,
  
• your css is valid,
  
• you do not rely on browsers' default padding and margins,
  
• you are well-informed about at least the more serious browser bugs (such as IE 5's broken box model [google.com] and IE's many float bugs [google.com]),
  
• you make yourself aware of some of the strategies for squashing those bugs [google.com] and,
  
• you always test during development
  

...then the amount of testing you need to do in the first place will be surprisingly small.

-b

[lammert]

Which browsers should I use to test my Web pages?

You didn't mention what you want to test. Until now people have concentrated on visual appearance, but remember that many "readers" of websites are the search engine bots. Browsing your site with a text browser gives a good idea of your site through the eyes of a bot. You can use lynx, or elinks. The latter supports basic color and table rendering.

[2by4]

twist is absolutely right about nesting divs to eliminate problems, I started doing that in 2000 and I haven't ever had to rewrite any website. Very pleasant feeling. I chose to ignore whether it's 'correct' or not, and go for practicality. Never regretted it, not for a minute. I still use that technique, not so much for box model / quirks mode issues, but because I don't have to sit doing the math on every change, if I want 2px more padding, I don't have to refigure the widths. Simple stuff, I like life to be easy where it should be easy.

Before the Opera fans go off on me, it's just not stable enough to use as a testbed. Support for various css properties changes from build to build. A property will work one way in v.6, differently in v.7, back again in v.8 and different, still, in v.8.5. That's not good enough for development work.

well said, that's what made me stop everything but ultra basic opera support. For a browser with a real world market share approaching 0.5%, making developers spend that much effort just isn't acceptable.

I don't know the current status of KHTML versus applewebkit/safari, but I do know that khtml is now the first non-mac browser to pass acid2 css test. So I think a lot of the css engine was brought back into the konqueror/khtml project. So I'd guess testing on kde+konqueror will give you a reasonably accurate safari test, as long as you use kde 3.5 or greater.

My current attitude is if it works with ie 5, 5.5, and 6, including quirks fixes, and if it works on gecko and khtml, then any difference opera displays at that point is an opera problem, not my problem.

[edited by: 2by4 at 8:58 pm (utc) on Mar. 13, 2006]

[twist]

bedlam -

Hoo boy. Twist, this post is seriously misinformed.

bedlam -

all modern browsers--except the IE 5 Win series--add padding and borders to the width of an element whether that element is explicitly declared or not.

So, what your saying is that,

<div style="width:100px"><div style="padding-left:10px">text</div></div>

would could stop potential cross-browser compatibility issues with IE5 and possibly others. This qualifies as seriously misinformed information?

bedlam -

padding and margins on elements such as h1, p, ul, ol, li etc up to the user agent, so you're right there is built-in inconsistency in how elements are rendered.

twist -

This leaves the browser programmer to decide how large the container for the text should be.

Seriously misinformed?

[2by4]

twist, you're not seriously misinformed, you're doing it the informed way. Pretending that the presence of a div inside a div matters in any way, shape, or form in terms of the code, except as a very powerful way to create a rock solid stable css layout, now that's seriously misinformed.

Since this is the second time recently I've seen you post pretty solid stuff in a thread and be jumped on, I'd trust your views if I were you, they work.

Normally I don't post in html etc, this one just caught my eye.

[twist]

I chose to ignore whether it's 'correct' or not, and go for practicality.

Exactly. I'm not going to bother to memorize continually changing standards and how each evolving browser interprets them.

This can only be interpreted one way,

<div style="width:100px"><div style="padding-left:10px">text</div></div>

This has two possible interpretations,

<div style="width:100px;padding-left:10px">text</div>

I don't need the css handbook to tell me which one of the two I am going to use, common sense dictates that.

[2by4]

twist, it's not so much the two interpretations, it's the fact that changing the one changes the other, in absolute terms. More padding make the div wider. Sometimes my css is very complex, and of course it's never on page, so I need the changes to not impact the layout. If you do one or two sites, it's fine being pure standards, but if you do a lot, you aren't going to remember all this stuff, it's much better to opt for maximum stability of the layotu, which is what nested divs give.

That's for commercial css, that's how I do it on almost all commercial sites, and let me tell you, when I load one of my sites for the first time in a browser I never tested them on, say Konqueror 3.5, and display is not just almost perfect, it's perfect, I have exactly zero doubts about the methods I use.

Opera would be the exception to that, but even then the stuff almost always works perfectly in opera too.

But I don't want to pull this thread off-topic, just wanted to point out that your methods are solid, whether talking about flash or css.

[zafile]

I test my pages on IE 5.5, IE 6.0, and Firefox 1.01.

I'm looking forward to buy a Mac just to test pages with IE 5.x for Mac and the newer Safari browser.

Just remember IE 5.x for Mac uses a totally different engine than IE for the PC.

[grelmar]

Back to topic:

Firefox 1.0 & 1.5
(NB: Firefox is also my "Daily Driver" - So I have a bias to test it here first.)
IE 6
Opera 8.5
Konqueror, for a KHTML browser. Konqueror is the open source KHTML browser. If K don't bust your page, probably nothing will. Biggest problem here is you need a *nix box with KDE for it. Konqeuror kinda sucks, but it'll give you a rough idea of what Safari is doing without having to invest in a Mac. Find some random old beater box and install some *nix distro with KDE, or download Knoppix, burn it to CD, and run it "Live" without having to install it on anything.

As for Lynx:
Used to use it, and it IS good for looking at your pages and seeing what the search engines see, but I've dropped it recently in favor of Opera, which allows you to enter "Author Mode" and emulate a text browser. (And there are a number of options on how you emulate a text only browser, you can even remove tables).

For fun, Opera even has a mode that looks at the web like an 8 bit computer (40 columns 4ever!)

Opera annoys me on a number of levels, as a surfer, but it has a pretty fierce built in toolkit for development.

[tsheridan]

Test all of them that you can: your visitors will come from all browsers, and you might find some oddities on some that you wil have to correct. For instance, on one, I found that my grey colours were appearing as shades of pink!

[2by4]

back ontopic:

Currently:

IE 5.0, 5.5, 6.0
Firefox 1.5 (firefox has had such stable css support I stopped worrying about supporting older versions)
Quick look in Opera 8.5 and 9
Konqueror 3.5
Lynx, just because it's the original text mode browser. Why emulate when lynx yoursite.com is only a few keystrokes away?
Elinks and Links2, look cool, and execute javascript, some anyway.
w3m, my favorite, always interesting to see what the site looks like with w3m.

You'd be surprised what kinds of errors you see right away using text mode browsers, that's how I almost always check out an seo question, open the site in lynx, and there's all the spam, for all to see. w3m helps detect very subtle scripting and login errors that would not be apparent in gui browsers.

If I want to be really thorough, for a site with a non-tech savy demographic, or a site that attracts users of old macs, I'll test in netscape 4x too.

[AhmedF]

Not mine, but I love this - [sitevista.com...]

Fantabulous in checking out how your page looks on various computers, colors, and resolutions.

[2by4]

Just discovered this one: Opera 8.5 (windows version) works great in Wine on linux, cool... now I never need to boot up windows any more.

[TonyMc]

Someone posted a free site something like sitevista.com a while back but I can't find it just now. Anybody remember the name of that site?

--Tony