W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

Re: Use cases for Selectors-API

From: Anne van Kesteren <annevk@opera.com>
Date: Sat, 27 Dec 2008 18:07:27 +0100
To: "Giovanni Campagna" <scampa.giovanni@gmail.com>, public-webapps@w3.org
Message-ID: <op.umty6kni64w2qv@annevk-t60.oslo.opera.com>

On Sat, 27 Dec 2008 16:20:57 +0100, Giovanni Campagna  
<scampa.giovanni@gmail.com> wrote:
> <27/12/2008> Jonas Sickings
>>  * Minor nit: It's called XPath, not XMLPath.
> No the complete name is XML Path Language (XPath) 2.0, according to the
> latest Rec.

XPath is a commonly used abbreviation, XMLPath is not. Also note that Web  
browsers do not implement XPath 2.0.

> 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",...)

Except that optimizing the former gives the browser greater benefits  
(faster CSS computations) than spending time on optimizing the latter.

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

But for e.g. div > h2 you do.

> I meant that any new API is a problem beacuse authors don't learn  
> quickly. (and DOM3XPath is not new, selectors API instead is)

But most Web authors know Selectors (from CSS), but hardly know XPath.

Anne van Kesteren
Received on Saturday, 27 December 2008 17:08:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:23 UTC