Closed valtlai closed 1 year ago
Excellent. We should take a look. This plugin is getting long in the tooth, despite being used so often.
Could we simply rename matches
to is
and release a new major version? Or would it be too radical?
Find and replace all 😂 @jonathantneal
Also keep backwards compatibility for :matches(…)
which is defined as an obsolete legacy alias for :is(…)
, but browsers don’t need to implement it.
Yes it should be deprecated not replaced
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 👍
The problem is that :matches
has forked from the spec.
https://github.com/postcss/postcss-selector-matches/issues/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 |
@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.
@LeaVerou FYI, there’s now csstools/postcss-is-pseudo-class (not released yet).
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 FYI, there’s now csstools/postcss-is-pseudo-class (not released yet).
Awesome, any release ETA?
It seems that :matches
has just been renamed (vs. aliased) to :is
in Chrome v88.
Just found postcss-pseudo-is
There’s also postcss-is-pseudo-class, which is actively maintained, so I’m closing this issue.
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()
.