- From: Tony Ross <tross@microsoft.com>
- Date: Tue, 20 Oct 2009 05:21:12 +0000
- To: James Graham <jgraham@opera.com>
- CC: 'Jonas Sicking' <jonas@sicking.cc>, Adrian Bateman <adrianba@microsoft.com>, "public-html@w3.org" <public-html@w3.org>
On Sunday, October 18, 2009 3:12 AM, James Graham wrote: > Quoting Tony Ross <tross@microsoft.com>: > > > I feel HTML 5 already provides an elegant means of simplifying > > popular extensions based on XML Namespaces with its handling of SVG > > and MathML. Per your example, HTML 5 itself will enable authors to > > use vector graphics without a knowledge of namespaces because the > > SVG namespace will be assumed when an <svg> element is encountered. > > Other extensions could initially require the use of namespaces in > > markup, but then be integrated into a future version of HTML in the > > same manner should they become popular enough. Consequently an > > author would only be "forced" to use namespaces in markup for > > extensions that had not yet become popular enough to be integrated > > into HTML. > > Experience with SVG and MathML suggests that this kind of post-hoc > denamespacification becomes significantly more problematic when the tag > names of the imported vocabulary clash with the existing HTML tag names. > Therefore if one can imagine ones vocabulary being used in HTML without > explicit namespacing in the future, one must design it with unique tag names > from the start. Given this, the supposed advantages of namespaces to > vocabulary designers don't apply in this situation. >From a technical standpoint I don't see this as a major problem. So long as your vocabulary has a root-type element that doesn't clash, the identity of the remaining descendant elements can be determined without explicit namespacing, even if they utilize names that clash with HTML. On the other hand, if the sole intent of your vocabulary is to run within HTML, I agree it would be probably be wiser to avoid known HTML tag names for the author's sake. -Tony
Received on Tuesday, 20 October 2009 05:21:49 UTC