[whatwg] Thoughts on recent WhatWG blog post

On Mon, Feb 7, 2011 at 4:36 PM, Brett Zamir <brettz9 at yahoo.com> wrote:
> 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).

Note that JavaScript is currently growing a module system as part of
ES-Harmony. I don't think we want pre-empty that on a DOM-level.

/ Jonas

Received on Monday, 7 February 2011 16:49:50 UTC