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

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

Well, by the same token (just to pick one of many issues at random),
it's been demonstrated that many authors will use presentational
markup no matter how much specs discourage them.  Is that a reason for
the spec to make presentational markup valid?  HTML5 mostly takes the
approach of making undesired features invalid, so that they work but
don't validate, even though this won't stop them entirely.  A
surprising number of authors do actually care about document validity
for some reason, in my experience.  (As reported by a validator, I
mean, not that they care what the spec says.)

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

Well, first of all, other standards are already allowed to extend
HTML5.  Look at RDFa, for instance.  Of course, these won't validate
automatically, and need to be explicitly supported by the validator.
But that's necessary anyway to ensure that the foreign markup is valid
according to its own standard.  So I think other standards are covered
already (please correct me if I'm wrong).

On the other hand, I'm not clear what you mean by script libraries or
editors.  Are you referring to packages in standard client-side
formats such as JavaScript, which would like to store data in the DOM
for their own purposes?  I think this is covered pretty well by the
class attribute, data-*, and so on.  While it's true that making up
your own elements would be kind of neat, it doesn't seem to give much
practical benefit.  It's entirely possible I missed some use-cases in
all the discussion -- what exactly would custom attributes/elements be
useful for, from the perspective of JavaScript or similar
technologies?  getElementByTagNameNS() was mentioned, but
getElementsByClassName() should be just as fast, I'd think.

If by script libraries and editors you mean non-standard extensions --
like browser plug-ins, Flash, etc. -- then I think it's entirely
correct that markup to support them shouldn't validate.  Validation is
a sign that your content is standards-compliant, which it isn't if it
contains non-standard content.

So in short, despite reading all this discussion, I'm really not sure
exactly what applications need more support than they have already.
Other than applications that want to write markup that only they can
read, but I don't get why HTML5 would want to give them more support.

> Giving such extensions a standard form also increases author awareness that the markup is not native to HTML itself.

This would be accomplished equally well if there were a standard
mechanism for extensions (namespace-based or otherwise), but it didn't
validate, like in CSS.  Would that satisfy your requirements?

Received on Sunday, 18 October 2009 21:34:21 UTC