W3C home > Mailing lists > Public > public-html@w3.org > October 2009

Re: ISSUE-41/ACTION-97 decentralized-extensibility

From: Shelley Powers <shelley.just@gmail.com>
Date: Wed, 28 Oct 2009 19:01:27 -0500
Message-ID: <643cc0270910281701i30ba8a7ci44d80eeea9a0099a@mail.gmail.com>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Tony Ross <tross@microsoft.com>, "public-html@w3.org" <public-html@w3.org>
On Wed, Oct 28, 2009 at 6:47 PM, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote:
> On Wed, Oct 28, 2009 at 5:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Tue, Oct 27, 2009 at 6:07 PM, Tony Ross <tross@microsoft.com> wrote:
>>> The nature of script and these libraries provides consumers with an adequate means of resolving object name conflicts should they arise. The global variable for these libraries can typically be reassigned to another variable without impacting the behavior of the library itself. Thus should two names ever conflict, a page author can just rename the first before the second library loads.
>> Hmm.. Not quite sure I follow what you're saying. Do you have any examples?
> I think his point is that typically, JavaScript libraries only expose
> a single global variable, and implement everything as methods and
> member variables of that.  So even if it turns out two people
> independently made libraries that create a "myLibrary" global object,
> you can still do
> <script src=mylibrary1.js></script>
> <script>myLibrary1 = myLibrary;</script>
> <script src=mylibrary2.js></script>
> Or something like that.  The more general point here is that with JS,
> you typically have access to the source code of the library in some
> form, at worst somewhat obfuscated, and you can always rename things
> yourself if it causes a problem.  If it's a binary program like MS
> Word or something that's interpreting the HTML, on the other hand,
> then if a naming conflict arises, you're stuck.
> However, I don't think the kind of workaround Tony is referring to (if
> I understand him right) is ever needed in practice for JS libraries,
> even if it's theoretically possible.  Namespacing really seems to me
> like a solution to a wholly hypothetical problem.

Actually, the issue of name collision in JS libraries has been under a
great deal of discussion for the last several years. In fact, the use
of a specific type of JavaScript namespacing is used when creating
libraries, to ensure that there's less likely to be a problem with
object name collision.

In addition, JS libraries are both large, and minified in order to
save space. One doesn't just crash through and make changes here and

All you have to do is search on "namespace" and "javascript" and you
find a wealth of articles on the topic dating back years -- both for
the use of namespacing from a JS perspective, and related to the fact
that some of the more popular libraries did/do not have support for
XML namespaces. And not just specific to XHTML, as one can create an
XML model rather than JSON in order to process data via Ajax.

There's nothing hypothetical about name collisions and concerns about
this in JavaScript, or the problems that inconsistent handling of
namespaces between XML (including XML), and HTML has caused in

Received on Thursday, 29 October 2009 00:01:59 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:53 UTC