Providing the same UI across browsers

As a web designer and e-learning course developer, I often grapple with the notion of making my products appear the same in every browser. I’m not opposed to the idea that you should make your work look (almost) identical in every browser. After all, you’re promoting a specific design aesthetic and the last thing you want is for a browser to dictate what you can and can’t do, especially browsers you don’t even like. (I’m looking at you, IE6.)

But it’s never as simple as we’d like. Internet Explorer has that crazy CSS box model. Older versions of Firefox and Safari don’t support border-radius or RGBa.  Mac browsers use completely different scrollbars and form elements than Windows and Linux browsers. For that matter, scrollbars and form elements in Windows 2000 look completely different than XP, Vista, and Windows 7.

This is one of the reasons Flash has become so popular — it allows designers to standardize their RIA‘s UI elements across browsers.

The latest salvo in the war for controlling your browser’s look and feel is Jilion’s SublimeVideo, an HTML5 video playback system that ensures your video has the same controller across browsers. It bypasses the browser’s built-in controller in favor of Jilion’s (very slick) custom controller. Jilion’s blog states (emphasis mine):

We aim at delivering a modern and simple video-embedding solution for web developers that provides the same user experience and uniform UI across browsers.

Jilion’s work comes from the same school of thought that led designers/developers to change the look and feel of other built-in browser components such as radio buttons and checkboxes. (Guilty!)

While looking at Jilion’s fine handiwork, I was struck by a thought: If a person uses a particular browser regularly, they will be accustomed to that browser’s native controls — whether it’s for video or drop-down menus in forms — and might be thrown off by the custom controls. Maybe it isn’t such a good idea to create a homogeneous video controller for all browsers.

After all, why does a Firefox user need to have the same experience as a Chrome user? Why does an Opera user need to have the same experience as an Internet Explorer or Safari user? These people have probably never seen what a webpage looks like in a different browser, anyway. What benefit do site visitors really receive from “a uniform UI across browsers”?

If you change the default controls to match the look and feel of something your visitor has never seen before, you run the risk of creating confusion, distrust, or alienation. Even worse, if the controls are poorly made or conceived — and many are — you might make your site less usable. A cardinal sin.

The more I think about it, the real beneficiaries of a uniform UI across browsers aren’t the site visitors, but rather the designers who demand artistic control and the clients who insist the product looks the same everywhere, without understanding that it’s okay (even expected) to have some differences.

Personally, I realized 100% uniformity is an unnecessary hardship when I began adopting HTML5 and CSS3 features into pipwerks.com last year. These new features are still not supported in all browsers, and essentially forced me to give up IE6 support. (pipwerks.com uses Andy Clarke’s handy Universal IE6 stylesheet for IE6.)

I’ve come to grips with the notion that my site’s design won’t look the same in Opera 9 or IE7/8 because those browsers don’t support border-radius. My design is simple enough that the general impression is preserved across browsers, but people who use certain browsers will see a slightly less refined product. This is a-ok with me.

It should also be noted that growth in the mobile market appears to be shifting perceptions about consistency between browsers, too. Most major sites have a “mobile edition” which will look quite different than the standard website, and is most likely geared to look great on an iPhone and so-so in all other mobile devices.

CustomInput Class: Accessible, Custom-Styled Checkboxes and Radio Buttons

I’m a big fan of the Filament Group’s UI work.  They put a lot of thought into their work, and ensure everything they make is not only beautiful, but as accessible and as semantic as possible.

One of my favorite pieces of work by the Filament Group is their approach to stylized checkbox and radio <input> elements, as described in their post Accessible, Custom Designed Checkbox and Radio Button Inputs Styled with CSS (and a dash of jQuery)

The system is remarkably well-constructed, degrades gracefully, and is completely accessible if JavaScript, image loading, or CSS is disabled can’t be loaded. No small feat. Plus it remains semantically sound, with no bloated markup.

Having said all that, I’ve never actually used any of Filment Group’s UI code in my projects because of one little obstacle: they rely on jQuery.  Mind you, I’m not a jQuery hater, but I prefer MooTools and build all my major projects using MooTools. Switching to jQuery for such a small UI customization is not going to happen. I’ve often thought it would be great to build a MooTools version of Filament’s UI examples, but never had the time… until today.

I’m currently working on a new quiz system at work, and decided I’d incorporate Filament’s wonderful stylized checkboxes and radio buttons into my project, which meant it was time to roll up my sleeves and code me some Moo. 

