Bug 29703

Summary: Add a function to element to check whether it matches a CSS selector
Product: WebKit Reporter: Sam Weinig <sam>
Component: DOMAssignee: Nobody <webkit-unassigned>
Severity: Normal CC: diego.perini, gianni, john.david.dalton, kangax
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: OS X 10.6   
Description Flags
mitz: review+
modified version of jressig's test none

Description Sam Weinig 2009-09-24 00:09:00 PDT
As is being discussed for v2 of the Selectors API, we should add a function to Element to check if it matches a selector (Element.webkitMatchesSelector).  Mozilla is also working on this (https://bugzilla.mozilla.org/show_bug.cgi?id=518003).
Comment 1 Sam Weinig 2009-09-24 00:14:50 PDT
Created attachment 40048 [details]

Implement Element.webkitMatchesSelector.
Comment 2 Sam Weinig 2009-09-24 10:48:15 PDT
Landed in r48723.
Comment 3 Sam Weinig 2009-09-24 15:41:21 PDT
Created attachment 40087 [details]
modified version of jressig's test
Comment 4 Diego Perini 2009-10-05 08:34:07 PDT
I believe there is a performance problem with the webkitMatchesSelector() method as you are currently implementing. Proof is that my javascript implementation is about 10/20% faster than native C++ implementation.

The method I use is to parse and compile the passed CSS selector strings in ad-hoc javascript functions that can be reused for the rest of the page lifetime, it is a pure bottom-up matcher, very fast.

The speed improvements will be really high for this method, I would like to underline the fact that this new methods could be called thousands of time during page interactions controlled by event delegation, so it seems important
to have the fastest outcome in speed from these methods.

Here is the test showing the described slowness:


Can be tested only with r48723 and above or a nightly Firefox.

I used r49078 in my tests.