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

On Friday, October 16, 2009 3:34 PM, Jonas Sicking wrote: 
> On Thu, Oct 15, 2009 at 6:36 PM, Tony Ross <tross@microsoft.com> wrote:
> >
> > If we can work around the compatibility risks, why not take the next
> > step and make these two worlds even more consistent with each other?
> 
> My main concern with namespaces is that people would use them.
> Especially standards orgs. I continue to think that XML Namespaces is
> a too complex technology for the web and would prefer not to force
> them upon anyone.

I agree that XML Namespaces is more complex than simply using tag names for identity, but I'm curious as to what specifically makes you think it is too complex for the web.

> It's easy to say that no-one will be forced to use them. However that
> isn't really the case. For example the SVG WG chose to use XML
> Namespaces, and now everyone that wants vector graphics in browsers
> are forced to use XML Namespaces. I don't see why the same thing
> wouldn't happen with any other XML Namespaces based extension to HTML
> that becomes popular.

I feel HTML 5 already provides an elegant means of simplifying popular extensions based on XML Namespaces with its handling of SVG and MathML. Per your example, HTML 5 itself will enable authors to use vector graphics without a knowledge of namespaces because the SVG namespace will be assumed when an <svg> element is encountered. Other extensions could initially require the use of namespaces in markup, but then be integrated into a future version of HTML in the same manner should they become popular enough. Consequently an author would only be "forced" to use namespaces in markup for extensions that had not yet become popular enough to be integrated into HTML.

> > You're correct that with prefix-based naming, a developer could
> > easily access all elements of a single type, but that's not exactly
> > what I meant. My point was to illustrate the ease of accessing a
> > collection of related, but different elements types. For example, in a
> > prefixed world if I have my_element1, my_element2, etc, I cannot select
> > all of them without resorting to either N queries (one for each name),
> > or using a blanket query for all elements and filtering the list
> > manually (once again with a condition for each name). If those elements
> > belonged to the same namespace, I could write a single query using
> > existing APIs to select all of them at once. Furthermore, I could do
> > this from CSS in addition to script.
> 
> What is the use case for this?

That's a fair question. I have a few use cases I was specifically thinking of, but I suspect there are more. Each really depends on what the extension author is trying to do. In the case of metadata, one use case would be the ability to easily hide all metadata elements. The implementation could be a single CSS rule using a generic namespace selector to set "display: none" on all elements in the metadata namespace. In the case of a script library implementing multiple types of widgets, one use case would be the ability to easily apply styles common to all widgets. Another use case would be the ability to easily and efficiently select the list of all elements in the document that the library should act upon.

-Tony

Received on Saturday, 17 October 2009 23:55:28 UTC