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

On Thursday, October 22, 2009 at 4:06 PM, Maciej Stachowiak wrote:
> If you'd like to survey the range of opinion though, here are my own
> (purely personal) views about extensibility:

I'm definitely interested in the range of opinion. Thanks for sharing.
 
> - 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.

Agreed.

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

I can see the problem if such elements have custom parser handling or fix-up, but that shouldn't be allowed. Only user agents would be able to put such a restriction in place anyway.

Other differences could be styling and rendering or additional APIs exposed on the element instance, but this could just as easily be triggered based on an attribute. In the end I'm not quite sure how this becomes a problem specific to elements. 

Can you elaborate?

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

Agreed. I think this is the advantage of a standardized extension mechanism. Should an extension be rolled into HTML with behavioral changes, element and attribute names can be altered so existing content relying on the original behavior can continue to function. Then implementers can migrate to the new standard without fear of breaking the web. Authors can also utilize both the standard and legacy markup until such time that the standard is broadly enough adopted. This matches closely with how CSS vendor prefixes work today.

I think we should also recognize that many of these extensions will never be standardized, especially when their purpose is more domain-specific. I expect the number of extension authors to be much greater than the number of user agent vendors, increasing this gap. This is also what makes me more concerned about the potential for name collisions.

> When considering the possibility of eventually folding in custom
> markup extensions into standards, I think custom elements are
> considerably more problematic than custom attributes.

Why do you think custom elements are more problematic?

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

I think the primary use case is the readability of the source. I find something like <my-calendar> a bit easier to follow than <div class="my-calendar"> or <div data-my-type="calendar">.

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

Agreed, though I would also want validators to inform authors when HTML documents contain extensions.

-Tony

Received on Saturday, 24 October 2009 00:05:51 UTC