On 2/8/2011 1:33 AM, Adam van den Hoven wrote:
Hey guys,
I was reading the blog today and something I read (
http://blog.whatwg.org/whatwg-extensibility) prompted me to signup to the
list and get involved again. What follows is not exactly well thought out
but I'm hoping that it will spark something.
window.atob() and window.btoa() feel wrong, so does
window.crypto.getRandomUint8Array(length), not because they're not useful
but because there is no answer to 'what does converting binary data to a
base 64 string have to do with window?' beyond 'nothing but where else would
it go?'.
In reality all these belong to javascript, but modifying JS to include them
is not feasible. Also, what if I don't want to do crypto in my code, why
should I have all that lying around (not that its a hardship but why pollute
the global namespace)?
I think that we would all be better served if we were to introduce something
like CommonJS to the browser, or perhaps a modified version of the require()
method. This would allow us to move the crytpo and the atob/btoa into
specific modules which could be loaded using:
<script>
var my_crypto = window.require( 'html:crypto' ); //or however you wanted to
identify the 'crypto library defined by html'
var my_util = window.require( 'html:util' ); // my_util.atob();
var $ = window.require( '
https://ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js' );
</script>
I really like this approach of using require() for namespacing. Besides
being semantically more accurate, the approach looks to the future as
well, in that it does not burden the user with needing to avoid names
which could end up being co-opted by HTML in the future. (Also, just
because WhatWG may verify names are fairly unique or unique on the
public web, does not mean they are catching HTML uses off the web and
for which there could be conflicts; abdicating responsibility for
effects of such apps just because it is not within the scope of the spec
would I think be rather shoddy stewardship of a language relied on for
many purposes.)
Also, whatever the caching behavior, I like the idea of having a simple
way of importing remote scripts dynamically, without having to define
some wrapper for XMLHttpRequest ugliness each time one wishes to use
such a basic feature, such as to ensure one's application stays modular
(particularly for reusable libraries where the library does not wish to
burden the user with needing to specify multiple script tags).
The final and even main reason I like and had wanted to suggest this
approach is because it is neatly compatible with another idea I think
the web (and off-web) needs: a formal way to import proprietary objects
(e.g., such as specific browser vendor(s) or browser add-ons might make
available), with the potential for fallback behavior, with require()
throwing distinct exceptions such as "NotSupported" (the default for
unrecognized modules) or "UserRefused" (for privileged features a
browser or add-on might wish to make available from the web but which a
user specifically declined).
Maybe a second argument to require() could be specified to allow for an
asynchronous callback (where one did not wish to keep checking for the
setting of a particular property or force the user to wait).
Brett
