IE9.js
in [JavaScript]
|
From: David Mark on 26 Mar 2010 11:15 Scott Sauyet wrote: > 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. My condolences. Where are they now? :) > It was a > heavy-weight solution and a large download without the benefit of a > CDN. If you want to use a CDN, sign up for one. Don't rely on the hosts of others. > But it worked well. Dean was responsive to questions and quick > to fix problems. Worked well and problems don't seem to fit together. > It was very liberating to develop in Firefox with > Firebug and have things just work in IE5.5/6. Just work? Per your observations I assume. > I really did run into > few issues. That you knew about at the time. > > David Mark said that Dean Edwards "uses browser sniffing for > _everything_". He does (or at least he did as recently as a year ago). > All I really remember was that he didn't feature test, > using navigator.appVersion for everything. You can't "feature test" _anything_ using the navigator object, except the functionality of that (largely useless) object. > 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. The issue is including it at all. Who needs a heavy-weight "solution" that only spackles over observed problems in IE? > > On the other hand, I haven't often found a need for it, and it > probably wouldn't play well with other scripts. It definitely won't. > > 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. Definitely ill-advised to do _that_. > 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. > It is.
From: Gregor Kofler on 26 Mar 2010 11:14 Hans-Georg Michna meinte: > 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. How is that supposed to work reliably? If a browser doesn't know document.getElementById() and doesn't allow host object augmentation, how could one write a "replacement"? You would need another abstraction layer and you end up with your dreaded "cross-browser libraries". Gregor -- http://www.gregorkofler.com
From: Jorge on 26 Mar 2010 11:50 On Mar 26, 4:14 pm, Gregor Kofler <use...(a)gregorkofler.com> wrote: > Hans-Georg Michna meinte: > > > 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. > > How is that supposed to work reliably? If a browser doesn't know > document.getElementById() and doesn't allow host object augmentation, > how could one write a "replacement"? > You would need another abstraction layer and you end up with your > dreaded "cross-browser libraries". But var JSON= { parse: function () {..}, stringify: function () {..} } is NOT "host object augmentation". Or is it ? -- Jorge.
From: Hans-Georg Michna on 27 Mar 2010 08:18 On Fri, 26 Mar 2010 09:59:18 -0400, David Mark wrote: >Hans-Georg Michna wrote: >> 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. How about performance? Can you afford to ignore querySelectAll, if it is there, and use much slower JavaScript code? > 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. ;) Yes, I agree. Sometimes they are useful though (at least for demos :-). Hans-Georg
From: "Michael Haufe ("TNO")" on 27 Mar 2010 10:19
On Mar 27, 7:18 am, Hans-Georg Michna <hans- georgNoEmailPle...(a)michna.com> wrote: > How about performance? Can you afford to ignore querySelectAll, > if it is there, and use much slower JavaScript code? What browser do you know of that has QSA that also has "slow" JavaScript in comparison? If the API is inconsistent across implementations then yes, and guess what, they are for complex queries. If you avoid complex queries then you aren't gaining much of an advantage using QSA over the other APIs already available. |