The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Multi-browser support rant

I have been working on a web app, my first web app, and a couple of days ago I decided to try the website using FireFox. Wow! I cannot believe how different the site looks. It really looks like crap! So I started searching for solutions to support multiple browsers and came across quirks mode and such. Well, I have decided to develop and test with FireFox and then port, if you will,  over to IE but all of this is a hugh pain. I feel like I'm not making no progress at all and just crawling along on this project.

My background is developing GUI windows applications and now I'm thinking of scaping the website and heading for the Smart Client route with a webservice.

How do you web monkeys do this multiple browser support all day long!?!? Don’t you feel like your spending all your time spinning your whe

Thursday, December 01, 2005
 
 
You must stick to bog standard HTML, or even XHTML without using any browser extensions. You must stick to bog standard CSS, not the advanced cutting edge stuff, that is widely supported. Avoid javascript as different implementations on different browsers make it a real PITA.

I generate web pages that look identical in IE6, Firefox and Opera, so it can be done. If you can't do it, then you're doing something wrong.

I have been generating my web pages using server-side XSL transformations for several years now, and I've recently tested the switch to client-side XSLT. Guess what? It works both in IE6 and Firefox.

See. It can be done if you try hard enough.
Tony Marston Send private email
Thursday, December 01, 2005
 
 
It's really not that bad.... If you get html to work in firefox, it will almost always look the same in IE.  The main painful differences are in JavaScript, so often you'll have a bunch of conditionals which is annoying.  The big things to keep in mind are just use well formatted HTML and remember your "" in attributes.
Phil Send private email
Thursday, December 01, 2005
 
 
Stick to XHTML 1.0 and CSS 2.0 and you should be in good shape 95+% of the time.

If you start using Javascript, as long as you stick to the standards (1.2?) and do some simple if/else to handle the oddities, you'll be in good shape there.

Stay away from ActiveX and the nifty Firefox extensions if you want people to actually use it.
KC Send private email
Thursday, December 01, 2005
 
 
Test driven development helps for web apps. Write or change a small part, then view it in your target browsers. Make small incremental changes. Test small parts alone, then integrate with other areas of the layout later. It won't take long and you'll know exactly what quirks each browser has. It will still be important to test in small pieces, but development will be faster because you'll already know how to deal with most quirks. Learning to deal with quirks takes the most time in the beginning. Keep the design and coding simple (this can be very elegant too!)
Nonymous
Thursday, December 01, 2005
 
 
> "I'm thinking of scrapping the website and heading for the Smart Client route with a webservice."

Please don't do this.

You'll thank us later.  As will your service's users and whoever pays for its development.

Cross-browser web development isn't too bad if you design in small steps and test in all popular browsers from the beginning - every time you create a new complex style on something, test it in IE5, IE6, Firefox, and Safari (if you have a Mac available).  If all of them can render it the desired way, then you're safe (unless your app needs to be viewed by a company still stuck in the dark ages of Netscape 4 - yes, such places do still exist).


Here's something that will make this task much easier:

(flame shield ON!)

Don't try to be perfectly "semantic" with an all-CSS design if it's giving you trouble.  (And it will, once you leave single-target-browser land.)

If a TABLE will work for your horizontal navigation bar, and you can't get an over-styled UL/LI set to work, ignore all of the web design theorists who scream, "But it's really a list!  A list of links!"
Marco Arment Send private email
Thursday, December 01, 2005
 
 
http://browsershots.org makes cross-browser development much less painful.  Testing the incremental changes that people are advocating becomes a lot easier.
Richie Hindle Send private email
Thursday, December 01, 2005
 
 
Use HTML for structure of content and CSS for presentation. Try to keep both separate as much as possible. I used to write style attributes when I was testing things out. Now I often find it easier to make adjustments on the fly by making an external CSS and using a class attribute with multiple options (tag class="borderLight textLarge"). Yes, a little more work to start, but so much easier later, particularly with repeating elements. When I notice patterns latter in development I can consolidate the CSS further. With server side programming you have the option to use a separate CSS for different agents. I have not found the need for this yet. If dealing with padding and margins is difficult, try setting a bright background-color to figure it out and then delete it later.
Nonymous
Thursday, December 01, 2005
 
 
Funny thing is that I did my first web app in 97 and had the same exact problems that I still have today with different browsers.  The problems are always minor but still annoying.  I really hate developing web apps.
Bill Rushmore Send private email
Thursday, December 01, 2005
 
 
"My background is developing GUI windows applications and now I'm thinking of scaping the website and heading for the Smart Client route with a webservice."

