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
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Saturday, 27 December 2008 17:08:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:29 GMT