[whatwg] Avoiding new globals in HTML5 ECMAScript

Brett Zamir brettz9 at yahoo.com
Sun May 9 22:08:42 PDT 2010


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.

thank you,

More information about the whatwg mailing list