Side navigation
#14622 closed feature (wontfix)
Opened December 10, 2013 08:29PM UTC
Closed December 11, 2013 06:53PM UTC
Last modified December 11, 2013 07:09PM UTC
Match more of Sizzle API in selector-native
| Reported by: | m_gol | Owned by: | |
|---|---|---|---|
| Priority: | undecided | Milestone: | None |
| Component: | unfiled | Version: | 2.1.0-beta2 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
I'd love to use selector-native in projects that don't need to cater to old/broken browsers. There are a couple of stop-gaps to make it usable for me, though:
1) perf-related: selector-native doesn't have the same fallbacks to getElementById & friends as Sizzle
2) API-related: selector-native doesn't support leading combinators and returns different jQuery objects for supported selectors (like in the $div.find( 'div > *' ) case)
In my opinion, those two points should be fixed. IMO an ideal situation would be if selector-native ommited the whole selecting code, always using querySelectorAll but if, at the same time, it modified the selector string before passing it to qsa. The temporary ID workaround present in Sizzle doesn't require a lot of code and would reduce API differences.
Such a change would also ease the path to upgrade the module to use find/findAll once they become available.
I'm leaving it for a discussion; I'm willing to work on this if the rest of the core team was willing to accept a patch.
Attachments (0)
Change History (3)
Changed December 10, 2013 08:43PM UTC by comment:1
Changed December 11, 2013 06:53PM UTC by comment:2
| resolution: | → wontfix |
|---|---|
| status: | new → closed |
As for #1, I don't recommend using selector-native at all, but I especially wouldn't recommend using it in browsers where the lack of getElement[s]By... shortcuts is an issue. qSA is fast enough, which other projects that ignore the advantages of a selector engine have already proven.
#2 should not be changed. selector-native is meant to be purely a wrapper around querySelectorAll, for better or for worse. As the file warns against, it should only be used by developers who are exhaustively familiar with all of the differences, such as the lack of support for several Sizzle conveniences (leading combinators not being the only one) and the failure of the qSA specification for rooted queries. When find/findAll (by the way, they won't be called that anymore) are finally released, the difference in behavior should be completely apparent to the super users who utilize selector-native.
If we start adding too much to selector-native, it will quickly lose its appeal as a simple wrapper around native methods and we'll inevitably encounter unexpected errors (such as reflows from adding IDs to the DOM).
Changed December 11, 2013 07:09PM UTC by comment:3
OK, I wasn't aware adding an ID not existing in stylesheets causes a reflow. I guess that alone settles it.
On #1, does it really make something "too slow" to use qSA consistently? I'd like to see that code.
On #2, adding the id to the DOM causes a layout so whatever miniscule benefit you'd get from #1 would probably be taken away several times over on an average page by this. To avoid that penalty you're better off using API calls.