How Do You Test Your Web Pages?

Pieroxy asks: "As a web developer, both professionally and personally, I try to always make sure what I write works in every browser at my disposal. When the choice came for me to choose a platform for my PC, I went the Windows route, because I cannot afford not to test IE on all those websites/applications. But now I am facing a problem with all browsers that don't have a native Windows port, such as IE5/Mac, Safari/Konqueror. kde-cygwin helped very little because the version of Konqueror shipped doesn't display most JPEG, making any testing worthless. IE5 for Mac should die soon, but is still widely used as being the default browser for so long. How do you test your web pages? Have you noticed discrepancies on how a specific engine (Gecko, Opera, KHTML) renders content on different Platforms? Do I need a Mac and a Linux machine to make sure it is working on these platforms?"

Comments

code to the standard

[Numeric]

thats usually your best bet

Re:code to the standard

[cyber0ne]

But even "standard" code can render differently in different browsers on different platforms. Depending on the complexity of the website/application, small differences can be a big problem.

At my last job I kept a log of browsers/platforms that hit the webserver. From the vast majority (at the time, IE5 on Win9x) down through the percentages, I would run what I could for testing. For example, using whatever tool of choice (VMWare on my home network was what I used), I tested my sites in IE5 on Win9x, IE5 on Win2K, Netscape, Mozilla, etc, etc. I think I was regularly testing on maybe the top 6 percentages in the log, capturing about 99.5% of the hits.

There will always be a percentage of browsers in the world you can't test, be they either little-used browsers on little-used platforms or widely-used browsers with some strange configuration that messes things up. But if you can identify the majority of the variations that are hitting your site(s), then just test as many of those as you can before you feel confident that it's "as compliant as it's going to get."

Re:code to the standard

[chris_mahan]

>But even "standard" code can render differently in different browsers on different platforms

Exactly. Things will look different. Go with standard code, and let browsers render as they will.

I would say that if you want paper-like precision, go with paper. If you want to display data, go with a simple format, and keep to the standards.

if your clients don't like it, and you want to accomodate them, then it's a business expense. Buy 8 computers and install all the different browsers on them. It will be expensive, yes, but you should pass that to your customers as a cost of development.

Re:code to the standard

[Basje]

That's a self fulfilling statistic: people with an unsupported browser (in which the page won't render correctly or at all) won't return. Thus, the supported browsers will always be top in the logs, unsupported browsers will stay at accidental hits.

Re:code to the standard

[wishus]

But even "standard" code can render differently in different browsers on different platforms.

That is by design, and it is a feature of standard-compliant design. You can code a web page once, and it will render for normal people, blind people, people with 640x480 displays, and everybody else.

Re:code to the standard

[chris_mahan]

You have no control over which browser people use. Once the packets have left your server, they're gone. Gone.

What you have to do is spread packets that follow the standards, so that users can decide for thmselves which browser they want to use.

For example, would it be amazing if every gas station in the country had different octane levels, and some had lead, others had pcbs, and yet others put ethanol, alcohol, or whatever in them.
No, standards insure that if you buy a BMW, you can get fuel anywhere in the country (and the industrialized world) and won't damage your car.

Re:code to the standard

[AllUsernamesAreGone]

Nope, doesn't work. It'd be wonderful if it did, but .. well, just look at XHTML 1.1/CSS2 and tell me how many browsers you think will handle pages written in them correctly. The site I'm building can only be valid XHTML1.1/CSS2 when delivered to Mozilla or Firefox (although I've got to test it with Knoq/Safari yet). Opera doesn't (or didn't inthe last version I grabbed) support id attributes in object elements and IE... <shudder> Even if you code to older standards support is patchy at best, especially in IE which in places expects practically prehistoric versions of some standards.

And even when browser do all support the standards you're using, they are somewhat liberal in their interpretation of them, especially when it omes to margins, padding, border sizes and whitespace in general.

In short: coding to the standards is a bit like navigating a minefield in the dark with a map of the mine locations drawn by a guy with amnesia. If that is all you rely on, you are going to end up doing the biggest splits you'll ever do in your life.

Re:code to the standard

[Captain Splendid]

HTML must use CSS dynamic placement and not tables

Didn't work for me, so I went for a CSS/Table route (despite wanting to stay completely in CSS.) At some point you just have to get on with your site however you want, otherwise I'd be tweaking all day, trying to get it right.

I like CSS a lot, though, anhd looking forward to it becoming a little more mature.

Re:code to the standard

[Rick the Red]

Go with standard code, and let browsers render as they will.

So, are you saying we should ignore the 600 pound gorilla, or thumb our noses at it? Most people code to the standards, then tweak each page so the gorilla won't barf on them.

