Re: Use cases for Selectors-API

<27/12/2008> Jonas Sickings

> A few comments:
>
> * XPath works mostly fine on HTML already, firefox supports it. The
> only things that weren't defined by specs were a few things related to
> case sensitivity.

According to the HTML5 specification, the HTML parser is not required to
build an XML Information Set and this is the only normatively specified
method to build and XPath data model (but not the only one allowed). If it
works yet, I'm happy with that.


> * The fact that XPath can return non-nodeset values is totally
> unrelated to implementing a element.matchesSelector type API. What it
> means is that you can return things like numbers and strings, i.e. you
> can return the number of <p> children inside the <body> multiplied by
> the value in the 'hello' attribute of the first <meta> element.

Actually I meant the use of boolean functions + the use of a context node.
But yes, it has terrible perfomance issues.

>
>  * Minor nit: It's called XPath, not XMLPath.
>
No the complete name is XML Path Language (XPath) 2.0, according to the
latest Rec.

2008/12/27 Boris Zbarsky <bzbarsky@mit.edu>

> 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.

sorry but I didn't know of Safari / IE8.

 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.

That is an issue for browser vendors, not spec writers. And I think that if
they optimized document.querySelectorAll("blockquote > p") they can optimize
document.evaluate("\\blockquote\p",...)

>
>
> 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.
>
The problem are toolkits, not XPath. The more javascript you use, the worse
the performance, since JS is interpreted not compiled. If toolkits didn't
rewrite complex CSS selectors in XPath syntax, performance would be similar.


>
>  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.
>

You don't need selectors API for matching ".my_class" or "object" or even
"#my-id". Use getElement(s)ByClassName/TagName/Id


>
>  (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.
>
I meant that any new API is a problem beacuse authors don't learn quickly.
(and DOM3XPath is not new, selectors API instead is)

>
>  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?
>
Jonas says that this problem is also resolved. (and public-html is not
actually public, because of patents)


>  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.


Same old questions = same old answers? I don't think these are enough

Giovanni

Received on Saturday, 27 December 2008 15:21:32 UTC