[whatwg] Avoiding new globals in HTML5 ECMAScript

[Ian Hickson]

On Mon, 10 May 2010, Brett Zamir wrote:
> 
> Although it seems a lot of attention has been given to ensuring 
> backward-compatibility in HTML5, and while a kind of namespacing has 
> been considered in use of data- attributes (over expando properties), it 
> appears to my limited observations that global (window) properties are 
> being added without sufficient regard for backward compatibility (and in 
> any case limiting future variable naming by authors).
> 
> While I can understand the convenience of properties like 
> window.localStorage or window.JSON, it seems to me that new global 
> properties and methods (at least future ones!) should be added within 
> some other reserved object container besides "window".
> 
> While I can appreciate that some would argue that the convenience of 
> globals to authors outweighs potential conflict concerns (and I know I'm 
> not offering this suggestion very early in the process), it seems to me 
> that HTML5's client-side ECMAScript should model good practices in 
> limiting itself as far as new globals perhaps similar to how XML 
> reserved identifiers beginning with "xml", doing the same with allowing 
> one "W3C" global or maybe "HTML{N}" globals or the like ("HTML" alone 
> would no doubt be way too likely to conflict), allowing authors the 
> assurance that they can name their properties freely within a given set 
> of constraints without fear of being over-ridden later.

I agree with you in principle, but there are three other factors to bear 
in mind:

1. When we add something in the global namespace, we do get to test to see 
   if it breaks anything before making it final. It's not like we're just 
   adding things willy-nilly.

2. Other namespaces tend to be just as problematic. For example, we've run 
   into problems adding attributes to elements, even though there's really
   no reason anyone should be doing anything there.

3. If we can add to the global namespace without conflicts, it's 
   preferably to other options because it's much more convenient and 
   memorable.

These, as well as everything you say, are all taken into account when we 
add new DOM APIs.

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