- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 21 Oct 2009 02:35:23 -0700
- To: Adrian Bateman <adrianba@microsoft.com>
- 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>
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