IE9.js
in [JavaScript]
|
From: Hans-Georg Michna on 26 Mar 2010 09:34 Has anybody looked into the idea, promoted by Dean Edwards' IE9.js library and its precursors, to write a JavaScript layer for specific browsers to make them conform to current standards? To give just one example, if they don't have querySelectAll, let the JavaScript layer provide that function. If the browser doesn't have JSON, add that functionality as well. (json.js does exactly that already.) And so on. I guess that the Internet Exploders have the greatest need for such wrapping, so it may not be surprising that Dean Edwards wrote his stuff for them. The downside may be that one would have to write one such layer for each standards-dodging problem browser, and perhaps this already answers my question. However, one could think about writing such a layer for most or all of them. So instead of writing a library with new functionality, a minimalistic approach could be to write only a library that creates the standard-conformant functionality of an ideal browser. Has anyone here used IE9.js or one of its older brethren? Hans-Georg
From: David Mark on 26 Mar 2010 09:59 Hans-Georg Michna wrote: > Has anybody looked into the idea, promoted by Dean Edwards' > IE9.js library and its precursors, to write a JavaScript layer > for specific browsers to make them conform to current standards? I've looked at it and dismissed it. Is he really at that again?! It's a completely backwards strategy (and he uses browser sniffing for _everything_, calling it "pragmatism"). You don't step all over the differences (not to mention host objects) in browsers. Your script (and others that must coexist with it) must be able to see those differences and act accordingly. > > To give just one example, if they don't have querySelectAll, let > the JavaScript layer provide that function. If you must use queries and have a query engine, you use that and forget about QSA. That's the best strategy. Unfortunately, most libraries rushed to pile incompatible QSA on top of (already buggy as hell) query engines, creating additional inconsistencies which will lead to lots of variations in behavior between new and old browsers (the opposite of what you want). And, of course, the safest bet is to forget all about CSS selector queries in the first place. ;) > If the browser > doesn't have JSON, add that functionality as well. (json.js does > exactly that already.) And so on. You don't do it by augmenting host objects. You create wrappers. > > I guess that the Internet Exploders have the greatest need for > such wrapping, so it may not be surprising that Dean Edwards > wrote his stuff for them. But he did it all wrong (and with browser sniffing to boot). :( > > The downside may be that one would have to write one such layer > for each standards-dodging problem browser, and perhaps this > already answers my question. That's another downside. Context, context, context. ;) > > However, one could think about writing such a layer for most or > all of them. So instead of writing a library with new > functionality, a minimalistic approach could be to write only a > library that creates the standard-conformant functionality of an > ideal browser. > > Has anyone here used IE9.js or one of its older brethren? Dear God no (at least I haven't). Do not accept scripts from the JS "MacGyver" as they are novelties at best and monumental blunders at worst.
From: "Michael Haufe ("TNO")" on 26 Mar 2010 10:40 On Mar 26, 8:34 am, Hans-Georg Michna <hans- georgNoEmailPle...(a)michna.com> wrote: > Has anyone here used IE9.js or one of its older brethren? I tried IE7.js and IE8.js during a time crunch on a particular project in the past....and it didn't work as well as advertised. Sure, the samples looked nice, but once it was plugged into a real life page it broke some things unexpectedly (one of them being FCKEdit). Sure its easy to claim that the page was built horribly before-hand, but most of the interwebs is. Causing unintended side-effects is never justified, regardless of the excuse.
From: Scott Sauyet on 26 Mar 2010 10:54 On Mar 26, 9:34 am, Hans-Georg Michna <hans- georgNoEmailPle...(a)michna.com> wrote: > Has anybody looked into the idea, promoted by Dean Edwards' > IE9.js library and its precursors, to write a JavaScript layer > for specific browsers to make them conform to current standards? I used his IE7 on several projects a number of years ago. It was a heavy-weight solution and a large download without the benefit of a CDN. But it worked well. Dean was responsive to questions and quick to fix problems. It was very liberating to develop in Firefox with Firebug and have things just work in IE5.5/6. I really did run into few issues. David Mark said that Dean Edwards "uses browser sniffing for _everything_". All I really remember was that he didn't feature test, using navigator.appVersion for everything. The script was supposed to be included only with appropriate conditional comments; that was certainly important, but it was never an issue for me at the time. On the other hand, I haven't often found a need for it, and it probably wouldn't play well with other scripts. The more general idea is a common one; I tried to do it several times myself, but I eventually decided that I really would rather not mess with so many native and host prototypes. Most of the libraries out there no longer really try too hard to smooth over the browser differences, instead implementing their own APIs on top of the many browser environments. I think that's probably the best way to go. -- Scott
From: David Mark on 26 Mar 2010 11:00
Michael Haufe ("TNO") wrote: > On Mar 26, 8:34 am, Hans-Georg Michna <hans- > georgNoEmailPle...(a)michna.com> wrote: > >> Has anyone here used IE9.js or one of its older brethren? > > I tried IE7.js and IE8.js during a time crunch on a particular project > in the past....and it didn't work as well as advertised. Sure, the > samples looked nice, but once it was plugged into a real life page it > broke some things unexpectedly (one of them being FCKEdit). Sure its > easy to claim that the page was built horribly before-hand, but most > of the interwebs is. Causing unintended side-effects is never > justified, regardless of the excuse. > Yes, as many scripts out there are built on unfortunate object inferences (another form of browser sniffing), it is ill-advised to step all over the host environment and cause other scripts to fork in new and unexpected ways. And is it any wonder that there is a 7, 8 (and now 9) version? :) That's what making unfounded correlations between the UA string and features will do for you. It's confusing as hell too. If you are using ie8.js and a user is running IE8 in IE7 mode, what happens? What about IE9? Do you have to overwrite ie8.js with ie9.js or do you run both? And what happens when IE10 comes out? Do you and your users have to upgrade (scripts and browsers respectively) to keep in sync? Then there are the non-IE browsers that have similar holes and IE clones (embedded MSHTML) with unexpected (or changed) UA strings. What a boondoggle. Gives me a headache just pondering such futility. How such things are still being pushed (with a straight face) in 2010 is beyond my comprehension. |