View Demo

I made a couple of changes to the underlying JavaScript to suit a MooTools approach (and add some flexibility with the CSS selectors) but the basic premise is the same as Filament’s demo.

The following JavaScript will style ALL checkbox and radio inputs on your page. Note that CustomInput returns the collection of elements that have been styled.


window.addEvent("domready", function(){ 
    var all_styled_inputs = new CustomInput();
});

If you want to target specific parts of the page or only certain input types, pass a CSS selector as an argument:


window.addEvent("domready", function(){
    //Only style checkboxes
    var styled_checkboxes = new CustomInput("input[type='checkbox']");

    //Only style radios in a div named "walkman"
    var styled_radios = new CustomInput("#walkman input[type='radio']");
});

The CustomInput class has been fully JSLinted, and remains very close to the original jQuery version’s size. When compressed (YUI), it squeezes down to about 1.6kb. It uses ‘dollar-safe’ mode for compatibility with other JS libraries.

It has been successfully tested in the following systems:

Windows XP

  • Internet Explorer 6
  • Firefox 3.5
  • Safari 4
  • Chrome 4
  • Opera 10

Mac OS X (10.6.2)

  • Firefox 3.6
  • Safari 4
  • Opera 10.1
  • Chrome 5 (beta)

View Demo | Download Project Files

Major kudos to Filament Group for sharing their ideas with the world.

Update 3/12/2010: Fixed a typo in the JS file preventing the checkedHover class from being assigned.

Building e-learning courses: Should we use e-learning authoring tools?

This post was triggered by BJ Schone’s question “How do you build e-learning courses?

So, here’s my question: How do you build your e-learning courses? Do you build them from scratch (ex. HTML, JavaScript, etc.)? Do you use an authoring tool for the whole course structure?

This is an interesting question. Personally, I use home-grown solutions, not any particular e-learning authoring tool, though I often use e-learning authoring tools such as Adobe Captivate to create some of my animated content.

However, I think before you can really dispense advice which particular development approach is best, there are a number of factors to consider.

Questions abound

Who’s using the tools?

Development tools are generally used for two things: creating new courses and updating existing courses.

Here are two common scenarios for teams creating new courses:

  1. The team is large, with specialists. I know of some e-learning companies who have specialists for each type of project task, with strict orders to maintain the development boundaries: the instructional designer only works on curriculum development, the writer only writes, the web developer only works on the technological elements, the graphic designer only works on graphic elements, the subject-matter expert only provides insight about the topic and is not involved in any technological development tasks, etc. Apparently this makes it easier to subcontract the work and replace or augment team members where needed.
  2. The team is small, with generalists. In most cases, each person in an e-learning development team wears multiple hats: the instructional designer also does some web and/or graphic design, the subject-matter expert writes large chunks of the curriculum, etc. There often isn’t an experienced web developer on the team, so the team may be forced to learn an off-the-shelf program such as Captivate or Lectora just to get the course out the door. Sometimes, if the team can afford it or is in a time crunch, they may hire a subcontractor to do the technical work.

I think situation #1 lends itself to standard web development tools, whereas situation #2 lends itself to e-learning authoring tools. More on that in a minute.

When you get to updating courses, the question becomes: Who is responsible for maintaining the course? If the course is internal, do your coworkers know how to use the software, too? If the course was for a client, are they expected to purchase the development tools you used, and have enough technical expertise to use them?

Is portability a concern?

The portability of the content is an often-overlooked issue. When I speak of portability, I mean portability in three senses:

  1. Portability as a course from one LMS to another
  2. Portability of the content fragments within a course from one course to another
  3. Portability of the entire course to other file formats or mediums, such as XML, PDF, a database, etc.

What about accessibility?

We should never forget that there are a significant number of people taking our courses who may have special needs, including people who may be deaf, blind, color-blind, have low-vision, or other physical impairments (such as limited ability to use a mouse or keyboard).

Where are you going with this?

Buckle your seatbelts, you may not like this statement: Most e-learning tools do not promote the creation of effective courses, do not promote web standards, and do not promote accessibility; they merely make cookie-cutter course development easier for technically inexperienced course developers.

There, I’ve said it. Please don’t hate me.

Let me take a few moments to explain my thoughts on the subject.

Effective courses

Let me be clear: I am NOT saying that e-learning tools cannot create effective courses. However, I do believe that the templatized nature of most e-learning development tools leads many course developers to favor convenience over effective communication and education.

