Closed foolip closed 1 year ago
Is there a proposal for a different parent selector in the works? If not I think we might as well consider that :has()
is the best "parent selector" we'll get. As to whether it should still be considered "missing" I guess it depends if you answer based on what's in the spec (in which case it's not missing anymore) or what is actually usable today (in which case we're still not quite there).
I think it probably boils down to what we can replace it with, and since I can't think of much else right now I feel like we might end up leaving it in? Same issue with containment queries really…
Somehow explicitly ask "did
:has()
meet the use cases you wanted parent selectors for?" (other question)
:has()
is strictly more powerful than a parent selector that is the reverse of the child selector, so this is not really a subjective question.
https://drafts.csswg.org/selectors/#relational says that :has()
can't be nested, isn't that a difference from the imaginary parent selector?
Ultimately I think we should ask about :has()
as its own feature, and not do anything special.
I would be interested to see whether "parent selector" would still be a popular choice for this question if we kept it, but keeping doesn't make a whole lot of sense.
I don't recall every detail of the relevant discussions, but I seem to remember that even without nesting, :has()
is strictly more powerful than the subject selector as it can branch out on multiple different parts of the tree and the subject selector is strictly more powerful than the parent selector (by parent selector I assume something like a combinator that is the reverse of >
). But it's entirely possible I'm misremembering and that's true only with :has()
nesting. @tabatkins, maybe you remember?
Regardless, I agree that it probably doesn't make sense to use the term "parent selector" anywhere, unless what we are trying to measure is how many people have realized that :has()
solves that problem.
@LeaVerou can you also add the "already in survey" label?
unless what we are trying to measure is how many people have realized that
:has()
solves that problem.
I guess that's the point. I just had the case today that I told someone about :has()
and he didn't realize that this is basically the parent selector with more powers.
I am sure that many more people out there don't know that :has()
solves that problem.
Talking about authors not knowing about features, see also #35.
Sebastian
Perhaps we could just rename "Parent selector" to "Parent selector / :has()
"
Renaming to put :has()
in the title might be the best, yeah. It won't have shipped in all browsers when the survey runs I think, so it still makes some sense to talk about it as missing.
If @LeaVerou's altered survey questions are adopted, this will rather be part of unusable features due to little browser support.
Sebastian
Changing tags, since this does have an action item attached to it: Rename to "Parent selector / :has()
"
The name of the feature will just be :has()
I think. Using the term "parent selector" just adds confusion imo.
The name of the feature will just be
:has()
I think. Using the term "parent selector" just adds confusion imo.
What kind of confusion would something like "(aka Parent selector)" add?
"aka" sounds good, that conveys that it isn't the canonical name of the feature.
The name of the feature will just be
:has()
I think. Using the term "parent selector" just adds confusion imo.
I am fine with that if there's a one-line explanation below it saying that it covers the use case of a parent selector and others.
Sebastian
I'd like to keep and tweak this question for 2021: https://2021.stateofcss.com/en-US/opinions/#currently_missing_from_css_wins
Parent Selector is a tricky one, because there's now
:has()
, but it's different from the imagined parent selector as the reverse of the child selector. Options that I can see::has()
:has()
meet the use cases you wanted parent selectors for?" (other question)