Forum Moderators: open
Which browsers should I use to test my Web pages?
Blessings, RS
I've seen something as simple as a different browser skin break a css layout.
All you can do is create a snapshot of the page using the browser rendering engine to render the page.
It's not hard to install and run all the browsers you need, and it works way better than any emulation. Running through the site live on each browser is the only real way to test them. Shortcuts will just cut off the testing quality and utility.
It's not like it's difficult running these browsers.
It's not like it's difficult running these browsers.
Except that:
1. Running multiple operating systems isn't fun
2. Changing resolution and/or color depth and checking various browsers is a complete pain in the arse.
You pay to make life easier, no? :)
1. Running multiple operating systems isn't fun
2. Changing resolution and/or color depth and checking various browsers is a complete pain in the arse.
VMWare is popular for these these reasons.
You can have prebuilt virtual machines for all the scenarious you need to test, and it only takes 10 seconds to bring one back from standby and test your site.
Running 2 operating systems isn't hard, use your windows, boot into a kde based live linux cd, simple. Or do what webdoctor suggests if you want to get complicated.
Once you know how the browsers work there is very little surprise in anything you'll see. Once you write stable css your pages will display as expected in most cases.
Since I know more or less how the browsers will handle the code, I only have to check once in a while to make sure nothing is wrong, debug for MSIE, move on. This is only hard if you don't know how to do it. Solution to that is learning how to do it.
As always, the worst offender is MSIE 6, so that's the main block of debugging time usually spent. But it's fairly predictable too.
This isn't hard. Color depth really isn't that much of an issue, hexadecimal colors only cover 64 k colors, though those display slightly differently in windows and in linux/mac/unix.
The real problem is that the browser 80-90% or so of the people use, msie 6, has poor support of css and other things. That's what most time is spent on, the others tend to display pages pretty much the same.
An emulator will just run your html through different rendering engines and give you a snapshot of part of the page. Not very useful. You have to run the page, that's just part of the job, it's like putting data through a program you've written, you have to do it, if you don't test it's your fault, not anyone elses.
Checking various browsers however, how is that a pain, you have them all installed, you turn them all on, you load the page, and you look at it. What's so hard about that? You can install msie 4,5,5.5,6, and 7betat all on the same box if you use xp sp2. Same for the other browsers. You can also install msie 5,5.5, and 6 on linux, though they aren't as stable. This would be I'd say the easiest part of building a page.
if you want to get complicated.
It's really not complicated. VMWare server is now free (although it's still in beta) so there's no excuse not to try it :-)
I've never looked into using vmserver, don't even know how to get it installed, read the website but couldn't figure it out.
It would be interesting though, as long as I can pop it right into linux and run windows from it, might be worth a try, though I suspect I'd almost never use it. Can you point to any tutorials etc that are decent, for linux installs?
Always design for different font sizes so it works in everything perfectly. Takes about 4 times longer to finish a site but it takes the weight off my mind knowing it works no matter what.
If something works on all four of these it is probably going to be OK on any reasonably modern browser.
Its not perfect, as I may be caught out by Firefox on Windows or Mac behaving differently from Firefox or Linux, or Safari behaving differently from Konqueror.
So far the only issue I have failed to catch has been a page that is messed up on IE6 on Wondows 98 - not that common a combination.
Furthermore, again, it is a matter of convenience. I would just prefer to spend my time developing and not switching OS/browsers and screenshotting away.
...not switching OS/browsers and screenshotting away.
Some people would call this stuff "testing", and say it comes with the "developing" job :-)
Employee # - language they speak - % customers who speak that language
#1 English 90%
#2 Spanish 8%
#3 Japanese %1
#4 Chinese %.02
#5 Russian %.02
#6 Portuguese %.02
#7 Arabic %.02
#8 French %.02
A Swahili speaking person came into my store the other day, first one in 5 years. I am thinking about hiring a full-time employee that speaks Swahili just in case another Swahili speaking person comes to the store again.
Do you guys think I am going a little overboard?
While jtara's statement about omitting Lynx from the discussion is true it is not necessary with Opera's text browser emulation mentioned by grelmar. I remember spending hours trying to find a win32 executable version of Lynx not know it was a DOS only app!
To get the "Author Mode" button in the Opera GUI go to Tools Menu --> Appearance Sub-Menu --> Buttons Tab --> Browser View Category.
One thing that is most nifty about Opera's text browser emulation is that it's great for testing out ALT attributes on pages with images.
Swahili
A Bantu language of the coast and islands of eastern Africa from Somalia to Mozambique. It is an official language of Tanzania and is widely used as a lingua franca in eastern and east-central Africa. Also called Kiswahili.
Ahh, twist - Where do you live? O.o
John
Someone mentioned the ACID2 test and since the recent successful passing of the test by Opera, I cared to run it for Firefox 1.5.0.1 and IE 6 SP2 with patches up to January from Windows Update...
I tested IE 6 SP 2 and Firefox 1.5.0.1. The latter rendered the test in an acceptable way, but IE messed completely.
--Tony
Like others have already stated; including a DTD and using valid code will get rid of 90% of the cross browser quirks.
For my part, I develop in Dreamweaver using FF1.5 as my primary browser (1024x768 screen res primary monitor), check it in IE 6.0x (800x600 on my second monitor), on new code/experiments also check Opera 7.2X, then run it through the DW validator and double check with CSE html. And just for laughs, now and again check it in my t/rusty old NS 4.72!
Thanks for the earlier post tip on Opera small screen, funnily enough, I was researching WAP/PDA earlier today.
Tip in return - FF does a pretty good lynx/text emulation >view >page style >no style.
Have fun and Hooroo!
Your example with hiring multiple people to account for multiple languages is completely opposite to what browser testing will accomplish. By learning HTML/CSS/etc properly, you can develop one version of your site, and have it work in all browsers with no additional effort. You don't need to test your site in all browsers. The only ones you need to test in are ones you are targetting (or ones that are likely to be used by your visitors).
Your analogy is a pretty good one. There is a line, every site, every project, has different lines, different numbers of languages to support, keeping with your metaphor. What drdoc said above does not fit with any real world browser css support I've seen over the years, although it is an attractive fantasy. I always look at the target demographic to decide what to do, what browsers to support. I also ask my clients what their priorities are. For example, I have never had a client who cared about 100% opera support, so I only take a quick look with Opera. Same for Konqueror. It's also relevant where the target audience mostly is, global, usa, europe, asia, each area will favor a certain browser mix. But it's up to the developer. If someone pays me to support browsers with miniscule market shares, I'll happily do it. I don't care who it is, but I want to get paid for it if it's a professional job.
There's no absolute rule. It's a case by case thing. Maybe for one site, swahili actually will create some worthwhile sales, so in that case, yes, hire a swahili speaker. But usually it won't, so don't worry about it.
That's my approach now. I don't spend time fixing stuff when it's not my fault if it's only affecting 0.5% at most of my visitors. I like clean html, clean css.. well, clean might be pushing it.
Then there was the client running AOL4 on Windows NT -- but I digress into horror stories. You really only learn by doing, at any rate. And as you do, you learn more about what browsers will do with various types of code. And you get bitten by this and that obscure corner of the user base having some problem or other. And you learn various approaches (can we say hacks) to work around these patterns and you build a sort of "tool kit" you can roll out.
The simpler your layout, as a general rule, the less widely you need to test. And the less you choose the more advanced CSS functions the less widely you need to test.
I remember 1998 when I first tried to learn CSS. The situation was awful -- I couldn't tell if I made a mistake or the browser did! So I waited a few years. This is probably parallel to some of the more advanced CSS that is in the W3C spec today.
After all, we have, what, 2 browsers that have passed the Acid2 test. And for one of them (Opera9) it's only a weekly build, and not yet the production release. The more cutting-edge your code, the more widely you will need to browser test.
In terms of the language anaolgy twist made, in some cases, you can make do with one employee who is bilingual but also has a smattering of a few other languages. You just need to use a more limited vocabulary with the customers.
Also, a note on color depth. In 16-bit color, there can be a nasty mismatch when you use a gif with a certain color and draw the background with a hex color. Especially in older browsers and hardware, the rendering of a gif color was not the same as the rendering of a background color, and you could end up with a boxy outline where you planned on having the image float on the page.
So although I don't obsess about it, one good check at 16-bit is something I try to do. And if you want a real scare, start changing the default system font size in your OS through the Control Panel!
And if you want a real scare, start changing the default system font size in your OS through the Control Panel!
My biggest relief with the "obscure" crowd is that their going to be seeing problems with many websites, not just yours. They will be accustomed to misaligned pages.
When I was in college the computers were set up on a system where everytime you rebooted all settings were returned to a default. The default was NN4 at 640x480 at 8-bit color. You could go in and change the settings but most people just surfed using default. Everything looked like crap, images were all just blobs of colors, but I didn't go around emailing webmasters asking them what was wrong with their websites and why they didn't support NN4 on WinNT with 8-bit color. So unless your making an intranet for Red Hat 5 machines running Opera 4 you probably shouldn't lose any sleep over whether or not your website aligns properly on that setup.
@import "file.css";
Certainly there is no need whatsoever to test in old Opera, old Netscape, old IE ...
I will simply make sure that they get an unstyled version. And, I still consider that working in those browsers :)
To address what you said earlier, twist -- I could not agree more! For a newcomer it is easy to take the buzz about browser testing the wrong way. You are absolutely right that there is no need to test in all browsers. I think tedster sums it up very well.