More time is spent on shoehorning course content into templates, and less time is spent on the instructional design aspects of course-building, where you stop and ask “how can I really engage the audience during the course?” (And by ‘engage’ I don’t mean just adding a simple quiz question.) Personally I don’t find the pre-built interactions in many e-learning tools to be very good. And the few that are good tend to be so overused that they get stale fast.

Since many of the developers using these authoring tools are not experienced web developers, they rarely venture ‘outside the box’ with the tool, and tend to stick to the course options presented by the software. Thus, the course developer’s options are often limited to the tool manufacturer’s instructional design preferences and notions of what constitutes a ‘proper’ course. This may lead to a boring, unimaginative course, or even worse, a course that doesn’t meet the needs of the learner.

My gist is that the tool, with its limitations and hard-coded inclinations, often winds up driving the end product more than the instructional designer. This is not unlike PowerPoint’s relationship with presenters, and how PowerPoint templates have reshaped modern notions of what a good presentation should be.

As I see it, PowerPoint presentations became the standard for two key reasons: they make presentations seem more ‘official’ or ‘professional,’ and entry-level users found the software’s templates to be very easy to use.

PowerPoint is not the answer

“Need to create an online course but don’t know how? Our tool allows you to convert your existing PowerPoint presentations into effective, engaging courses in MINUTES!”

This sounds like a dream come true for non-technical people who need to create an online course fast. But let me ask you a question: how many GOOD PowerPoint presentations have you seen that were created by non-designers? C’mon, be honest… we all know that 90% of PowerPoint’s built-in templates are ugly and hard to read.

More importantly, truly effective PowerPoint presentations are secondary (and complimentary) to a good, dynamic classroom trainer. These presentations are often simple outlines, minimalist in nature, designed to focus the attention on the presenter, not the PowerPoint file.

Simply stated, a PowerPoint presentation is designed to display a linear presentation of bullet points. How does a linear presentation of text (perhaps with a few animations thrown in) have any bearing on effective web-based training? Short answer: it doesn’t.

To expect a trainer’s PowerPoint presentation to be an effective online course without the trainer is preposterous. The trainer’s experience, charisma, presentation skills, and ability to fine-tune the course content to the needs of the individuals in the classroom is paramount.

(An ugly little secret in our industry is that quite a few course developers — and clients — don’t care about the effectiveness of the training nearly as much as they care about being able to say the training has been created and is available to the client. But rest assured: If you’re reading this, you probably aren’t one of them.)

e-learning development tools

I’m not implying that all e-learning tools follow the “let’s import PowerPoint!” model of course building, but you can’t deny how rampant PowerPoint-to-e-learning conversion tools have become in our industry. My belief is that our industry (and others) has a fixation on PowerPoint simply because of its ease of use.

The most popular e-learning tools I’m aware of today are Adobe Captivate, Articulate Presenter, Rapid Intake’s FlashForm, and Lectora. What do these all have in common? They’re geared towards users with little or no development expertise. Yes, they’re geared towards the PowerPoint crowd.

Each of the tools has its strengths, and I’m not telling people not to use them. However, I’d like to point out that each of the tools either creates files in proprietary formats (which requires purchasing their product just to make edits), or outputs courseware that doesn’t adhere to web standards and best practices.

What’s the alternative?

Using standardized web development techniques, including writing valid page markup, maintaining the separation of content from presentation via valid cascading stylesheets, and using unobtrusive JavaScript, will free your course from the shackles of a proprietary e-learning development tool format.

The most persuasive argument for using specialized e-learning development tools has been maintenance — the desire for easy updates and not relying on technical experts to handle the editing.

But I disagree; not being tied to a particular tool or proprietary format means that practically anyone with general web development experience will be able to make edits to your course or even create new courses using your system. Millions of people around the world work with HTML, and hundreds of thousands work with JavaScript. I’m willing to bet that the number of people familiar with proprietary e-learning development tools is much smaller, probably numbering in the thousands. It’s a niche.

Maintaining courses built with web standards means you can hire just about any college student or web designer to come in and make changes. It means YOU can make changes if you learn a little about HTML, or use a standards-supporting WYSIWYG editor such as Adobe Dreamweaver. The key is for your course system to adhere to web standards.

