-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
:has() selector discussion #5797
Comments
This comment was marked as outdated.
This comment was marked as outdated.
It is August 30th. All new features and "restored features" can use Firefox will follow at some point. Tracking issues:
|
Please wait until Firefox has full support for |
We're not going to retroactively break features, so it's ok. As mentioned, new features and bugfixes can already use the new selector. Firefox will get them whenever it becomes ready. The features you mentioned simply would not exist without :has(), in fact one of them was years old and I implemented it as soon as the selector was available in Safari, in 15 minutes of my time. We're not going to write JS code for new features that are 3 lines of CSS, only for it to be obsolete in 3 months. I hope that makes sense. |
Possible new selector usage:
|
@jerone By the way, you can opt-in to Firefox's preliminary implementation by enabling the |
Note:
|
Hmm... Firefox doesn't seem to have moved any closer on this in the last 6 months; based on the activity on the tracking issue and hide-own-stars' fix is not compatible with Firefox's experiemental implementation. Is there a suggested workaround for Firefox users, since currently, we're getting a degraded experience (even after enabling the experimental flag)? |
Unfortunately not. GitHub has also been making changes to their DOM making it increasingly difficult to target elements reliably, which means I have no choice but use |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as duplicate.
This comment was marked as duplicate.
Upstream bug closed! Coming to Firefox 119 on October We can start fixing all the TODOs (but they won't be merged until that date) |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
New issue to track: Apparently on hold until at least Firefox v121, December 19th. It's strange because it already passes the web interop tests 10x faster than Chrome, even. Anyway presumably this already works well if you enable the See you in 2024 guys |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as resolved.
This comment was marked as resolved.
Firefox 121 is released! @fregante |
We'll likely still wait a few weeks before releasing a release that breaks Firefox <120.
It turned out just about right 😃 |
Can be closed. I cleaned up past polyfills and some TODOs. Due to performance issues, |
Feel free to leave a comment (or more) if you think of any features that can be rewritten or enhanced using the
has
selector.Live examples:
readable-title-change-events
order #5795clean-conversation-sidebar
wrongly hides projects #5757 (comment)But also, maybe:
body:has(native button) .our-button {hide}
🤯I swear this selector is a game changer for extensions. The only thing it can’t do is alert us of such events (maybe 😏 via empty
animationend
on these elements + JS listener)The text was updated successfully, but these errors were encountered: