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

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 21 Oct 2009 02:35:23 -0700
Cc: Jonas Sicking <jonas@sicking.cc>, "Tab Atkins Jr." <jackalmage@gmail.com>, Tony Ross <tross@microsoft.com>, "public-html@w3.org" <public-html@w3.org>
Message-id: <647FF942-F093-4157-B05D-A4FCD7EED340@apple.com>
To: Adrian Bateman <adrianba@microsoft.com>

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
Received on Wednesday, 21 October 2009 09:36:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:09 UTC