| Summary: | Add a function to element to check whether it matches a CSS selector | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Sam Weinig <sam> | ||||||
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | diego.perini, gianni, john.david.dalton, kangax | ||||||
| Priority: | P2 | ||||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | All | ||||||||
| OS: | OS X 10.6 | ||||||||
| Attachments: |
|
||||||||
|
Description
Sam Weinig
2009-09-24 00:09:00 PDT
Created attachment 40048 [details]
patch
Implement Element.webkitMatchesSelector.
Created attachment 40087 [details]
modified version of jressig's test
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: http://dl.getdropbox.com/u/598365/matchspeed/matchspeed-custom.html Can be tested only with r48723 and above or a nightly Firefox. I used r49078 in my tests. |