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
On 12/27/08 2:17 AM, Kartikaya Gupta wrote:
Found an issue in DOM2 Range that doesn't seem to be addressed anywhere that I
could find:
Section 2.12.1 (handling insertions) says that the boundary point offset should only be adjusted if the
insertion point's offset is strictly less than it. Howe
