[whatwg] Thoughts on recent WhatWG blog post

On Mon, 7 Feb 2011, Adam van den Hoven wrote:
> 
> 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.

Modifying JS to include them would make no difference, in practice. For 
example, parseInt() is on window, as is Object, String, indeed everything 
is on window. Window is the global object.


> 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>
> 
> and so on.

We try to do that (but with far less verbosity) already. For example, the 
ApplicationCache API is not on Window, you have to get a handle to it:

   <script>
   var my_appcache = window.applicationCache;
   // now you can use my_appcache
   </script>

As a shorthand, you can also just directly access things on 
applicationCache:

   window.applicationCache.status

The same applies to many other features, e.g. session history features are 
accessed via window.history, features relating to the UA and the 
environment as accessed through window.navigator, etc.


> Further, in CommonJS, the library has to export an object in order to 
> make it available. If we could define things in such a way that the 
> browser compiled the library independent of the page that loads it, the 
> browser could cache the *compiled* code and provide that to the browser 
> page.

That kind of thing has been tried in the past, but in practice it turns 
out there are too many versions of too many libraries to actually make 
this workable, as I understand it.


On Mon, 7 Feb 2011, Adam van den Hoven wrote:
> On Mon, Feb 7, 2011 at 12:03 PM, Aryeh Gregor wrote:
> >
> > Generally we try not to create new objects in the global namespace. 
> > Instead, we try sticking them on other preexisting global objects in 
> > most cases.
> 
> But that is exactly what has happened, or perhaps some existing 
> pollution is simply being codified.

In this case, yes.


> There is no meaningful connection between atob and window. So yes it 
> already exists... I'm just not sure that it should.

Window is just the global object. Things that have no meaningful 
connection to anything go on window because there's nowhere else to put 
them ("require()" would have to go on window too). I wouldn't get too 
caught up in the name "window".


> > What problem does this solve?  The problem of global namespace 
> > pollution?  Why not just define window.html (or some other single 
> > name) and make all the functions methods of that object?  This is kind 
> > of what we're doing already, although not so systematically.  Your 
> > solution seems overly complicated.
> 
> You could collect them into a single global object, and that was something I
> though about, as well. But I think that this is a more generally applicable
> solution. There are many libraries that do nothing but load javascript from
> within javascript. They all do it by writing a script tag to the DOM. I
> believe this is a code smell. Having a consistent way to do this sort of
> thing would improve the lives of a lot of code developers and create some
> consistency between what is happening on the server side as well.

I don't really understand what problem you are describing here.


On Tue, 8 Feb 2011, Brett Zamir wrote:
>
> [it would be good to have a script importing feature that] does not 
> burden the user with needing to avoid names which could end up being 
> co-opted by HTML in the future.

My understanding is that this is being addressed in JS itself.


> (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.)

I think our first priority must be to the Web. If we try to make HTML 
appropriate for multiple different unrelated platforms, we will end up 
pulled in multiple directions. Naturally if there are multiple equally 
good ways to design a solution for a problem faced by the Web, we should 
pick the solutions that work for the most other environments as well, but 
that's not as strong a commitment as I think you are describing above.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 11 May 2011 15:42:17 UTC