-
Notifications
You must be signed in to change notification settings - Fork 20.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standardize custom pseudo object #2073
Comments
I actually would like to keep them all. Regardless, I'd like to continue recommending the use of the .createPseudo() method for creating custom selectors, making the choice of one property somewhat moot – except for |
In the sense of not moving to deprecated, or of not standardizing?
But still exceedingly rare from (among other things) its lack of documentation, and with a fix that couldn't be simpler. At any rate, though, I propose deprecation not because I think we can remove them anytime soon, but to promote consistency.
That would depend on your measurement criteria... it's probably the most used by execution count from jQuery UI alone. And to the extent that any such special-case functionality can be used "much", I bet updating api.jquery.com would address the educational gap.
Then it appears NWMatcher has moved on, at least from an API perspective (which is what I'm addressing). However, even if it hadn't, maintaining surface area in jQuery core to support transitioning from an independent selector engine seems... overaccommodating.
Not at all; the result of |
I think we're on different wavelengths here. In terms of defining custom pseudos, you said jQuery UI mostly used
Totally true. Brain fart. However, the main point there was I'm all for documenting custom pseudo creation in jQuery (and I'm fine picking a property and sticking with it), but I still don't see the value behind deprecating the other properties. To me, deprecation voices the intention of removal whether we say it does or not. If we use the same property in all of our documentation, that seems like enough. |
Per meeting, decided on "pseudos". |
cc @timmywil @scottgonzalez
The Sizzle pseudos object is exposed on
jQuery.expr
as three distinct properties:jQuery.expr.pseudos
jQuery.expr.filters
jQuery.expr[":"]
Sizzle defines the first two, and jQuery defines the third.
None of them appear in the current jQuery documentation, though Sizzle documents the object as
pseudos
(and separately documents the relatedsetFilters
), and I'm sure we have published instructions on how to define a custom pseudo at least once, which would necessarily reference one of them. We also have internal uses in at least two libraries:jQuery.expr[":"]
fromjQuery.expr.pseudos
jQuery.expr.filters
jQuery.expr.filters.hidden
in the :visible pseudo$.expr[ ":" ]
$.expr.filters.animated
$.expr.filters.visible
and$.expr.filters.hidden
So now that this issue affects three source repositories and jquery/api.jquery.com, here's the crux of it: can we standardize on one internally and deprecate the others? All things considered, my vote would be on
filters
.The text was updated successfully, but these errors were encountered: