- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Sun, 18 Oct 2009 17:33:48 -0400
- To: Tony Ross <tross@microsoft.com>
- Cc: "public-html@w3.org" <public-html@w3.org>
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