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

On Oct 22, 2009, at 2:22 PM, Tony Ross wrote:

> Given some of the comments in this thread, I'd like to step back and  
> try to get consensus on the core problem. Specifically I want to  
> know whether or not the group feels providing some sort of a  
> solution for decentralized extensibility, in particular  
> decentralized extensibility of markup, is important.
>
> In short, should HTML 5 provide an explicit means for others to  
> define custom elements and attributes within HTML markup?

I don't think there is consensus on the answer to this question.  
Clearly different people have different opinions on whether offering  
such a capability is good, bad or irrelevant.

> Note that supporting decentralized markup extensibility does not  
> necessarily mean you feel XML Namespaces are the appropriate  
> solution. Other ideas have been shared and there are certainly many  
> possible solutions, each with their own pros and cons. For the  
> moment let's put these discussions aside. If we cannot agree on the  
> problem, then debating the technical details of a potential solution  
> is pointless.

I think it might be possible that we can find a solution that everyone  
is satisfied with (or at least can live with) without necessarily  
agreeing on the basic principles of extensibility. Indeed, that's what  
we will probably have to do. The HTML Working Group has too many  
diverse constituencies for us to reach full agreement on our premises.

If you'd like to survey the range of opinion though, here are my own  
(purely personal) views about extensibility:

- I think it's good to allow other standards to define new HTML  
elements and attributes (not necessarily W3C standards, but using some  
form of open standards process), and have the resulting markup still  
validate. The standards process itself can prevent namespace conflicts  
in this case. HTML5 already allows for this though, so it doesn't need  
a lot of discussion.

- For purely private extensions, I think allowing custom attributes is  
reasonable, but allowing custom elements could be problematic. The  
reason is as follows. Let's say two vendors define different custom  
attributes with the same effect, perhaps using some sort of prefix.  
It's practical to put both on an element. If a similar feature is ever  
standardized, you can include that too, without conflict. CSS vendor  
extensions work the same way - you can specify multiple prefixed  
properties without a problem. For elements, it's not so simple.  
Unknown elements (unlike unknown attributes) already have some  
behavior in HTML. Writing two different custom elements nested, or  
next to each other, won't necessarily give the results you want. So  
differences like that have to be patched over by script or by serving  
different content to different user agents. Nonstandard extensions  
have a notable tendency to eventually be standardized, and sometimes  
changed in the process, even if they were originally considered  
totally proprietary. So we need to think about such considerations.  
When considering the possibility of eventually folding in custom  
markup extensions into standards, I think custom elements are  
considerably more problematic than custom attributes. I also can't  
think of a lot of use cases for custom elements that couldn't be  
served by a standard element with custom attributes, or a special  
"class" value, or perhaps special RDFa or Microdata markup. Thus, I  
would prefer we only cater to custom attributes. Note though: CSS  
doesn't make vendor-prefixed properties valid, it just defines their  
form and promises that the standard won't conflict with a properly  
vendor-prefixed property. I think this is an impractical choice, and  
we should make prefixed attributes valid.

- For privately defined custom attributes, I think we should define  
some sort of prefix convention to reduce the possibility of accidental  
conflict. Since data-* attributes are a form of custom attribute, I  
think the spec should recommend that reusable libraries use a  
convention of data-PREFIX-ATTRIBUTE where VENDOR is a per-library  
prefix, and ATTRIBUTE is the actual attribute name intended. I could  
also imagine a more concise prefix convention like -PREFIX-ATTRIBUTE  
or PREFIX-ATTRIBUTE or PREFIX:ATTRIBUTE or even XML-style namespaces  
(where the meaning of the prefix is defined by namespace declarations).

- If I had my preference, I'd prefer just using prefixes directly  
instead of by indirect binding to a URI as with Namespaces in XML. In  
practice, it often transpires that producers and consumers of data  
start treating the prefix as semantically meaningful in XML, thus  
effectively requiring prefixes to be unique anyway. And it's been  
demonstrated that collisions in choice of prefix name are avoided  
naturally - I can't think of two well-known XML namespaces that are  
commonly used with the same prefix. So let's skip the URI-binding step  
and just make the prefix itself meaningful. We'll save a lot of  
confusion and complexity, and get the same net benefit. This also has  
the advantage that HTML parsing doesn't need to change.

- If we go with the "make the prefix meaningful" approach, I think it  
would be better to use something other than a colon character as the  
prefix separator. This would avoid conflict with IE's namespaces-in- 
HTML extension, and conflusion with Namespaces in XML. I think it  
would be bad to have a mechanism that looks like Namespaces in XML,  
but doesn't work the same way.

Regards,
Maciej

Received on Thursday, 22 October 2009 23:06:13 UTC