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

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

From: Adrian Bateman <adrianba@microsoft.com>
Date: Sun, 18 Oct 2009 19:42:54 +0000
To: Jonas Sicking <jonas@sicking.cc>
CC: Tab Atkins Jr. <jackalmage@gmail.com>, Tony Ross <tross@microsoft.com>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <104E6B5B6535E849970CDFBB1C5216EB061F0F28@TK5EX14MBXC140.redmond.corp.microsoft.com>
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.
Received on Sunday, 18 October 2009 19:44:34 UTC

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