• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Blog200701061216

Page history last edited by PBworks 17 years, 2 months ago

 

 

Blog List All Entries Archives by Month Photos My Notes

 

 

Designing a decent cross-browser experience
12:16pm January 6, 2007

 

 

First off, HAPPY NEW YEAR everybody! 2006 has come and gone and now we're nearly a full week into 2007. As always, it feels basically the same to me, but I guess I will join the bandwagon and write some of my resolutions here later.

 

But right now, the subject is how to design a website that is compatible across browsers. That's a rather large task, and maybe one that is impossible to do perfectly, but that's why the title says a decent cross-browser experience. You're simply not going to please everyone, so realize that fact and just do your best.

 

HTML

 

Despite the fact that most of the incompatibilities happen on the CSS level, it's still a good practice to not define your site's appearance in the HTML. First, there's uniformity between pages. Second, by keeping it simple, there's less chance of getting into some odd case that browsers will handle differently. Last, it's nice to have really old browsers at LEAST be able to read your content, if not do it in a pretty manner.

 

All modern browsers basically handle HTML just fine as long as you make sure to practice good technique, like closing all your tags. If you're designing for mobile devices, this is probably even more important, as they get picky in their parsing of (x)HTML. Even if you're NOT designing for mobile devices, it's really sexy to make compliant HTML and show it off to all your friends. I mean, check out this turn-off:

 

BAD
<select>
<option>one
<option>two
<option>three
</select>
GOOD
<select>
<option>one</option>
<option>two</option>
<option>three</option>
</select>

 

Yeah, sure, most browsers will figure out what you're talking about and handle it just fine, but it's not much trouble to type </option> after each one and make sure every opening tag has a closing tag. For stuff like <img> that traditionally didn't have closing tags, you can make your HTML standards-compliant by simply adding a / (forward slash) at the end of the tag, like so:

 

<br />
<img src="mypiccy.jpg" />

 

So once you have your nice pretty HTML that all browsers worth their salt will handle, then you get to style it with CSS.

 

CSS

 

I typically have few problems with CSS as long as I don't use too many complicated selectors. IE6, for example, will not handle either of these two cases:

 

<style>
   div.class1.class2 { font-color: green; }
   body > div.class1 { font-color: red; }
</style>

 

In the first case, it will not recognize that direction as meaning a div with BOTH classes "class1" and "class2". In the second, the child selector (>) is not recognized. To make matters worse, IE5.0 treat it like a space (descendent selector), while IE5.5 and IE6.0 ignore the declaration completely. The new IE7.0, however, DOES handle them. Oh joy.

 

Another problem I see a lot of is how to do position:fixed. The Mozilla browsers have been handling it well for a while, but Internet Explorer, had not been supporting it until IE7.0, and then, only if your document is set to "strict" mode. What's worse, if you set it to fixed in the older versions of IE, it will deprecate to static (just the default element position) and NOT absolute, which would be easier to design for. Search Google for "IE6 position fixed" and you'll see the nightmare, or go here for somebody's neat solution.

 

Scripting and Programming

 

If your page uses something like Java or Macromedia Flash, you don't really have to worry about compatibility. Being basically proprietary stuff, the programs that run them are going to do pretty much the same thing cross-browser.

 

Javascript, on the other hand, is often completely different between browsers. For example, in DOM scripting, to access the CSS float style, you do document.style.cssFloat in Mozilla, but document.style.styleFloat in IE. Most designers will set both, as it doesn't cause any errors to set an element property like that.

 

In other cases, you can often check for methods before calling them, allowing a split for different browsers:

 

<script>
function someOnloadEvent() { ...code here... }

if (document.addEventListener) {  //mozilla code
   document.addEventListener('load',someOnloadEvent,false);
}
else if (window.attachEvent) {    //IE code
   window.attachEvent('onload',someOnloadEvent);
}
else {  //if all else fails
   window.onload = someOnloadEvent;
}

</script>

 

 

Now, this example isn't entirely practical, because setting window.onload works in all browsers, but you get the point. If you needed to attach handlers to some event that was handled differently between browsers, this would be a necessary step to keep compatibility high.

 

Ultimately, you won't catch everything. And if you wanted more complete compatibility, you'd have to check in multiple browsers until you're blue in the face. That becomes a problem when you're not allowed to install multiple versions of a browser on a machine.

 

Luckily, there's a solution that doesn't require you to have a dozen different computers. However, before we get to that, you should select a few preferred browsers unless you want to go crazy.

 

Deciding on preferred browsers

 

Usually, you'll need to pick a few preferred browsers that you design for, and recommend that your surfers use at least one of those. To give a good spread, aim for two or three of the most popular browsers. Here's my design process, for example:

 

  1. I create a site that will look good in the most recent versions of Firefox (2.0) and Internet Explorer (7.0)
  2. While I'm at it, I make sure that it'll survive browsers that are a little old (Firefox 1.5 and Internet Explorer 6.0) with minimal wear and tear.
  3. Afterwards, I'll pick up Safari as much as possible to get more of the Mac crowd.
  4. I test the layout on a few other browsers and make small tweaks if possible, but I don't sweat it if Browser-With-Market-Share-of-1% can't handle me.

 

 

That changes as browsers are introduced, and your page will probably need continual revamps to stay up-to-date (and before your design gets stale). That's why it's good to have nice solid HTML, so only CSS and a little Javascript needs updating.

 

With all that said, now I can show you a few tools to let you test different browsers from one computer.

 

Testing in different browsers

 

http://browsershots.org

 

 

 

Permalink | | Top

 

 

 

 

Content (c) Jason Nguyen 2006

 

Comments (0)

You don't have permission to comment on this page.