Websites That Archive Cross-Browser, Cross-Platform CSS/Js Bugs

What will cause a site to look and act OK in IE but not in Firefox?

First thing, you'll need Firebug, which is an extremely helpful debugging tool for Firefox. With that, you'll be able to debug and set breakpoints in your Javascript. You can also set Firebug to break on errors so you'll be able to track those down.

From there, I suggest validating your HTML and CSS, which will help you pinpoint invalid markup that is likely not cross browser.

W3C HTML Validator
CSS Validator

Also, there is a handy tool called jslint which helps track down Javascript "code smells" that should be refactored.

How can I draw vertical text with CSS cross-browser?

Updated this answer with recent information (from CSS Tricks). Kudos to Matt and Douglas for pointing out the filter implementation.

.rotate {
  -webkit-transform: rotate(-90deg);
  -moz-transform: rotate(-90deg);
  -ms-transform: rotate(-90deg);
  -o-transform: rotate(-90deg);
  transform: rotate(-90deg);

  /* also accepts left, right, top, bottom coordinates; not required, but a good idea for styling */
  -webkit-transform-origin: 50% 50%;
  -moz-transform-origin: 50% 50%;
  -ms-transform-origin: 50% 50%;
  -o-transform-origin: 50% 50%;
  transform-origin: 50% 50%;

  /* Should be unset in IE9+ I think. */
  filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=3);
}

Old answer:

For FF 3.5 or Safari/Webkit 3.1, check out: -moz-transform (and -webkit-transform). IE has a Matrix filter(v5.5+), but I'm not certain how to use it. Opera has no transformation capabilities yet.

.rot-neg-90 {
  /* rotate -90 deg, not sure if a negative number is supported so I used 270 */
  -moz-transform: rotate(270deg);
  -moz-transform-origin: 50% 50%;
  -webkit-transform: rotate(270deg);
  -webkit-transform-origin: 50% 50%;
  /* IE support too convoluted for the time I've got on my hands... */
}

How do I detect the user’s browser and apply a specific CSS file?

If you have to detect browsers just to apply CSS, then you might want to rethink your CSS before going to browser-specific stylesheets. All it takes is for one browser to mimic another's user agent string, or a new version to be released, and everything breaks. Use the current standards and validate your code (http://validator.w3.org/), and you'll have to worry about far fewer cross-browser issues. Even just using  without a version number could break the layout in later versions.

That being said, if you want to style the page differently based on what CSS features are available, take a look at Modernizr. This way, you're only checking features, which won't be broken if a new version of the browser is released.

If all else fails and you really need to detect the visitor's browser, try jquery.browser. It's built into jQuery, and is simple to use. http://api.jquery.com/jQuery.browser/.

Why JavaScript rather than a standard browser virtual machine?

Well, yes. Certainly if we had a time machine, going back and ensuring a lot of the Javascript features were designed differently would be a major pastime (that, and ensuring the people who designed IE's CSS engine never went into IT). But it's not going to happen, and we're stuck with it now.

I suspect, in time, it will become the "Machine language" for the web, with other better designed languages and APIs compile down to it (and cater for different runtime engine foibles).

I don't think, however, any of these "better designed languages" will be Java, Python or Ruby. Javascript is, despite the ability to be used elsewhere, a Web application scripting language. Given that use case, we can do better than any of those languages.

IE9 Acid 3 test?

Microsoft's position has been the same for a while now. They are focusing on meeting the needs of their users by attempting to fix the bugs that manifest themselves most often. Additionally, they are trying to add support for the most requested features.

They say in your first link "As we said at MIX10, we will continue to build standards support into the IE9 platform and as a byproduct our ACID3 score will increase." and I have heard them say this elsewhere as well.

They are NOT "coding to the test". They are not going to attempt to fix the particular parts of the ACID 3 that are failing. Rather, they are attempting to improve IE 9 as a whole by addressing the failures they see as most important. Only as a consequence of that will the ACID score improve. I think this is a good strategy. If it takes 1000 programmer-hours to fix an oddball rendering error in ACID 3, but that same amount of time could fix 2 or 3 really POPULAR bugs that ACID 3 does not address (it's not designed to be comprehensive), I would think their resources are better spent on those more popular bugs.

Obviously what their priorities ought to be could be endlessly debated. As can the amount of success they are having. So let's not even go there. :)

Update: I'd like to back up my statement that Acid 3 is not designed to be comprehensive with this citation: From http://www.webstandards.org/2008/10/02/dowehaveawinner/

"Acid3 was not meant to be the one and only indication of a browser’s performance. In fact many other test suites are far more important."

and

"Many subtests are high on a developer’s wish list: Full CSS 3 selectors support, media queries, SVG fonts. Admittedly a few others test edge cases and more esoteric features – but the test was supposed to be a significant challenge!"

Although I am not an IE user, it's better for us all if Microsoft sticks to improving the important stuff and skips the tests that check for "esoteric features".

Dynamically load a JavaScript file

You may create a script element dynamically, using Prototypes:

new Element("script", {src: "myBigCodeLibrary.js", type: "text/javascript"});

The problem here is that we do not know when the external script file is fully loaded.

We often want our dependant code on the very next line and like to write something like:

if (iNeedSomeMore) {
    Script.load("myBigCodeLibrary.js"); // includes code for myFancyMethod();
    myFancyMethod(); // cool, no need for callbacks!
}

There is a smart way to inject script dependencies without the need of callbacks. You simply have to pull the script via a synchronous AJAX request and eval the script on global level.

If you use Prototype the Script.load method looks like this:

var Script = {
    _loadedScripts: [],
    include: function(script) {
        // include script only once
        if (this._loadedScripts.include(script)) {
            return false;
        }
        // request file synchronous
        var code = new Ajax.Request(script, {
            asynchronous: false,
            method: "GET",
            evalJS: false,
            evalJSON: false
        }).transport.responseText;
        // eval code on global level
        if (Prototype.Browser.IE) {
            window.execScript(code);
        } else if (Prototype.Browser.WebKit) {
            $$("head").first().insert(Object.extend(
                new Element("script", {
                    type: "text/javascript"
                }), {
                    text: code
                }
            ));
        } else {
            window.eval(code);
        }
        // remember included script
        this._loadedScripts.push(script);
    }
};