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

For some reason Tony's message hasn't appeared on the public-html mailing list. We're not sure why. His two attempts may eventually show up but hopefully this will appear sooner.


-----Original Message-----
From: Tony Ross 
Sent: Wednesday, October 14, 2009 9:54 AM
To: 'public-html@w3.org'
Subject: Re: ISSUE-41/ACTION-97 decentralized-extensibility

First off, let me apologize for the delay in my response. In hindsight, waiting until I returned from vacation to send a proposal would have allowed me to be more engaged in the discussion. That said, I have had plenty to think about from the responses so far and should be more engaged from this point onward.

Base Requirements:

Given what has been discussed, I want to clearly state my agreement that namespaces are not the only means to achieve decentralized extensibility. In fact, I don't even think namespaces represent the bare minimum of what proponents of decentralized extensibility are asking for. The bare minimum I see, though others are free to disagree, is decentralized MARKUP extensibility. More specifically, having the ability to add custom tags and attributes to HTML markup in such a way that the document remains VALID and HTML tools can work with the markup consistently. Namespaces are one solution, but even a standardized prefixing mechanism would meet this requirement.

Why is the extension of markup more desirable than other means of extensibility? Markup provides extensibility in a way that is both familiar to web developers and easy for them to use. Furthermore, developers can then rely on the existing set of APIs they already use for normal markup in order to access and manipulate the extended content. Granted many use cases for this revolve around metadata, but content that actually renders also makes sense, particularly with respect to controls/widgets implemented by script libraries.

A concern I have seen raised here is that user agents will use such a mechanism to introduce proprietary elements and implementations. I agree that's entirely possible, but as others have pointed out, this can happen and has happened even without a formalized method for extensibility. User agents are also not the only customers for markup extensibility. Script libraries, editors, and even future standards may choose to make use of such a mechanism. Giving such extensions a standard form also increases author awareness that the markup is not native to HTML itself.

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.

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.

Compatibility:

Many have expressed the opinion that the proposal as stated will break the web. I agree that this outcome is a possibility. Rather than rejecting the proposal outright, however, I would prefer to discuss how it can be tweaked to reduce such risk. One possible approach I can see is to scale back the base proposal to be even more like what IE does today. 

I would also like to come to some consensus on what the tolerance for breakage is. One page? 100 pages? 10,000 pages? Of the billions of pages on the web, certainly any change will break some of them.

Finally I want to thank those that have shared specific compatibility concerns. I have not yet had a chance to investigate all of them in depth, but will continue to do so and reply back with my findings.

-Tony

Received on Thursday, 15 October 2009 00:17:47 UTC