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

On Thu, Oct 15, 2009 at 6:36 PM, Tony Ross <tross@microsoft.com> wrote:
> On Thursday, October 15, 2009 at 3:49 PM <jonas@sicking.cc> wrote:
>> On Tue, Oct 13, 2009 at 9:57 PM, Tony Ross <tross@microsoft.com> wrote:
>> > Using Namespaces:
>> >
>> > Beyond allowing extended markup to be valid within HTML documents, a
>> couple of other motivations contribute to the desire to utilize
>> namespaces as a solution.
>> >
>> > The first of these is greater consistency with XML-based documents.
>> > Ideally the experience here would be as close to that experienced in
>> > XHTML as possible. This is particularly relevant with the introduction
>> > of SVG and MathML into HTML  since we can fully expect content to be
>> > directly pasted in from these document types. Without namespaces,
>> > pieces of content that aren't native to SVG or MathML won't behave as
>> > expected when accessed from script.
>>
>> I will note that HTML has been wildly more successful than XML when it
>> comes to web pages, so following XML isn't obviously the right thing
>> to do.
>
> The success of HTML is not necessarily tied to its non-support of namespaces. I agree that there are aspects of XML that are undesirable to port to HTML, such as draconian error handling, but I'm not convinced namespaces fall in this bucket. Furthermore DOM Consistency with XHTML remains one of the HTML Design Principles.

I agree that the use of namespaces is probably not a major reason for
XMLs lack of success in this market. And I buy the argument about
Design Principles.

> I truly anticipate that authors will construct HTML 5 documents with namespaces and expect them to work. Typically this will be when content has been taken from XML documents such as SVG. From an author's point of view I don't find that expectation to be much of a stretch given that HTML 5 already supports namespaces in the DOM. The HTML 5 parser currently assigns namespaces to all the elements it creates depending on the parsing context. Even certain attributes with auto-mapped namespaces can be already be created on SVG or MathML elements (xlink:title, xml:lang, etc). Heck, I can dynamically create any element or attribute in any namespace from script, even in an HTML document.
>
> 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.

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.

>> > The second motivation is to allow developers to quickly target groups
>> > of related extensions without introducing a host of new APIs. Thus a
>> > developer can now use getElementsByTagNameNS or CSS namespace selectors
>> > to target large swaths of extended content. This ties in even further
>> > with the first motivation since this matches the experience a developer
>> > would have in XHTML.
>>
>> I would actually say that this this is even more true for a solution
>> like prefixed-based naming, like <example_com_myelement>. I.e. using
>> getElementsByTagName and namespace-less selectors is even more
>> familiar to developers than their namespaced counterparts.
>
> 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?

/ Jonas

Received on Friday, 16 October 2009 22:34:32 UTC