Universal Feature Detection
David Foley wrote:
Please forgive me if I'm polluting the list, and re-direct me if I am, but considering that there has been so much focus on browser implementation, that JavaScript is also employable in various 'environments' (IDE's, Servers etc.) and that all of these environments avail different features to developers, that a universal / standard feature detection API, perhaps through a standardised global Environment object, would be prudent.
Are there any plans to do such?
There will probably be some kind of module system in ES-Harmony (which will be prototyped before then). It would make sense for that to support querying whether a given module is available, its version, and other metainformation about it.
David Foley wrote:
Just to clarify, are you speaking about there being a standard way to query modules in general, in which case multiple modules could be tested for availability and then queried (of course), or are you suggesting that there would be a single top-level object that you could query for a specific module?
A module system is likely to require some definitions in the global namespace. Whether or not they are accessed via a single object is less important than that the functionality, I think.
On Wed, Apr 29, 2009 at 5:30 AM, David-Sarah Hopwood <david-sarah at jacaranda.org> wrote:
David Foley wrote:
Please forgive me if I'm polluting the list, and re-direct me if I am, but considering that there has been so much focus on browser implementation, that JavaScript is also employable in various 'environments' (IDE's, Servers etc.) and that all of these environments avail different features to developers, that a universal / standard feature detection API, perhaps through a standardised global Environment object, would be prudent.
Are there any plans to do such?
There will probably be some kind of module system in ES-Harmony (which will be prototyped before then). It would make sense for that to support querying whether a given module is available, its version, and other metainformation about it.
Ihab Awad and I made an initial proposal for a module system for Harmony in January, and presented it to TC39.
Proposal: docs.google.com/Doc?id=dfgxb7gk_34gpk37z9v&hl=en Presentation: docs.google.com/Presentation?docid=dcd8d5dk_0cs639jg8&hl=en
Since then, we've been working closely with a group called ServerJS that is creating a standard library for server-side JavaScript, with participants working on prototypes for {Spider,Trace}monkey (Flusspferd, GPSEE), V8 (v8cgi, k7), and Rhino (Helma NG, Persevere, Narwhal). They've converged on a module system specification that is very close in form to the initial phase of our proposal (that is, without syntactic sugar). The proposal and links to the relevant discussions, which have been extensive, are on the Moz wiki:
wiki.mozilla.org/ServerJS/Modules/SecurableModules, wiki.mozilla.org/ServerJS/Modules, wiki.mozilla.org/ServerJS
The proposal does not require augmentation to the global name space, but it might be desirable. In the proposal, there's a "require" free variable in the module, and various prototypes inject the free variable into the module's scope, some as an argument to the module factory function, some as a member of a fresh context object begotten of global. So, within modules, there's no need for a global variable. There are a couple known options for loading the "main", or initial module. One of them is to add a require method to the global object. Another is to introduce a variant of the <script> tag that loads a
module instead of a global script. Chiron, my client-side prototype, uses a script tag to bootstrap a module loader and loads the module in the <script src> query string.
Regarding feature testing, the module system might be useful since the "platform", albeit browser, could provide features as modules, in which case calling "require" on that module's identifier would throw an error. Some prototypes have a "require.isLoaded(id)" method that could be used to test whether modules provided by the platform have already been loaded, without having to catch a require error.
However, these ideas probably don't obviate the need for a feature testing system for layout, rendering, event, and other features and quirks that might not be neatly distinguished based on the availability of a module.
Kris Kowal
Please forgive me if I'm polluting the list, and re-direct me if I am,
but considering that there has been so much focus on browser
implementation, that JavaScript is also employable in various
'environments' (IDE's, Servers etc.) and that all of these
environments avail different features to developers, that a
universal / standard feature detection API, perhaps through a
standardised global Environment object, would be prudent.
Are there any plans to do such?
Such an object could be decoupled from vendor plug-in architectures,
perhaps even providing an interface as simple as:
Environment.featureIsSupported(featureName:[String], featureVendor: [String, null], majorVersion:[Number, null], minorVersion:[Number,
null], revision:[Number, null]) : Boolean
Of course, it would be up to vendors to decide just how the method
would return true or false under certain conditions, but its not hard
to see how such an interface could be useful to detect DOM
capabilities, vendor plug-in availability or even native proprietary
features supported by an 'environment'. A universal way to detect
environmental variations would be a very useful thing, IMHO.
Best
David.