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

On Wed, Oct 21, 2009 at 4:35 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Oct 18, 2009, at 12:42 PM, Adrian Bateman wrote:
>
> On Sunday, October 18, 2009 11:44 AM, Jonas Sicking wrote:
>
> On Sun, Oct 18, 2009 at 9:00 AM, Adrian Bateman <adrianba@microsoft.com>
>
> wrote:
>
> For example, on page load a library needs to enumerate all the widgets
>
> on the page and set them up. Searching the whole document once for each
>
> element that the library supports is less efficient.
>
> So you'd have multiple elements in this namespace that all meant "this
>
> is a widget"? I would have thought that for example <foo:widget>
>
> always meant a widget, and <foo:somethingelse> meant something other
>
> that goes inside the widget, like a configuration parameter or some
>
> such.
>
> I guess I can believe that wanting all elements in the extension
>
> namespace happens. I'm just not sure if its so common that it means
>
> that using prefixed localNames won't work well enough. You can after
>
> all simply use a treewalker with an appropriate filter which will
>
> return just the elements you want. This won't be as performant as
>
> getElementByTagNameNS though I agree.
>
> I meant something like <widget:datepicker>, <widget:menubar>,
> <widget:treecontrol>. This seems fairly common in JavaScript control
> libraries and finding all instances of controls provided by the library is
> necessary. Page start-up performance for this kind of behaviour is
> important. Something like this is where you might also want to style across
> elements with CSS as Tony suggested. Of course, this is only one of the
> suggested use cases but I think it's a reasonably compelling one.
>
> Seems like this use case is adequately served with class names and data-*
> attributes. Indeed, JavaScript libraries work fine today using class names
> for binding and information roughly equivalent to data-* attributes (but
> with less convenient DOM access) for configuration parameters. What would
> the use of XML-style namespaces bring to the table? Are JS library authors
> really yearning to replace nice short class names with unwieldy namespace
> URIs? That's certainly not a request I've heard.
> Regards,
> Maciej
>

In this specific case, class nor data-* would depend on luck to work.

Having written several books on JavaScript, I can say with a great
deal of confidence that one thing we can be guaranteed is that
JavaScript libraries proliferate. Now that the JS developers have a
data-* capability, we will be seeing significant numbers of clashes in
use of names between libraries. Considering that CMS systems like
Drupal and Wordpress incorporate JS libraries through the tools, as
well as plug-ins and modules, we can almost be guaranteed that name
clashes will cause significant problems, once the use of data-*
becomes more popular.

What's worse is that it will be very difficult for the person using
these plug-ins and modules to determine what the problem is.

People have been using class names for some of this now, true. And I
imagine there have been clashes because of this, but we're not
familiar with them. If there have been few, though, it was because of
luck, not because of careful thought and design.

I would rather depend on careful thought and design, then luck. I
would rather a system be in place that forces the JS or widget
developer to be aware that they're operating in the same space as
other JS or widget developers, and to plan out their functionality
accordingly.

Shelley

Received on Wednesday, 21 October 2009 12:50:48 UTC