ELearning software that outputs to HTML (such as Lectora and ToolBook) do not output HTML documents that adhere to web standards. Same for many homegrown proprietary formats that have caused grumbles in offices like yours and mine. Not only are these courses harder to update, but they’re more likely to have browser compatibility issues and are less likely to be ‘future proof.’ Adobe Captivate is a good example: The latest Captivate SWFs aren’t even compatible with Flash SWFs created in Flash CS3 (publishing to ActionScript 3).

Using standard web technology means you will have the greatest flexibility possible, including the ability to embed rich media (Flash, Quicktime, etc.) whenever you like. It also means your courses will work in the largest percentage of browsers possible, including mobile devices and game consoles (depending on what type of rich media you embed in your courses).

Until e-learning development tools offer greater content flexibility and create courses that adhere to best practices for web design and accessibility, I heartily recommend using standard web development tools in place of specialized e-learning development tools.

Accessibility

Web sites built for any federally-funded project are required by law to meet a certain standard for accessibility. So why don’t we ever hear anyone talk about accessible online courses? No matter how well you think you may know your audience, don’t ever think it’s reasonable to assume no one with special needs will ever take your course.

Accessibility is imperative for a certain percentage of people. It’s a complete downer for another segment of the population, who think making a web page accessible means making the web page boring and free of any rich media. Perhaps this used to be a fair assessment, but not anymore. Many good people have put in long, hard hours making formats such as Flash SWFs and Adobe PDFs more accessible. Plus many alternative web browsing devices can now parse JavaScript, enabling some JavaScript-heavy sites to maintain a reasonable degree of accessibility (disclaimer: it really depends what you’re trying to do with the JavaScript).

What’s even better is that web standards have finally taken root over the last half-dozen years, enabling manufacturers of alternative web browsers to improve their handling of the modern web page. This means that adhering to web standards will take most of the effort out of making your site accessible! You may need to tweak a few things here and there, or put some extra effort into improving the quality of the accessibility — specialized CSS, a little extra markup, and descriptive text are good starting points — but you will have at least met a basic level of accessibility without even trying. This is way cool.

This is yet another reason why using standard web development tools is a good idea, and using e-learning-specific authoring tools may not be the perfect tools their marketing departments would have you believe.

e-learning authoring tools need an overhaul

I understand that it is simply not reasonable to expect all e-learning developers to learn code and create courses using web standards. In my experience, many self-described “e-learning developers” are either instructional designers who know very little about web development beyond using a WYSIWYG editor like FrontPage, or are web developers who know little about instructional design. “Dabblers” are the norm, and I accept it.

With such a large number of non-technical people in what is largely a technical endeavor, who can blame the non-techies for wanting to use an e-learning authoring tool? They’re cheap, they’re easy, and — most importantly — they get the course out the door. The demand is there and is undeniable. Everyone wants better tools that will make their lives easier, even me.

But we can make these tools better. MUCH better. And these better tools can lead to better courses. That’s what we ALL want, right? Isn’t that why we’re in this business?

Based on what I’ve seen, the e-learning tools industry needs to shape up and provide better solutions for its customers. Here are some suggestions.

Make your tools adhere to web standards and best practices.

Make accessibility easier

When creating courses using your product, why not include tools and gentle guidance that aids the developer in making the course more usable and accessible? For instance, you could prompt users to enter descriptive text for any image imported into the course. You could have a warning appear if the user writes a sentence in all capital letters. You could have a tip appear informing the user that the table they just imported should have a long description, and should only be used for tabular data.

Use better markup and styling techniques

Speaking of tables, the documents created by your tool should never use tables for layout! Adherence to web standards means all page styling (fonts, color schemes, etc.) should be handled by external CSS, not inline styles or deprecated font tags. You should also use JavaScript sparingly, and as unobtrusively as possible. Let the page markup (HTML) and styling (CSS) do as much of the work as possible. Avoid browser-specific code, such as Microsoft’s ActiveX, like the plague.

Allow users to export their content into easily reusable formats

If your tool adheres to web standards, it should be easy to export (most) course content to a reusable format such as XML. Allowing users to export their content to XML in turn allows the user to easily repurpose the content for different media, such as importing it into a print-based document format such as Adobe FrameMaker, using server-based conversion tools to create dynamic on-demand PDFs, or syndicating the content via RSS feeds.

Give the developer more flexibility — and encouragement — to try instructional design approaches your design team may not have thought of.

Many courses are designed to be page-turners with a few interactions scattered around. I’ll admit I’ve created my fair share of these courses. Tool manufacturers often promote their built-in templates as meeting or exceeding well-established instructional design principles. Entry- and mid-level developers in this field may actually believe your marketing spiels, and think that your templates are the holy grail. This may be good for your business, but it certainly isn’t good for the person taking the course.