If your only reason for going to a smart client is because of cross-browser issues then I don't see the need. 

Instead, just tell your users they have to use a specific browser to use your app.  This seems simpler to me than going the smart client route and telling them they have to download your smart client to run the app. 

If there are other reasons for going the smart client route then I would understand.  But cross-browser issues are not in themself enough.
Herbert Sitz Send private email
Thursday, December 01, 2005
 
 
MarketingSherpa ran a good article two days ago on why you should code for Firefox first and Internet Explorer second.  Besides being a growing population of users (as high as 35% on tech sites), coding for Firefox means using web standards which provide several benefits.

Original article:

http://www.marketingsherpa.com/sample.cfm?contentID=3130

Summary on my blog:

http://richardkmiller.com/blog/archives/2005/11/design-for-firefox-first-internet-explorer-second
Richard Miller Send private email
Thursday, December 01, 2005
 
 
You might also check at http://particletree.org .  They write a bunch about 'degradable' Javascript - provide a way for non-Javascript-enabled browsers *or* JS variations to still provide a usable experience.  I'm new to the web stuff but their examples work for me in IE & FF.
a former big-fiver Send private email
Thursday, December 01, 2005
 
 
"How do you web monkeys do this multiple browser support all day long!?!?"

It's much easier if you immediately start building for both browsers.  I have an incrediably complex site with frames, popup divs, pull-down menus, etc, etc and it all works fine in IE and Firefox.  There was a lot of initial pain, but now that I've dealt with it I can continue to code and really not have to worry about cross-browser compatibily -- it simply works.
Almost H. Anonymous Send private email
Thursday, December 01, 2005
 
 
Your first mistake, as I suppose you've learned, was doing development on IE. Given the choice, you should always develop on the more standards-compliant browser and then add fixes for the lesser browser. It hurts a lot less that way.

I'd also suggest testing in Opera if possible, even if you don't care about it. Its default stylesheet differs from other browsers, and it'll catch some bad assumptions that you make.

For Javascript, see http://www.quirksmode.org/ . Be aware that IE has significant bugs in its DOM implementation, such as losing form input attributes on insertion in some situations.
comp.lang.c refugee
Thursday, December 01, 2005
 
 
If you don't read anything else on quirksmode, read http://www.quirksmode.org/js/support.html .
comp.lang.c refugee
Thursday, December 01, 2005
 
 
I develop all the markup (HTML), styles (CSS) and behavior (JS) with reuse in mind. In practice, this means aiming for three things: minimal markup, meaninful classnames and clean scripts. This builds a practical user interface library little by little, and I have to solve each browser problem only once which is good for sanity.

To give an ad hoc example, after the styles and scripts are done, creating a warning message which the user must acknowledge before continuing is simply a matter of:

<div id="major-problem">
<h2>All your base are belong to us</h2>
<p>You are on your way to destruction</p>
</div>

I think being as semantically correct as possible is the way to go. Each time I've decided to take a shortcut I have had to make a detour later on, in the end giving me more work and making the whole process less enjoyable.
Aapo Laitinen Send private email
Thursday, December 01, 2005
 
 
If you have a Linux machine, Konqueror is very standards compliant and is related to Safari ... if you design for Konqueror, almost everything will work for Safari, >=IE6, Mozilla and Firefox.

As others have said, develop incrementally and test with a lot of browsers.  I like to start out with my layout by creating a test page and css that has different background colors for each <div>.  Once the layout is okay, I start filling it in (generally, this test page becomes my template and the other pages dynamically generate content for it).

