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

On Sat, Oct 17, 2009 at 4:54 PM, Tony Ross <tross@microsoft.com> wrote:
> 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.

I've mentioned them before in this thread. But in short:

The identifying name is a tuple rather than a string (arguably this
could be fixed by changing DOM/CSS, but so far such proposals have not
been made).
The identifying name is different from what's being written in the
markup. I.e. the user writes "foo:bar" in the markup, but the
identifying name is { "somenamespaceURI", "bar" }
Copy-paste of markup becomes more fragile since it's easy to loose the
prefix-mapping in the process.

>> 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.

It's unfortunately not true that the way <svg> works in HTML hides the
complexity of namespaces. As soon as you use the DOM you still have to
ensure that you create elements in the correct namespace, or that you
use the correct namespace when querying for elements.

>> > 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.

The metadata example I agree with you. For widgets, you probably don't
want to apply the same styling to all the elements in the widget
namespace. I wouldn't imagine that you want to apply the same style
rules to the outer <foo:widget> element as you would for the
<foo:widget-button> inside the widget.

Not sure I understand the list-of-elements example.

/ Jonas

Received on Sunday, 18 October 2009 06:35:09 UTC