Giovanni Campagna wrote:
- 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
o
So I consider the main reason for the Selector API is that many more
developers are familiar with selectors than are familiar with XPath. I
base this on the fact that many more pages use CSS stylesheets than
use XPath, by several orders of magnitude (probably more than 3). It
is also demonstrated
On Sat, 27 Dec 2008 16:20:57 +0100, Giovanni Campagna
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
<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
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 selectio
On Fri, Dec 26, 2008 at 10:26 PM, Giovanni Campagna
wrote:
> As for the subject, I was wondering what are the use cases for Selectors
> API. Yes, author desperately need a way to get element that match some
> constraint inside a document (ie all tables or all p > span.urgent
> e
As for the subject, I was wondering what are the use cases for Selectors
API. Yes, author desperately need a way to get element that match some
constraint inside a document (ie all tables or all p > span.urgent
elements).
But they already have a language to implemented this: XML Path Langu
