- From: <bugzilla@wiggum.w3.org>
- Date: Thu, 04 Jun 2009 08:48:57 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6775
--- Comment #12 from Henri Sivonen <hsivonen@iki.fi> 2009-06-04 08:48:57 ---
(In reply to comment #11)
> The original issue description says
>
> It follows that an HTML 5-compliant UA treats elements in the
> http://www.w3.org/1999/xhtml namespace as HTML elements
> but doesn't treat no-namespace elements as HTML elements.
>
> I am taking "treat ... elements as HTML elements" to mean supplying
> the default styling and behavior specified in the various HTML
> specifications.
Yes. Specifically, it means that the element nodes that get constructed are
instances of the classes that implement HTML behavior and HTML DOM interfaces.
> My question is: why?
To hide the HTML vs. XML origin differences in implementations on higher layers
than the parser.
> Why not make HTML 5 specify that elements
> in the http://www.w3.org/1999/xhtml namespace are treated as
> HTML elements, and elements for which no namespace is specified
> (i.e. elements with unqualified names, called in the description above
> "no-namespace elements") are also treated as HTML if their local
> name matches an element name in the HTML vocabulary (if necessary,
> by performing an ad-hoc transformation on the DOM to supply an
> explicit namespace name where appropriate)?
Mainly because it's more complicated to have to test for two namespaces plus
owner document (for no-namespace nodes in XML DOMs) all over an implementation
codebase than checking for one namespace.
> Two subsidiary points may be worth mentioning. First, my understanding
> of the Namespaces recommendation is that its awkward ways of
> describing unqualified names (namespace-name + local name pairs
> in which the namespace name is null) stem precisely from a desire
> to ensure that unqualified names can in appropriate cases (e.g.
> where there is external information) be recognized as identical in
> denotation (at least), or short-hand for, qualified names.
Sure, but XHTML foiled this by assigning the elements with HTML semantics to a
namespace.
> That is: I don't believe the Namespaces rec requires anyone or any
> spec to treat {}p and {http://www.w3.org/1999/xhtml}p as
> denoting different things.
Maybe not, but treating them as same requires more C++, more Java, more complex
XPath, etc. Treating them the same in XPath got objection over in bug 6777.
> It seems to me at first glance that HTML 5 might do well to use
> the special nature of unqualified names and to say that in an
> HTML processor, unqualified names which happen to be known
> to be in the HTML vocabulary should be treated as being in the
> appropriate namespace.
>
> What am I missing here?
That it's more complex to allow different namespaces in the data model and
write code to treat them similarly than to unify things in the data model and
write less conditions in the surrounding code.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 4 June 2009 08:49:07 UTC