Re: Use cases for Selectors-API

Giovanni Campagna wrote:
> - XMLPath and DOM3 XPath actually are implemented: even FF2 supports 
> document.evaluate, instead selectors api are included only in the very 
> latest browser (Opera 10 and FF3.1 AFAIK)

And Safari and IE8.  But yes, the point that XPath is already supported 
as a selection mechanism is correct (though I can't recall what the 
status is across all browsers).  In fact, various JS toolkits use it 
right now.

> Disadvantages of XMLPath vs Selectors:
> - authors must learn a new language
> - authors must use XML

You forgot:

  - Selectors is designed to be fast to match, while XPath had no such 
design criterion; as a result it's very easy to write pathologically 
slow XPath queries, even by accident.  For non-pathological cases, 
Selectors are still faster, whether because of spec design choices or 
because browsers already heavily optimize selector matching.

For example, see http://ejohn.org/blog/queryselectorall-in-firefox-31/ 
for some performance data.  The "old API" section is toolkits using 
whatever they had on hand before querySelector came along, including 
XPath.  At least Prototype and Dojo do in fact use XPath if possible: 
those would be the first and third bar on the graph.

> For the first issue, I simply answer that many authors don't know the 
> latest Selectors lev 3 features either

While this may be true, the initial uptake for this feature is expected 
to be by toolkits, not authors directly.

And you don't need to learn the Selectors Level 3 stuff to use this API, 
of course.

> (yes, they're not difficult, but until they're widely 
> deployed, the only mean to learn about them are W3C specs, and authors 
> sometimes don't even know about W3C)

I don't see how any APIs here would make a difference to this last class 
of authors, unless you expect them to read tutorials or whatnot....  And 
in that case, you're back to people not learning from the specs.

> For the second, it would be useful if HTML5 included a way to build an 
> XML Information Set from a text/html resource. DOM3XPath for example 
> normatively defines bindings between Information Set elements and DOM 
> interfaces, so that from any successfully built DOM it is possible to 
> have an XML Infoset.

That seems like it would be better suited to the public-html mailing 
list, no?

> I'm very curious about what your answer will look like (it seems to me 
> that I discovered hot water)

No, more like repeated the same old arguments yet again.

-Boris

Received on Saturday, 27 December 2008 06:52:32 UTC