When over 80% of your clients use one browser, you either alienate 80% of your clients or you code to their browser, however sucky it may be. "Coding to standards" sounds good on paper, but we live in the real world. BTW, the gorilla thinks it is the standard, and with it's market share it really has become one, like it or not.

P.S., in the read world the Mac doesn't even exist -- I've tested web pages for some Fortune 500 companies and while mostly they said to test on MSIE and Netscape, none of them required me to test on Mac.

Re:Of course...

[vijaya_chandra]

I don't think you can run OSX on x86 using any emulator/vm yet

but you can use vmware and an iso of knoppix to check out different browsers available for linux

Moz, IE and W3C standards

[palfrey]

Generally I'll do the dev work in $Mozilla-variant-of-the-week, but trying to keep with W3C standards and checking heavily against the validator. Provided the page is valid against various standards (HTML 4.01 Transitional as a minimum), and it renders ok in both Moz and IE, I'm happy. OTOH, I'm no longer a professional web developer (I have better things to do these days), and for a big client I'd want to check against various other platforms.

BrowserCam

[bjpirt]

If you don't want to buy a mac, you could always use browsercam

Of course you messed up in the first place not getting a mac. You can test in PC/IE from the mac, but not the other way around.

Re:BrowserCam

[Ianoo]

If anyone hasn't heard what the parent is refering to, then see the announcement here. RIP to him and my thoughts to his family.

When are we going to get some challenging Ask /.?

[stienman]

Do a Google search, and you'll find companies, tools and instructions, etc to help you do this if you are unable or unwilling to purchase the required equipment/software to do it yourself.

Of course, half the problem is knowing the correct question to ask. That's why google is so popular - it gets good results with bad questions, and you can refine your question with repeated searches.

-Adam

Yes

[ccarr.com]

Buy a cheap used iMac and make your Windows box dual-boot to Linux. If your situation allows, write the iMac off as a business expense.

You made a bad choice

[fozzmeister]

and your paying the price, you should have tried writing IE and testing Moz, Opera etc. then Then writing Moz, then Opera.

I personally find that if I write for Mozilla Firefox its usually only slight modifications needed for IE etc, and most of that is Javascript related.

IE's rendering engine is deliberately not picky, therefore it stands to reason its a bad choice to program for. Safari (KHTML) and Moz (Gecko) are OSS and as such tend to stick to the standards pretty well.

