- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 01 Oct 2009 19:55:02 +0200
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Adrian Bateman <adrianba@microsoft.com>, HTML WG <public-html@w3.org>, Tony Ross <tross@microsoft.com>, Sam Ruby <rubys@intertwingly.net>
Jonas Sicking wrote: > ... >> Also, dispatching on nodeName is entirely sane if you need to be able to run >> with DOM Level 1. > > How so? An element with nodeName "foo:hello" you have no idea what > meaning it has, unless you also know which namespaceURI it's in. > ... Yes, but it's well-defined how to find out using DOM Level 1. >>> ... >>> One of the problems with namespacing a'la XML Namespaces is that an >>> objects identifing name isn't a single string, it's a tuple. Everyone >>> has to lug around two separate values, localName and namespaceURI. >> No, that's an API problem. There are other APIs that use expanded names as >> identifiers. > > See above. I don't understand this argument, unless you are proposing > to do away with DOM? > ... There are many ways to consume HTML, and DOM may be the worst. Keep in mind that in many many cases RDFa is not consumed by browsers, so the defects of DOM really do not matter. > ... >> But that's because RDFa is a notation for RDF, which uses URIs, not >> (namespace,localname) tuples. > > Ok, might be that the tuples complexity was removed in RDF rather than > RDFa. The point remains that the RDF community decided that the XML > Namespaces namespaceing mechanism was not a good solution for them. > ... It was never "removed". RDF never used namespaceURI/name tuples as identifiers in the first place. >>> ... >>> However the proposal from microsoft still uses tuples of strings to >>> identify element and attribute names. >>> ... >> There's a well-understood way to map these tuples to simple strings, and >> back, so again, this is only an API problem. > > It's also a performance problem. If we store a single string to > identify the localName+namespaceURI tuple, that means that we have to > parse and split that string into its localName and namespaceURI parts > *a lot*. Every time a CSS selector is matched against a node, every No, you don't. That's an implementation detail. It's up to an implementation how to internally represent an expanded name; in particular, the choice for the internal format does not imply that the "other" format must be generated more than once. > time someone calls .localName from the DOM, every time a node is > created. I'd say that selector matching would get a couple of orders > of magnitude slower if we had to do that. Not quite as much for the > other operations, but possibly one order of magnitude there. At least > in Gecko. > ... If the CSS data model did use the same notation, it would probably be exactly as fast as before. Of course to be inconsistent internally is a bad idea. But that doesn't mean the one particular representation is bad. BR, Julian
Received on Thursday, 1 October 2009 18:02:25 UTC