IE9.js
in [JavaScript]
|
From: "Michael Haufe ("TNO")" on 27 Mar 2010 10:24 On Mar 27, 7:18 am, Hans-Georg Michna <hans- georgNoEmailPle...(a)michna.com> wrote: > I guess the question boils down to which browsers do allow host > object augmentation. Maybe the newer ones all allow it. If so, > then this may still be a way to go for those who dare to drop > support for the very old browsers. Who cares if you can shadow and/or box the object instead? You'll probably avoid more subtle issue's that way.
From: Garrett Smith on 27 Mar 2010 17:04 Hans-Georg Michna wrote: > On Fri, 26 Mar 2010 08:50:41 -0700 (PDT), Jorge wrote: > >> 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 ? > It sounds as if there was consideration that `JSON` could be a host object. It is not, and so no host object augmentation has occurred. The recent thread with subject "Re: FAQ Topic - What are object models? (2010-03-21)" covered the differences between host object and built-in object. The rewording (or redefinition, if you prefer) of those terms from ES3 to ES3 was discussed. The explanations from A. Bozhilov, R Cornford, and myself provide insight to the matter. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Hans-Georg Michna on 28 Mar 2010 14:56 On Sat, 27 Mar 2010 07:19:24 -0700 (PDT), Michael Haufe ("TNO") wrote: >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. I see your point. That leaves the question, why are the browser makers implementing something that nobody should use? (:-) Hans-Georg
From: David Mark on 28 Mar 2010 15:30 Hans-Georg Michna wrote: > On Sat, 27 Mar 2010 07:19:24 -0700 (PDT), Michael Haufe ("TNO") > wrote: > >> 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. > > I see your point. > > That leaves the question, why are the browser makers > implementing something that nobody should use? (:-) > Because the miserable JS library developers clamored for it (then whined when it did not meet their expectations, then went ahead and dumped it on top of their already buggy query engines anyway). History demonstrates that stupid things can and do happen.
From: "Michael Haufe ("TNO")" on 28 Mar 2010 15:50
On Mar 28, 1:56 pm, Hans-Georg Michna <hans- georgNoEmailPle...(a)michna.com> wrote: > That leaves the question, why are the browser makers > implementing something that nobody should use? (:-) QSA was implemented in browsers because it was a common pattern found in today's libraries, and in the competitive browser world you don't want to be the only one without parity functionality. Now whether its fundamentally the right thing to do is another question that isn't simple to answer. Personally I dislike having 2 or more embedded DSLs in the browser, but the "better" alternative is not an easy goal to obtain IMO. |