Opera used to (don't know if its still the case) stick absolutely to the standards so it may make a very good choice. I however don't test for it because of its small market share and it's still closed source.

Use Moz and go with the Web Developer Tools (http://texturizer.net/firefox/extensions/#webdeve loper) and click on the little tick thing on the right side of the bar and make sure you have "Standards compliance mode" as the Render Mode, then a quick check on IE (Windows) and your pretty much gonna be OK.

Re:Validator

[JimDabell]

I'm sorry, but that's simply not good enough. Writing valid code is only a very small part of making a robust website. You can write perfectly valid code that fails to display properly in any major browser. For example, not testing in Internet Explorer 6 will leave you prone to a couple of very nasty bugs that cause large sections of the page to simply not get shown.

Re:Validator

[DougWebb]

Nice, but irrelevant. How do you test the browser-specific templates?

Reduce the NEED for testing...

[Dr.Dubious DDQ]

That is, make sure your design isn't dependent on pixel-level control of everyone's browser as far too many web developers (and damned "content-generator" programs) seem to insist on.

Or in other words, always remind yourself that The Web is Not a Print Medium (Highly recommended, if slightly "fluffy", article). Most of the "hey, it doesn't work/look right in this OTHER browser" problems I've ever seen boil down to the web designer having a pressing attitude that they need to control the users' browsers down to the minutest pixel, and have a pile of browser-specific tricks that depend on recognizing the specific "brand name" of the browser and behaving in a different quirky manner depending on which (of the listed ones) it recognizes.

Many others have already posted the good advice to just "stick to the standards". In case it isn't obvious, that most especially means "don't reference any 'browser quirks' anywhere in your design." Even IE seems to have reasonable support for "standards compatibility mode", so if you stick to standards, you will greatly cut down the potential problems that necessitate testing your pages in 10+ different browsers on 4+ different platforms in the first place.

(The rare individual that really DOES require iron-fisted dictatorial control of the pixel-by-pixel layout of their page shouldn't be using HTML anyway - that's what PDF is for...)

Re:Validator

[JimDabell]

Yes and no. Firstly, it's quite possible to write valid, but stupid code. All a validator does is check for syntax errors, logical errors are outside of its problem space.

Secondly, and more importantly, of course there's something wrong with a browser if it can't display correct code sensibly. Newsflash: browsers aren't perfect, and when a client complains that Internet Explorer 6 users can't see any of the text on their website, they aren't going to care that the syntax is correct, they are going to care that you didn't ensure their website could be viewed in the web browser the majority of the world uses.

Re:Validator

[JimDabell]

If there is anything worth seeing on the website, then users will find a way to see it, even if that means downloading a new program.

No, they are far more likely to simply go to another website. And how are they to know what to fix? The average user doesn't have a clue that a rendering flaw is caused by a bug in their web browser and they could fix it by switching browsers.

This is the paradigm that has worked for Real, Macromedia, and the thousands of companies that use their products.

No, those are helper apps, not alternative browsers. That's a massive difference. Even so, when somebody offers Real and Macromedia files, it's usually content that you can't get elsewhere. The same is not normally true of HTML/CSS/Javascript/etc.

Web developers complain about having to code around IE's bugs, yet by continuing to do so they perpetuate the problem.

I don't disagree there. But it's the lesser of two evils. People develop websites to communicate with people, not to admire the cleanliness of the code. The content you produce is irrelevent if people don't see it.

Can you imagine if Mozilla introduced a new "feature" that was of benefit to the porn industry, and all of a sudden porn sites couldn't be viewed by IE? There would be a new "de facto standard browser" overnight.

Why would a porn website turn away the vast majority of their visitors? Sure, if all of them did it at once, it might be effective. But nobody will make the first move, as it would be commercial suicide - their competitors would just sit back and soak up all the Internet Explorer visitors they've turned away.

Tell the client that if there is any worthwhile content on his site, his audience will find it. If the audience isn't willing to upgrade a broken, worthless browser to see his content, then the content itslef is worthless.

That's a very arrogant attitude. What about people at work who can't upgrade? What about the people who aren't technically adept enough to even know about alternative browsers, let alone switch? What about people with vision problems who use expensive screen readers based around Internet Explorer? You really want to make it difficult for people to view your websites because of some browser snobbery? You might be willing to do that, but the people who commission the websites surely don't.

IE is no one's friend

[Dracos]

IE hasn't had any worthwhile rendering engine improvements since version 5, giving it the absolute worst standards compliance of any browser shipped today.

Never forget that IE wan't designed as a developer tool, is was designed to kill Netscape. True to MS form, trying to decipher any of IE's pitiful error messages will only cause migraines.

The W3C stopped development of their own reference browser (Amaya) because Mozilla's standards support is so good.

And stop using dreamweaver. It is incapable of generating compliant code, its javascript library is optimized for 3.x browsers, and no one ever learned HTML by using dreamweaver. It's appaling to me how many people claim to know (X)HTML but don't. Macromedia doesn't really give a damn about standards anyway. DW is also why no one seems to understand CSS... they never see it used effectively. All this and DW uses IE to render pages; see above for why this is bad.

Every so called "web designer" needs have their DW uninstalled and be forced to code pages by hand for a week to see how good they really are.

Re:Validator

[JimDabell]

>The whole point of testing in browsers is to ensure that things work properly.

The whole point of standards is that you don't have to. They will, all by themselves, if the browsers are standards-compliant.

The point of standards is to aid interoperability. They aren't a get-out clause to expect everybody else to write bug-free code. That is an unreasonable expectation, especially as validators themselves are only a tool to catch errors you've made yourself. So you make errors but nobody else is allowed to, is that it?

If I validate xhtml 1.1, that's the end of my testing phase.

You are aware that XHTML 1.1, per standards, will not work in Internet Explorer?

>How do you ensure that the HTML, CSS, etc you have chosen works with popular browsers?

By using standard-compliant xhtml and css. In and of itself, this guarantees that this will work in particular browsers.

Which particular browsers? There is no browser that gets XHTML or CSS completely right. It's quite obvious to anybody who has spent more than five minutes developing websites that standard-compliant XHTML and CSS does not guarantee your website will work in any particular browser. Browsers have bugs. You can deal with that by testing, or you can stick your head in the sand.

Note that I semantize, and don't go for special effects. (None. Go to my site, you'll see. It navigates and looks the same in Konq, Safari, Moz, Op, Lynx and Links.)

Your website violates RFC 2616 (HTTP 1.1) and RFC 2854 (the text/html media type), as XHTML 1.1 is not permissable to send as text/html. Also, by including an XML PI, you are screwing up rendering on Pocket IE and one other user-agent that I can't quite recall. If you want to comply with the specifications and also be accessible to the majority of the web, you'll have to drop back to XHTML 1.0 and follow Appendix C.

Or you could take your own advice, use the application/xhtml+xml media type, and say goodbye to Internet Explorer users, Lynx users, Links users and most search engines. After all, you just have to write to standards, and your job is done, right?