If you start by supporting multiple browsers, you'll quickly learn the common compatibilities and the whole process will get much easier.

Good luck
Steve Moyer Send private email
Thursday, December 01, 2005
 
 
"I have been generating my web pages using server-side XSL transformations for several years now, and I've recently tested the switch to client-side XSLT. Guess what? It works both in IE6 and Firefox."

Wow, you got client-side XSLT working in Firefox?  I recently tried some client-side XSLT (that works great in IE6) in Firefox and it took me about 30 seconds to discover all sorts of nifty bugs and security holes.  Search the Firefox bug database for XSLT some time if you want a good laugh.
SomeBody Send private email
Thursday, December 01, 2005
 
 
OP: You probably tested only on IE6. Now try IE5.5; IE5; IE4; does it work? (Most probably, worse than it does on FireFox. Does it work on IE on the Mac? Probably not. On a Nokia 770 or a PSP (great form factor in-your-pocket browser)?

By developing exclusively for IE (which is what you did so far), you targeted ~85% of the overall desktop market. If it doesn't work well on earlier IE versions, it's closer to 70%. If that's ok with you, then -- fine.

Write it off as a learning experience. Next time, do cross-dev from the start; e.g., while developing make sure you test in IE, FF, Opera, Safari & Konqueror (one on each day if the week, if you have a scheduling problem). You'll see that for ~5% more development time before release (amortized -- more upfront, much less down the road), you get a lot back when the app is released, because you'll have much less support overhead.

Analogy: You develop a clock that fits in a car's dashboard.  You develop only for Pontiacs. Then, just before release, you try to make it work with Fords as well. It sorta works, but it requires a lot of cutting and reshaping to make it really usable. Now, where's the problem - at ford, or in the development process?
Ori Berger
Thursday, December 01, 2005
 
 
Cross-browser development is rather easy... after a while when you start to religiously(sp?) follow _the standards_. Just because something works, doesn't mean it's correct. Do your development in firefox + the validator plugin. Really.
Dave
Friday, December 02, 2005
 
 
I've just now started to move away from table based layout to a CSS based layout.  I tend to do the opposite of most people here.  In my experiance most CSS stuff works perfect in Firefox, but screws up badly in IE.  So what I'll do is write, test in IE and if it works in IE then I'll text in Firefox.  If I do it the opposite (I am a die-hard firefox user) then I'll usually have a perfect looking firefox page that renders poorly in IE.

PS:  Dont belive the hype.  It's damn near impossible to do a 100% table free layout that works in all browsers all the time.  Sometimes you *have* to use tables, W3C peanut gallery be damned.
Cory R. King
Friday, December 02, 2005
 
 
When would you have to use tables? The only time I can think of is when you have tabular data. But for layout, I think it's possible to make a pure, tableless site that looks great  on both Mozilla and IE (and probably even in Safari, Opera, Konquerer, etc.,).
J
Friday, December 02, 2005
 
 
" When would you have to use tables? The only time I can think of is when you have tabular data"

If you really want a grid layout, tables are the only way to go. Having said that, if you really want a grid layout for something that's not tabular data, it's probably time to take a step back and look at what you're doing.

For an example of just how hard it is to fake a grid with CSS, look at Excite's TV listings. They're marked up as nested lists when a table would've been both easier and more semantically correct.
comp.lang.c refugee
Friday, December 02, 2005
 
 
Hmm, Excite's TV listings (http://www.excite.com/tv/grid.jsp) are tables for me in both IE and Firefox.
SomeBody Send private email
Friday, December 02, 2005
 
 
HTML standards proponents hover dangerously close to being architecture astronauts.

Sure, it's possible to do grids in pure CSS, yes.  But making it work right in all cases takes far, far, far longer then just doing it in tables to begin with.  Tables have been in browsers since the dawn of mankind.  They WORK, and I can use them and be reasonably sure they look right on Mozilla-Safari running on Sun's Gentoo Windows-Linux without ever actually using the browser.  With CSS, it's anybodies guess what it will render like.  In other words, the cost/benifit ratio of pure CSS starts to go pretty low.

While doing it pure CSS is a novel idea, I have yet to be convinced why it should be THE MOST IMPORTANT THING EVER TO DO IN THE WORLD.  I'd rather ship a product then produce something that takes a week to test on every browser in existance just to appease the knuckleheads over in the W3C.
Cory R. King
Saturday, December 03, 2005
 
 
Use the experience to learn minimalism in your design.  If you're having trouble making your website cross-browser compatible, it's a sign that you're being excessively clever.

Remember, it's not just IE/Firefox/Opera, it's IE 5/5.5/6/7 (when it comes).
Mediocre Coder
Sunday, December 04, 2005
 
 
That's odd, SomeBody. It seems to send tables to IE and Firefox, and nested lists (with javascript to set widths) to Opera.
comp.lang.c refugee
Monday, December 05, 2005
 
 
Cory, I would argue the opposite. After the initial learning curve, CSS for layout just works. Or this has been my experience.

I stopped using layout tables about three years ago. I think the turning point was when I started paying attention to designer blogs. Those guys had already solved all the sticky problem I had had, and they explained their techniques in detail.
Aapo Laitinen Send private email
Monday, December 05, 2005
 
 
Surely you can't hover in space?
Abstract Typist
Wednesday, December 07, 2005
 
 
I'm always amazed at what other programs can be productive with:  a few years ago it was IDE's without intellsense/autocompletion or realtime debugging (line-by-line execution).

A few years ago when I was looking for a new dev language people suggested langauges and IDEs that didn't have the above features. I'd be coding 300% slower without that level of assistance.

I'ave had the same experience with my (limited) use of .ASP pages. Javascript was even worse.  I don't know of any EASY way to do line-by-line execution of .asp pages (any suggestions appreciated).  I want to be able to watch each line execute and see all variable values.

That's trivial in .net or Delphi or VB 6 (hell, VB 3 *almost* does this).

Writing web apps WELL is, in my experience, very challenging.
Mr. Analogy {Shrinkwrap µISV} Send private email
Saturday, December 10, 2005
 
 
arggg  " other programs "  >> "other programERS"
Mr. Analogy {Shrinkwrap µISV} Send private email
Saturday, December 10, 2005
 
 
"I'ave had the same experience with my (limited) use of .ASP pages. Javascript was even worse.  I don't know of any EASY way to do line-by-line execution of .asp pages (any suggestions appreciated).  I want to be able to watch each line execute and see all variable values."

You can use Visual Studio.NET to do this.  One way is to hook into the ASP process (DLLHOST if you're using 2003) and put a "stop" statement in the code.  The script debugger will kick in, and you can open it in VS.NET.  From there you can step through the code, quick watch variables etc.  You'll need to have enabled script debugging for this.

You can also set up a web project, drag in your existing ASP pages, set a start page, put in break points and run your web site as if it were a normal .NET project.  You lose some stuff, but it is still a real IDE with the usual goodies.

Google "ASP Debugging Visual Studio" for the details.  I'm not sure if you can use the Express versions for this, but if you can, it's a fairly excellent Web IDE for free.
mrbloo
Monday, December 12, 2005
 
 
In these days of multitasking OS's, I personally have IE, Firefox, Safari (I'm on a Mac) and Opera open to the page I'm working on. It's no great hassle to refresh all four when I do a major change as I tend to create an empty page structure for each page with bits of code (PHP mainly, sometimes C# at work) to pull in the content dynamically.

Doing it that way it's very easy to get your layout working right especially if you populate it with Lorem Ipsum text whilst testing.

As for CSS/Tables, I use CSS for everything *except* if something is obviously visually a table then *it's a table*. Seems straightforward to me. If you need to do all your positioning in CSS then just place the table inside a div and control the div in CSS.
Karl Cartlidge Send private email
Wednesday, December 14, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz