Skip to content
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.

Sign up for GitHub

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

Jump to bottom

:matches() is now :is() in the spec #19

Closed
valtlai opened this issue Nov 14, 2018 · 14 comments
Closed

:matches() is now :is() in the spec #19

valtlai opened this issue Nov 14, 2018 · 14 comments

Comments

@valtlai
Copy link

valtlai commented Nov 14, 2018 •
edited
Loading

The :matches() pseudo-class is now renamed to :is(). See the Github issue and the spec.

I think it’s probably worth of support both instead of creating a new extension for the :is().
@jonathantneal
Copy link
Member

Excellent. We should take a look. This plugin is getting long in the tooth, despite being used so often.

@valtlai
Copy link
Author

valtlai commented Nov 23, 2018

Could we simply rename matches to is and release a new major version? Or would it be too radical?

@equinusocio
Copy link

equinusocio commented Nov 28, 2018 •
edited
Loading

Find and replace all 😂 @jonathantneal

@ExE-Boss
Copy link

Also keep backwards compatibility for :matches(…) which is defined as an obsolete legacy alias for :is(…), but browsers don’t need to implement it.

@equinusocio
Copy link

Yes it should be deprecated not replaced

@hacknug
Copy link

hacknug commented Feb 27, 2019 •
edited
Loading

Is anyone able to review my fork to see if everything I did would solve this issue? All tests passing for both :matches and :is but maybe there's another catch i didn't account for?

I can open a PR if needed/preferred. Just let me know 👍

https://github.com/hacknug/postcss-selector-matches

@jonathantneal
Copy link
Member

jonathantneal commented Feb 28, 2019 •
edited
Loading

The problem is that :matches has forked from the spec.

#16

For instance:

head ~ :is(html > body) {}

/* should become */

html > head ~ body {}

/* and should not become */

head ~ html > body {}

Given a CSS selector that is .foo head ~ :is(html > .bar ~ body) and HTML that is <html class="foo"><head class="bar"></head><body></body></html>, the CSS selector should match the HTML body tag. However, we must solve this without knowing the DOM tree.

To properly polyfill :is, we must first separate the context selector from the :is selector.

complex selector :is selector
.foo head ~ * (* is inferred) html > .bar ~ body

Next, we must separate and merge the last compound selector from its preceding complex selector.

complex selector matching selector merged selector
* body body (* and body can merge into body)

Note: These compound selectors must be merged into a single valid selector, correctly inferring universal selectors (*). If they cannot be merged, the rule must be skipped.

Next, all possible combinations of the preceding complex selectors (.foo head ~ and html > .bar ~) must be solved for, and I do not have an algorithm for this.

possible selectors
.foo html > head.bar ~ body
html.foo > head.bar ~ body

@LeaVerou
Copy link

LeaVerou commented Dec 7, 2019 •
edited
Loading

@jonathantneal What about a partial implementation until this is resolved? It seems the problem only happens with combinators, however :is() is very useful even for simple selectors and sequences thereof. What about only supporting compound selectors and commas?
Also, it seems to me that the renaming is orthogonal to this issue.

@valtlai
Copy link
Author

valtlai commented Dec 7, 2019 •
edited
Loading

@LeaVerou FYI, there’s now csstools/postcss-is-pseudo-class (not released yet).

@jonathantneal
Copy link
Member

Forgive this tangental response.

PostCSS Preset Env is in need of updates and publishes. I am very happy to say that my working conditions have changed in a manner that may now afford me some time to actually do this.

Secondarily, I have been distracted from updating PostCSS Preset Env because of the complexities that arise from requiring 3 parsers to work with CSS. A breaking changes in 1 of those parsers has meant that upgrading one package has required a kind of chain reaction. Contributors at first were eager to help me, but the complexities and the time required to address them evaded even some of those generous folks.

The situation is so frustrating that I have gone as far as looking into creating a new tool for the PostCSS ecosystem; one that parses selectors and values out of the box — following the CSS Syntax specification — while still preserving all those "lossless" bits like whitespace and comments.

At times, these things feel so tangental to the issue. That is until I actually try adding :is back into PostCSS Preset Env, and then those dependency issues come back to haunt me.

And there’s one other distraction. It’s whether I should prepare PostCSS plugins for incorrect caniuse data. I already have this issue with CSS Logical Properties and, for another project, Resize Observer.

@LeaVerou
Copy link

@LeaVerou FYI, there’s now csstools/postcss-is-pseudo-class (not released yet).

Awesome, any release ETA?

@cdoublev
Copy link

It seems that :matches has just been renamed (vs. aliased) to :is in Chrome v88.

@valtlai
Copy link
Author

valtlai commented Feb 14, 2021

Just found postcss-pseudo-is

@devongovett devongovett mentioned this issue Dec 27, 2021
Closed
@valtlai
Copy link
Author

valtlai commented Feb 28, 2023

There’s also postcss-is-pseudo-class, which is actively maintained, so I’m closing this issue.

@valtlai valtlai closed this as not planned Won't fix, can't repro, duplicate, stale Feb 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@LeaVerou @jonathantneal @hacknug @ExE-Boss @valtlai @equinusocio @cdoublev