Re: [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: > > > 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' ); > > > 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: var my_appcache = window.applicationCache; // now you can use my_appcache 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 proble
Re: [whatwg] Thoughts on recent WhatWG blog post
On Mon, Feb 7, 2011 at 6:15 PM, Adam van den Hoven wrote: > But that is exactly what has happened, or perhaps some existing pollution is > simply being codified. atob() and btoa() were first implemented years ago, I guess by Netscape, and are supported in all major browsers except IE. So they were already in the global namespace (except if you only care about IE). > 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. It would certainly make sense to have some way to include JavaScript other than adding
Re: [whatwg] Thoughts on recent WhatWG blog post
On Mon, Feb 7, 2011 at 4:36 PM, Brett Zamir 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: >> >> >> 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' ); >> > > 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
Re: [whatwg] Thoughts on recent WhatWG blog post
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: 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' ); 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
Re: [whatwg] Thoughts on recent WhatWG blog post
On Mon, Feb 7, 2011 at 12:03 PM, Aryeh Gregor > wrote: > On Mon, Feb 7, 2011 at 12:33 PM, Adam van den Hoven > wrote: > > 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)? > > 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. There is no meaningful connection between atob and window. So yes it already exists... I'm just not sure that it should. > > 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: > > > > > > 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' ); > > > > > > and so on. > > 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. > > 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. It > > would also be necessary to either enforce that these cached libraries be > > immutable or that a copy of the compiled code be made available. I > couldn't > > implement this so I'm not sure how feasible this is but I suspect that > > requiring immutability would be the easier to implement. > > What problem does this solve? How is it better than inserting a >
Re: [whatwg] Thoughts on recent WhatWG blog post
On Mon, 7 Feb 2011 15:03:55 -0500, Aryeh Gregor wrote: On Mon, Feb 7, 2011 at 12:33 PM, Adam van den Hoven wrote: ... 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. It would also be necessary to either enforce that these cached libraries be immutable or that a copy of the compiled code be made available. I couldn't implement this so I'm not sure how feasible this is but I suspect that requiring immutability would be the easier to implement. What problem does this solve? How is it better than inserting a
Re: [whatwg] Thoughts on recent WhatWG blog post
On Mon, Feb 7, 2011 at 12:33 PM, Adam van den Hoven wrote: > 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)? 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. > 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: > > > 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' ); > > > and so on. 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. > 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. It > would also be necessary to either enforce that these cached libraries be > immutable or that a copy of the compiled code be made available. I couldn't > implement this so I'm not sure how feasible this is but I suspect that > requiring immutability would be the easier to implement. What problem does this solve? How is it better than inserting a
[whatwg] Thoughts on recent WhatWG blog post
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: 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' ); and so on. 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. It would also be necessary to either enforce that these cached libraries be immutable or that a copy of the compiled code be made available. I couldn't implement this so I'm not sure how feasible this is but I suspect that requiring immutability would be the easier to implement. This would have two interesting effects. 'widgets' loaded this way could easily be taken from different libraries, this jquery accordion that mootools tree view. No having access means that it would have to require it itself, and the normal scoping would keep that version internal to itself. Second, this could reduce security risks, if the widget requires a library using some authoritative URL (say from Google's CDN), then some blackhatter who injects JS onto a page by what ever means could not modify the meaning of, say, jQuery.ajax to do something else. They would have to compromise the the source code itself which is a significantly more difficult thing to do. That is the extent of my conscious thought on the subject. I'm sure someone has a better idea than I in this regard but I thought I'd throw it out there. Adam van den Hoven
