[whatwg] Avoiding new globals in HTML5 ECMAScript
Brett Zamir
brettz9 at yahoo.com
Sun May 9 22:08:42 PDT 2010
Hello,
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,
Brett
More information about the whatwg
mailing list