- From: James Graham <jgraham@opera.com>
- Date: Fri, 16 Jan 2009 10:11:51 +0100
- To: Ian Hickson <ian@hixie.ch>
- CC: HTML WG <public-html@w3.org>
Ian Hickson wrote: > On Thu, 15 Jan 2009, James Graham wrote: >> The requirement that UAs place all HTML elements in the HTML namespace >> does not make sense for all classes of UA. For html5lib I plan to make >> it optional whether HTML elements are assigned to the HTML namespace so >> that people using APIs that have a significant namespace tax do not have >> to pay that tax in the common case. > > This wouldn't be non-conforming, since you don't expose a (W3C) DOM. It's not clear to me that Section 8.2.5.1 agrees with this. Insofar as building non-DOM trees is supported by the specification at all, requirements like "the UA must first create an element for the token in the HTML namespace" (where HTML namespace is linked to the corresponding URI) do not seem to be DOM-specific. > The requirement is a black-box requirement that is only testable if the UA > also supports Selectors (with namespaces), XPath, W3C DOM scripting, or > such like. It seems to me that what I want is, from the point of view of other resources in the browsing context of the page, a MUST level requirement that elements be in the HTML namespace (so scripts, CSS, etc always work with elements in the HTML namespace regardless of UA). For cases like screen scraping, however, application-level code is being written against the tree and portability between different implementations of the tree API is a less significant concern than ease-of-use in the API. Therefore from the point of view of such application-level code the parser should be allowed to put HTML elements in no namespace (maybe with a SHOULD requirement that it does not).
Received on Friday, 16 January 2009 09:10:47 UTC