Why not build more navigation and format flexibility into your tool, encouraging the user to think outside the box? Remind the user that your templates are just starting points and the real power of your tool is the flexibility it provides. Adobe Captivate’s success with its branching feature is a good example of how hungry developers are for alternatives to standard, page-tuner-style linear navigation.

Wrapping this thing up

Getting back to BJ’s original question, I use custom home-grown course solutions. This isn’t for lack of wanting a good all-round e-learning authoring tool; I just think there isn’t one out there that meets my needs yet. And until there is, I feel more confident working with standard HTML, throwing in the occasional Flash or Captivate file. I recommend this approach to others because I think it’s the most browser- and platform-neutral method, and opens up the development environment to any web developer without requiring expertise in a niche (and ultimately limiting) e-learning authoring tool.

What do you think?

Wow, OK, I sure didn’t intend to write this much. As you can see I had a few things I’ve been wanting to get off my chest for a while. If you’ve made it this far, you must be interested in this topic, too, so I ask you to kindly let me know what you think. Am I off-base here or what?

Vertical centering — without using tables!

For many years, table-based web page layouts were the rule, not the exception. They were easy to build, they worked cross-browser, and WYSIWYG editors made it a breeze to create and edit tables. CSS-based layouts didn’t really grab hold until just a few years ago, thanks to the evangelism of people like Jeffrey Zeldman and Eric Meyer.

The benefits of CSS-based layouts are very well-documented, and include increased accessibility (for surfers who use assistive technology), ease of site updates (change an entire site’s look and feel with a single stylesheet), and improved search engine rankings (search engines are able to index your content more cleanly when it isn’t surrounded by table markup).

It’s getting easier and easier to avoid table-based layouts these days, and even WYSIWYG editors like Dreamweaver have shifted gears and started including CSS-based layout templates with their software. This is way cool.

But every now and then, a developer like myself will come up against something that was SOOOO easy with table-based layouts and winds up being a royal pain with CSS-based layouts. One of these “d’oh!” moments is when you try to vertically center an element on your web page. Umm… hang on, let me rephrase that: One of these “d’oh!” moments is when you try to vertically center an element on your web page when using Internet Explorer 6.

Firefox supports CSS standards better than Internet Explorer 6 (the dominant browser), and predictably, vertical centering in Firefox is a piece of cake!

This journal entry is devoted to explaining how to get vertical centering working in both Firefox and IE6.

First, an example page.

The ingredients

There are three keys to making this work:

  1. A set of nested DIVs (yes, I know some of you are anti-nested DIV, but hey the world keeps on spinning).
  2. CSS for standards-compliant browsers (Firefox et al)
  3. A separate chunk of CSS for our old friend IE6

Nested DIVs

The first requirement is nested DIVs. You may be thinking “what’s the point of avoiding tables if I still have bloated markup?” My response is that one small set of nested DIVs isn’t nearly as bloated as a table, and using DIVs still helps you keep your markup readable for accessibility purposes and search engines. It’s a good thing! DIVs are also much more flexible should you decide to change your layout later on.

Here’s the layout in all its glory:


<body>
<div id="outer">
  <div id="container">
    <div id="inner">
      <img src="http://pipwerks.com/images/posts/indicator_green.gif" alt="Please wait" width="32" height="32" /><br />
      Loading...<br/>
      Well, not really.<br/>
      But don't I look nice centered like this?
    </div>
  </div>
</div>
</body>

The ‘inner’ DIV is what will hold your content. The ‘outer’ and ‘container’ DIVs’ sole purpose in life is to get your content centered on the page! I’ll explain this in a moment.

The CSS

Let’s look at the CSS:


body {
}

* {
   margin: 0;
   padding: 0;
}

/* macs won't see this! */
html, body { 
   height:100%;
   width:100%;
}
/* END mac */

#outer {
   height:100%;
   width:100%;
   display:table;
   vertical-align:middle;
}

#container {
   display:table-cell;
   vertical-align:middle;
}

#inner {
   text-align: center;
   width: 50%;
   margin-left:auto;
   margin-right:auto;
}

We set all elements on the page to have a default padding and margin of 0. This avoids box-model issues. We also dealt with some Mac inconsistencies with the Mac hack.

