This topic has been closed. No new entries allowed.
Reason: You can now post comments on articles on Dev Opera
You need to be logged in to post in the forums. If you do not have an account, please sign up first.
A browser sniffing warning: The trouble with Acid3 and TinyMCEIn 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 )
Originally posted by shadowk:
it still does not work "access denied"
*sigh* - somewhere along the line, a bug has been introduced into dev.opera.com, which has stopped me from publishing articles properly. The systems folk are working on it now.
Developer Relations Manager
Editor, dev.opera.com and labs.opera.com
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.
14. July 2008, 22:07:15 (edited)
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.
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..)
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.
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..