Selectors- CSS Selectors initial support

[jamesnw]

I would appreciate some feedback on how selectors are represented- this is split across 4 PRs-

1. Selectors- CSS Selectors initial support #2170 (this one)- Long term "initial support" selectors, like classes and ids
2. Add initial CSS pseudoclasses #2229 - Splitting out the pseudo classes from this one
3. Selectors- Add baseline high #2171- Baseline High features, but newer, or more likely to be sought out and identified as a feature.
4. Selectors - and indexed pseudo classes #2168 - Indexed pseudo classes, split into child and nth-of-type features
5. Selectors- add baseline false features #2169- The newer selectors that are currently baseline false, split into 6 distinct changelog-type features

The descriptions are intentionally rough at this point- I want to make sure the feature set is correct before polishing.

Note that the column combinator and blank selectors have a PR to be removed from BCD, as they are not implemented. mdn/browser-compat-data#24976

[jamesnw]

@ddbeck @Elchi3 @captainbrosset Do you have any opinions on this feature set?

[ddbeck]

I think this is a good start. Some ideas on the root of this, in line comments.

[ddbeck]

I'm not sure if this is the right thing to do, but one other way of looking at this would be to have distinct features here:

• type selectors (universal, type)
• combinators (list, child, descendant, next sibling, subsequent sibling)
• attribute selectors (attribute, class, id)
• user action pseudos (hover, active, focus)
• input selectors (checked, disabled, enabled)

It leaves some weird loners though (root, target, empty, lang).

This feels slightly more meaningful—e.g., as a developer, some of these would answer the question of "I want to select a…"—for some of them, but not all ("combinators" is not exactly a "feature" so much as a foundational language construct).

I haven't really convinced myself either way here. Would be interested to know your take, having seen this though.

[jamesnw]

As I look at this, I think this breakout makes sense, and make sense to do as the first pass. I think the weird loners can be weird loner features fairly easily.

I've marked the other sets of selectors ready for review, and will work on splitting this one up.

[captainbrosset]

root, target, empty, and lang are scenario specific, and might be good to move into their own features.
I like Daniel's idea, I like being able to use web-features to answer developer questions, even if the things they're asking about are kind of old and mostly taken for granted.

That said, I would personally group type selectors, combinators, and attribute selectors into a single "Selector initial support" feature.
They're more features of the language than capabilities. They don't allow you to implement specific developer scenarios.

[jamesnw]

It seems like we're in agreement that the pseudo classes should be split out into features, so I did that in #2229. That leaves the language features- type selectors, combinators, and attribute selectors.

@ddbeck Would you be amenable to grouping those into a Selector initial support feature? This would be somewhat similar to what was done in caniuse. Although that also includes the pseudo classes, they also didn't feel the need to split out further.

[ddbeck]

Yes, that would be fine. If you want to try out some way of naming this doesn't feel so frozen in time though, I would welcome that (maybe even "Selectors (core)" or "Selectors (common)"). Eventually, I'd expect some of the "newer" ones to be acknowledged as basic CSS functionality (e.g., in a few years, I'd imagine that :not() would join these) and it'd be nice if we didn't commit ourselves to a permanent view of this feature.

[ddbeck]

:not might be its own thing—it "feels" newer to me 🤷

[captainbrosset]

It also feels new to me for some reason, strange because it's been supported forever. The selector_list subfeature, however, is much newer. So I agree with Daniel about moving them both to a separate feature because of this.

[ddbeck]

I'm happy with this. Since this is one of the (rare) initial support-type features, I'd like to get one more review on this before proceeding.

@Elchi3 would you mind looking at this, since you were behind the equivalent JS feature? #2170 (comment) is the key discussion for CSS specifically.

[Elchi3]

LGTM! 👍 Optional commentary:

Not sure if we want to align the name and description here, but the "JS (core)" feature has more words to it. In particular it has a sentence "This feature represents the oldest language features .."

name: JavaScript (initial core language support)
description: JavaScript is a programming language that runs in browsers, usually through the `<script>` element. JavaScript has changed over many years. This feature represents the oldest language features, such as built-in objects, statements, and operators. Also known as ECMAScript.

[jamesnw]

LGTM! 👍 Optional commentary:

Not sure if we want to align the name and description here, but the "JS (core)" feature has more words to it. In particular it has a sentence "This feature represents the oldest language features .."

name: JavaScript (initial core language support)
description: JavaScript is a programming language that runs in browsers, usually through the `<script>` element. JavaScript has changed over many years. This feature represents the oldest language features, such as built-in objects, statements, and operators. Also known as ECMAScript.

I added "This feature represents the oldest language features of CSS."