As you can see from the CSS, the body and outer elements (outer, container) are set to be 100% wide and 100% tall. The outer element is told to behave like a table (display:table), and is vertically centered using the “vertical-align:middle” property.

By nesting the ‘container’ DIV inside the faux-table, we can make the container DIV behave like a table cell: “display:table-cell”. This DIV is also set to be vertically centered using the “vertical-align:middle” property.

That’s it for the vertical centering in CSS-compliant browsers!

In this case, the ‘inner’ DIV’s CSS is purely for horizontal centering. I set the width to 50% simply because I wanted a narrow DIV, and I centered the DIV horizontally using margin-left: auto and margin-right: auto.

Remember, the code up to this point is for standards-compliant browsers, not IE6.

Dealing with our friend, Internet Explorer 6

Now, you may be thinking that writing different CSS specifically for IE harkens back to the bad old days of browser sniffers and alternate web sites, and you would be correct. However, the alternate CSS is very easy to manage, and doesn’t require a browser sniffer! Thanks to Microsoft’s implementation of conditional comments in IE, we can simply insert a chunk of alternate CSS code into a conditional comment… whatever is inside the comment will be safely ignored by any non-IE browser. Here’s an example:


<!--[if IE ]>
   <style type="text/css">
      body {
         color: #ff0000;
      }
   </style>
<![endif]-->

You can read more about conditional comments at Peter-Paul Koch’s website.

On our vertical centering example, I used the following CSS code in a conditional comment:


#container {
   height: 1px; /* required for IE to properly center vertically */
   position:relative;
   top:50%
}

#inner {
   position:relative;
   top:-50%;
}

Internet Explorer doesn’t support the “display: table”, “display: table-cell” and “vertical-align: middle” properties. To get around this, we have told IE to use relative positioning to move the ‘container’ DIV 50% down from the top of its parent DIV (‘outer’), and to move the ‘inner’ DIV negative 50% from the top its parent DIV (‘container’).

Normally these two values would simply offset each other and cause the ‘inner’ DIV’s content to be displayed at the top of the screen. However, through the magical glitches of IE, by setting the ‘container’ DIV’s height attribute, the DIV suddenly jumps down to the middle of the page, right where we want it to be! I have no idea why, but hey, it works. Here’s the proof.

Important: the height must be set BEFORE the top percentage is declared.

Externalizing the CSS

It’s always a good idea to set up your CSS in external CSS files. This helps keep your web page clean, enables you to re-use your code on other pages, and much more. The CSS contained in the conditional code can also be placed in an external stylesheet. Here’s how I set up my page:


<link href="centering.css" rel="stylesheet" type="text/css" />

<!--[if IE ]>
   <link href="centering-IE.css" rel="stylesheet" type="text/css" />
<![endif]-->

The CSS is exactly the same, but cut and pasted into two external files: centering.css and centering-IE.css.

Now my page is looking clean as a whistle, and I can reuse my code by linking my other pages to my ‘centering’ css files!

Cool, can you do that with a Flash SWF, too?

Yes, you can! Here’s an example.

The code for the Flash example is exactly the same as the first example, except for content: I replaced the contents of the ‘inner’ DIV with some dummy text, and I embedded a Flash SWF using Geoff Stearn’s SWFObject method (the best embedding method I’ve used by far!). No CSS was altered except for the body and font colors.

And there you have it… a nice, (relatively) simple way to vertically center DIVs using CSS and NO tables.

Updates

Thanks to some sharp-eyed readers, here are a few corrections and/or additions:

Update: Here is an example of a Flash SWF embedded with a transparent background. The CSS has been altered slightly: an HTML background image has been specified, and the inner DIV has been set to the exact pixel size of the Flash SWF; this properly centers the SWF and causes scrollbars to appear when a minimum width or height has been reached. Tested successfully in IE6, FF2 and Safari 3 (beta), all Windows XP.

Update 9/03/2007: For IE7, if specifying the height of the inner div, you must also specify the height of the container div in the IE-specific CSS file. For example:

In standard CSS:


#inner {
   text-align: center;
   width: 550px;
   height: 400px;
   margin-left:auto;
   margin-right:auto;
}

In IE7’s CSS:


#container {
   /* required for IE to properly center vertically,
      must match #inner height */
   height: 400px;
   position:relative;
   top:50%
}

Unfortunately, in IE7 this also produces scrollbars (IE7 thinks the page content is larger than it actually is). I plan to do some more research into this when I have the time.