Page 1 of 1

Browser Compatibility

Posted: Thu Feb 28, 2008 6:21 pm
by Chalks
When I build a webpage, I try to keep it compatible with as many different browsers as possible. However, I have not (in the past) tested them personally with mac or linux browsers. Also, I generally test with whatever version of firefox/IE I have currently installed. This is obviously not good practice, and I want to change it. However, I'm not sure how extensive I should/can test on my windows machine.

I would like to have up to 3 old versions of the major browsers on my machine. I'm sure I can do this with firefox fairly easily (heck, I already have 2.0 and beta 3... getting 1.5 again shouldn't be hard). However, I'm not entirely sure that it's possible to have both IE 6 and IE 7 installed. I have no idea if I can, or how I can install and run mac browsers on windows (unlikely?), or even which browser(s) and version(s) to test. As for linux, I could just use my handy dandy bootable pen drive but again, I don't know what browser(s) or version(s) to test. Besides, rebooting every time you want to test on another browser is a pain.



I'd like to form/get a list of places to download the versions and browsers for _windows_. I'll start with the easy ones:
Firefox Portable 1.5.0.10 (portable version doesn't destroy my 2.0 info)
Firefox Portable 1.0.8 (I don't know if anyone uses 1.0.8 still)

I don't know how well this works, as I'm afraid to test it till someone says they've heard of it:
Multiple IE installer
Some more info about Multiple IE
Edit: downloaded it and ran it. I don't know why I was worried... I have backups of everything on my computer, and I mostly use freeware programs, so... no big loss if virus eats everything. I checked out msn.com with IE 3-7... and wow. IE 3 and 4 sucked. hard. I can't believe everyone used to think those were so great (did anyone ever believe that?). IE 5+ loaded everything pretty much ok. Though 5.5 and 7 both coughed a bit. It was fun to mess with. Interestingly enough, 3 and 4 died on my simple website (which has php, and a bit of javascript) just as fast as on msn.com.



Um. that's as far as I've gotten. Help? :)

Re: Browser Compatibility

Posted: Thu Feb 28, 2008 7:27 pm
by Weirdan
for other platforms (Mac, Linux) you could use a virtual machine like vmware or microsoft virtual pc. From what I heard, safari win / safari mac have no differences in rendering, that should be the case for firefox on these platforms as well. IE5 for Mac is a different beast - it's rumored to be the quirkiest browser in the universe.

Re: Browser Compatibility

Posted: Thu Feb 28, 2008 11:06 pm
by Ollie Saunders
Being a web developer and not a web designer I'm in the interest of making web applications, hopefully ones that take advantage of new technologies and advancements. To go to the effort of supporting very old browsers is giving the people using them a reason not to change and potentially holding up developments in the industry.

So any web app I write will usually work in:
  • Opera - the version I currently have installed on my PC and and mac, I usually try to stay a few versions behind
  • Firefox 2 (latest) and 3 - I could probably expand this to 1.5 actually, it's not something I've considered before. Incidentally there are rendering differences between the Window and Mac versions of Firefox.
  • Safari - I use the versions I have installed on my PC and Mac. My last place of work had lots of Macs so I was able to test about 3 or 4 different versions. They all look and feel the same to use but do render differently. Since I left I don't have access to that. Considering this browser is a bit like IE, in that they will probably be a whole class of people who never update it, I really should go dig around the Apple Knowledge Base a bit and see about running multiple versions. However, in general, provided you aren't doing anything too clever with the "display" CSS rule you'll usually find that Safari obligingly behaves almost exactly the same as Firefox i.e. obeying web standards. This only endears me towards it more and makes me more willing to support it.
  • IE - I test 6 and 7, and give 5.5 a quick check. Quite often I allocate days for fiddling to getting stuff to work in 6 and 7. It's a necessary evil. I know 6 is still going to be in use for quite some time because the usability of 7 is so bad. IE 7 introduces some of it's own new bugs so sadly even if it works in IE 6 you still have to test IE 7. Supporting anything earlier than 5.5 feels like insulting myself. Even supporting 6 I find myself degrading instead of getting things to work a lot of the time.
Notable by their absence are:
  • IE for Mac - I wouldn't know where to start about getting a copy. I believe it's no longer supported by Microsoft. From what I've heard I sure I wouldn't bother with the effort involved, how many people use this these days?
  • Netscape - This is just too old for me to care about
This is about the level of effort I would go to for a web application that uses a fair amount of JavaScript. For a web site I would differ with the additions of lynx, which is a text-only browser for Linux. I don't really care a lot about users of Lynx but it's the closest thing I've got to mimicking a screen reader (blind and partially sighted users rely on screen readers).

Also consider testing:
  • With stylesheets disabled - This test identifies where you are possibly using mark-up incorrectly.
  • With images disabled - This is a good test to see if any text goes becomes invisible because of missing CSS "color" rules
  • With JavaScript disabled - This is something I will do for websites where JavaScript enhances, for web apps where it's used extensively I won't begin to attempt to support browsers where JavaScript is disabled.
  • Mobile phones - If you dig around on Google you should be able to find articles on that. I believe there are 4 major rendering engines in use on mobile phones.
  • Print previews on any of the browsers tested
These are rules of thumb. It depends on the site in question and the expected audience. For instance, I've put considerably less effort into the browser support on my blog than I would if I was creating a government site.

And yes, multiple IEs is good.

Re: Browser Compatibility

Posted: Thu Feb 28, 2008 11:57 pm
by matthijs
Ole has some pretty good tips. Testing to see how your site looks/behaves with/without images, javascript, css is very important. It's essential.

I would say way more important then testing versions within browsers. In my experience, with browsers like Firefox, Opera and Safari there are hardly any differences between versions. I have personally never encountered one. So I just keep the latest ones around.

Not so with IE versions. For those the IE standalones are pretty good. Not perfect, but good enough for most testing purposes.

So what I do is build in FF on Mac, test in Safari mac, FF win, Opera win/mac, IE 6 and 7 win. In that order. Sometimes IE5.

If I may I'd like to add another tip. Maybe a reason why I almost never see any differences between the modern browsers or the versions within those when I build a page, is that I try to bullet-proof my code. One way to do that is by always building in a bit of flexibility. For example, if you're building a flexible layout, account for differences in rounding. So don't add box1 70% + box2 30%, but make them 69% and 29%. Or make sure boxes are flexible enough to deal with different amount or sizes of text.

Re: Browser Compatibility

Posted: Fri Feb 29, 2008 12:03 am
by Ollie Saunders
It depends how clever you are being. If you keep the CSS simple yeah it can be a very easy job. These days I'm nearly always doing something clever. Also I'm slightly addicted to the new CSS selectors which means I always put them in, grin to myself about how cool they are, realise they are unsupported and look glum as I have to remove them again. I should really stop doing that to myself. Still, it works fine for intranets.

Re: Browser Compatibility

Posted: Fri Feb 29, 2008 12:21 am
by matthijs
ole wrote:It depends how clever you are being. If you keep the CSS simple yeah it can be a very easy job. These days I'm nearly always doing something clever. Also I'm slightly addicted to the new CSS selectors which means I always put them in, grin to myself about how cool they are, realise they are unsupported and look glum as I have to remove them again. I should really stop doing that to myself. Still, it works fine for intranets.
I don't agree. It has nothing to do with being simple or not. It's about making sure your layout does not fall apart at the slightest change of one aspect. It's the same as when programming in php. You don't want your entire application crash when somewhere one variable changes in an unexpected way.

And about the more advanced CSS stuff: if you follow the mantra of progressive enhancement and graceful degradation, you can use them. Say for example you use text-shadow, or border-radius. The newer browsers will render those and make your site even prettier. Older browsers don't. Too bad, but not a big problem. Well, of course unless those elements are really needed in all browsers. Then you're out of luck and you have to fall back to other methods ..

Re: Browser Compatibility

Posted: Fri Feb 29, 2008 12:30 am
by Kieran Huggins
So I'm a tad lazy on this front, but I seem to be able to pull it off. It's all about best practices and layering enhancements; let me explain:

I start by structuring the information into logical, meaningful markup (xhtml). If you give this any real amount of thought your site will please CSS-less browsers and screen readers alike. No scripts are allowed at this point; the app must function as a series of static pages. This really isn't too much extra work, and it pays big dividends down the road. Also, testing the app at this point is hella simple!

Next comes the styling. After having a reasonable data layout in xhtml makes a Photoshop mock-up of the pretty version soooo much easier. I generally start by designing my highest traffic pages, handling more abstract layouts later (like the welcome/home page). People often make the mistake of designing the homepage first, then fight to make the actual data pages fit the design of the home page, which is a tad ridiculous, and leads to terrible design "hacks". I've found my method has given me more satisfying results in far less time, I totally recommend at least trying it.... but moving swiftly along:

At this point I build the stylesheets, testing in FF2 & IE 6. I find that achieving IE6 compatibility is usually enough to include the peculiarities of other browsers. Starting with sane xhtml & CSS is often all that's required to satisfy FF, Safari and Opera, with few exceptions. I don't support < IE 6 unless the site will be targeting people with older browsers. I just plain refuse to bend over for IE5 Mac. People with that browser just need to upgrade, and there are 4 safer, free alternatives. If it weren't for the language filter I would have made that point more colourfully.

Next comes the behaviour layer. This should be entirely loaded with a JS include with no inline script. If the browser has JS enabled then the behaviours attach, overriding the default actions with their sexier, ajaxy counterparts. jQuery is designed exactly for this purpose, and if you don't know how much I love it yet, you've been living under a rock. At the bottom of the ocean. On Pluto. Srsly.

So at the end of a build, I've usually only tested in FF & IE6, and 99% of the time it works and displays flawlessly in Safari and Opera. Do I bother checking? Most of the time, but again: I'm kinda lazy about it. Sane CSS almost guarantees compatibility on the style side, and jQuery is also cross-browser. Besides, at the end of the day the app will work with both CSS and JS turned off. So I feel satisfied, and I have yet to hear anyone complain.

If you need to do anything really fancy (for more advanced apps and/or intranets) I would just build a client quickly in XULRunner and have people download it & run locally. This guarantees both the flavour and the version of the rendering engine, and also gives you access to some sweet XUL elements.

Re: Browser Compatibility

Posted: Fri Feb 29, 2008 9:15 am
by Jonah Bron
Kieran Huggins wrote:If it weren't for the language filter I would have made that point more colourfully.
Thank goodness for the language filter!

Re: Browser Compatibility

Posted: Fri Feb 29, 2008 10:14 am
by Kieran Huggins
PHPyoungster wrote:
Kieran Huggins wrote:If it weren't for the language filter I would have made that point more colourfully.
Thank goodness for the language filter!
You have no <span style='color:blue' title='I&#39;m naughty, are you naughty?'>smurf</span> idea!

Re: Browser Compatibility

Posted: Fri Feb 29, 2008 4:02 pm
by Ollie Saunders
Kieran Huggins wrote:I start by structuring the information into logical, meaningful markup (xhtml). If you give this any real amount of thought your site will please CSS-less browsers and screen readers alike. No scripts are allowed at this point; the app must function as a series of static pages. This really isn't too much extra work, and it pays big dividends down the road. Also, testing the app at this point is hella simple!
Yes this is a great technique. I think what you are referring to about giving it real thought is achieving semantic mark-up. But I do think that providing a pure sever-side solution for every mixed client-server solution adds about 40% to the overall work (not the 100% that most people think). In some situations, such as intranets and administration sites, that 40% can't be justified because it's far easier and cheaper just to say to the userbase to make sure they have a decent browser with JavaScript enabled.

I was in just such a situation with my last project and I was able to write a near static HTML page, a model layer that responded with JSON and implement all the functionality from there in lovely AJAXy JavaScript.
Next comes the styling. After having a reasonable data layout in xhtml makes a Photoshop mock-up of the pretty version soooo much easier. I generally start by designing my highest traffic pages, handling more abstract layouts later (like the welcome/home page). People often make the mistake of designing the homepage first, then fight to make the actual data pages fit the design of the home page, which is a tad ridiculous, and leads to terrible design "hacks". I've found my method has given me more satisfying results in far less time, I totally recommend at least trying it.... but moving swiftly along
How do you decide what your pages are going to be? Do you use any kind of iterative design process. Most of the experienced developers I talk to recommend two things: Have a prototyping/design phase for each work iteration and do usability tests.

Application prototyping is a recent interest of mine, I'm keen to learn and try all the different methods. There are use cases, paper prototyping, HTML prototyping, Illustrator/photoshop mock-ups and cleverer tools such as Axure.

For my last project I used paper and then HTML prototyping. I found that HTML was slow but highly representative of the final product whilst paper was incredibly fast but I missed issues that affected the quality of the designs. One such example was a contextual dialogue box which I planned to overlay over the interface. On paper it looked great, I planned for the dialogue to be dismissed by the user clicking anywhere outside it. When I came implement it I realised that dismissing it in this way was very unnatural. Also the dialogue didn't stand out clearly enough and I was worried users would completely miss it. I solved the first issue by adding a cancel button and the second by adding a drop shadow. So although paper was great for 70% of the design decisions I did miss stuff. Despite this I still prefer paper to HTML because the HTML consumed a huge amount of time and the problems with paper should reduce as I get more experienced.

That sheer number of times I reworked the design whilst prototyping was a great indication of how rubbish my first attempt would have been if I was go ahead and implement that straight away. And I don't think that's just because I'm crap. I know the difference between mental and implementation models but it still took quite a few goes to relinquish my normal thinking.

Towards the end of the project I watched the users try the application out. I noticed a couple of issues immediately. Initially the user didn't understand the relationship between the "list of existing items" and the "currently selected item" panes which underpinned the entire app. The solution involved 15 minutes of tweaking with CSS (increasing and decreasing spacing here and there and changing colours) but it dramatically improved any new users' initial experience of the app.

Usability testing, as I was doing there, was identifying other problems that were invisible to the designer of the application. The designer approaches using his own application with all the knowledge of how it works. So it's essential to see what's clear without all that initial knowledge.

The book "Designing the Obvious" which I've mentioned before talks about all the techniques I've mentioned and more. Read it!
Next comes the behaviour layer. This should be entirely loaded with a JS include with no inline script.
Absolutely. And for best client-side performance <link rel="stylesheet"/>s should appear as high in the document as possible whilst <script> tags should appear as low as possible.
If the browser has JS enabled then the behaviours attach, overriding the default actions with their sexier, ajaxy counterparts. jQuery is designed exactly for this purpose, and if you don't know how much I love it yet, you've been living under a rock. At the bottom of the ocean. On Pluto. Srsly.
JQuery is great. But must admit I'm still mildly intrigued by some of the other frameworks. I guess you'll just have to kick that out of me :D
So at the end of a build, I've usually only tested in FF & IE6, and 99% of the time it works and displays flawlessly in Safari and Opera.
Wow that's a very high percentage. I don't usually get as lucky as that.
Do I bother checking? Most of the time, but again: I'm kinda lazy about it. Sane CSS almost guarantees compatibility on the style side, and jQuery is also cross-browser. Besides, at the end of the day the app will work with both CSS and JS turned off. So I feel satisfied, and I have yet to hear anyone complain.
I've experienced situations where code written in JQuery wouldn't work in Opera, I never did find the cause of that issue. Perhaps it was just a freak occurrence. I don't operate on assumptions that things will work first time, I think it's wise to expect problems, sometimes big ones.
If you need to do anything really fancy (for more advanced apps and/or intranets) I would just build a client quickly in XULRunner and have people download it & run locally. This guarantees both the flavour and the version of the rendering engine, and also gives you access to some sweet XUL elements.
Cheat!

Re: Browser Compatibility

Posted: Fri Feb 29, 2008 8:09 pm
by Chalks
ole wrote:Cheat!
up up down down left right left right b a start.



Seriously though, all the ideas and thought processes and what not are really really interesting. It's nice to get inside another webdesigner's head once in awhile. Especially on something that can be as tricky as compatibility issues. Personally, I will scribble out rough ideas on about 20 blank pieces of paper. After deciding which one I think looks best, I then build content. After I have the content I want, I start styling everything and adding javascript and whatnot. In fact, the article that best describes my style of webdesign is this one from A List Apart. The basic premise of the article is that the content of the website is what dictates how it is designed, not the other way around. Or something like that. Read it yourself. :-D

hehe: Compatibility.

Re: Browser Compatibility

Posted: Fri Feb 29, 2008 10:26 pm
by Kieran Huggins
Chalks wrote:
ole wrote:Cheat!
up up down down left right left right a b select start
And remember to blow on the cartridge first!

Re: Browser Compatibility

Posted: Fri Feb 29, 2008 11:04 pm
by Chalks
[derailedThread]
Kieran Huggins wrote:
Chalks wrote:
ole wrote:Cheat!
up up down down left right left right b a start
And remember to blow on the cartridge first!
re-fixed (select depends on the game)
Also, blowing the cartridge was fun.






wait. ON the cartridge. I meant ON it.
[/derailedThread]

Re: Browser Compatibility

Posted: Sat Mar 01, 2008 12:20 am
by Kieran Huggins