Bug Tracker

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#14622 closed feature (wontfix)

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.

Change History (3)

comment:1 Changed 6 years ago by dmethvin

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.

comment:2 Changed 6 years ago by timmywil

Resolution: wontfix
Status: newclosed

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).

comment:3 Changed 6 years ago by m_gol

OK, I wasn't aware adding an ID not existing in stylesheets causes a reflow. I guess that alone settles it.

Note: See TracTickets for help on using tickets.