A browser sniffing warning: The trouble with Acid3 and TinyMCE

A browser sniffing warning: The trouble with Acid3 and TinyMCE

In this article Hallvord Steen provides a warning about browser sniffing and why it is such a bad thing, by examining a recent bug discovered in Opera relating to compatibility with the TinyMCE editor. He also suggests a fix to this problem, involving "bug detection", a useful technique that can be applied to many other situations.

( Read the article )

The article currently says "Access denied". Unfortunately, since it looks quite interesting!

Hi JeroenH, can you get to it now? It works for me.

it still does not work "access denied"

Seems it's up now

Indeed, I can read it now, and it IS quite interesting!

Very nice to see the history behind this particularly high-profile bug. Seeing the bug-detection code is very helpful too.

This type of feature testing is definitely the way to go and has always been part of feature testing/detection. Sometimes it isn't just enough to know an API is present but it must be tested to know that it works as it should. I wrote a couple articles on similar feature testing ideas:

http://peter.michaux.ca/article/7146
http://peter.michaux.ca/article/7217

I think rather than calling it "has_range_collapse_bug" I would call it something like "ranges_supported" to be positive and thinking in terms of progressive enhancements rather than thinking in terms of graceful degradation. I find it is more productive to think about progressive enhancements.

It's working fine now. Thanks!

You have good intentions Hallvord, but if developers started going bug detection, more than half of the code in most scripts, js frameworks and libraries would be bug detection code, thanks mostly to IE, and older versions of the other browsers.

I agree with you though !

Originally posted by xErath:

but if developers started going bug detection, more than half of the code in most scripts, js frameworks and libraries would be bug detection code

Maybe But then, much of the benefit of using frameworks and libraries presumably comes from their browser incompatibility workarounds - it's a major selling point for every library, so they should do it properly.

I think most everyone would agree.
But if you want to actually get things done then browser-sniff hacks are inevitable.
So just make opera not report itself. Isn't the problem a much bigger issue?

Ideally no browser would report itself, wasn't that how things were originally?

There are no standards. The word standard should be excised from the lexicon.
At least the computer lexicon.

Originally posted by PadreSol:

if you want to actually get things done then browser-sniff hacks are inevitable

I'm arguing that many if not most of the problems you need to work around can be detected without browser sniffing. If you can pull that off, your script will be technically sounder (plus it will be more likely to work without bugs in IE 12..)

There are a few problems with feature detection and bug detection. The example that is displayed in this article is a good case where we should have used bug detection since we should have known that Opera would eventually fix the bug.

The problem is that feature detection will fail when common javascript libraries like prototype or mootools are used since they patch in things that they feel are missing in the default API. So if we then look for a specific feature using something like:

if (document.attachEvent)
   yada;
else
   yada;

The above statement might run the first code chunk on non IE browsers even if we look for a IE specific feature since some odd script might have patched the document object and added in an attachEvent just to be more "compatible" but it might then instead produce odd bugs. The hasOwnProperty doesn't work correctly on IE on native objects so it can't be used in the above case.

There are two problems with bug detection some bugs can not be detected such some bug that craches the browser or produces some result that can't be reverted. The other problem is that the code size will increase a lot the suggested opera detection in this article is nice but it's large and if we had such code chunks for each little bug out scripts would be 10 times larger or more and our user base is already nagging about the script size.

But anyway, good article and feature and bug detection is the still the way to go if it's possible but I don't think the subject is blank and white sometimes you need to do sniffing but most of the time we don't need it and shouldn't use it.

Good points

Originally posted by Moxiecode:

The above statement might run the first code chunk on non IE browsers even if we look for a IE specific feature

In some cases it might be possible and better to look for the feature you're going to use. You are not in any case guaranteed that all browsers with native support for attachEvent support everything IE does - or have the same bugs, depending on what you are looking for. Opera, for one, supports attachEvent but still doesn't have all features or bugs IE has.

code size will increase a lot the suggested opera detection in this article is nice but it's large and if we had such code chunks for each little bug out scripts would be 10 times larger

Indeed, though by exactly how much the code would grow I haven't tested this enough to work out. It would be an interesting study to take some popular library script, try to replace all instances of browser sniffing with equivalent bug/feature detection and see what impact it had on size and performance. I hope in most cases the trade-off would be worth it, especially as one of the major reasons I'd deploy something like TinyMCE instead of just an <iframe> with designMode on is to avoid having to deal with browser differences..