This is an example of a contextual modifier on the BCD key- the string "multicol_context" won't show up in CSS, but this modifier denotes that the break-after would work inside a layout that using column.

The convention is that these keys will have underscores, and this potentially could be useful down the road to further target linting. However, CSS properties are going to never have a period, so I think the regex could be adjusted to drop the .multicol_context, or anything after a period. Essentially, anything beginning with css.properties, you could do something like key.split('.')[2] to get the property name.

Ah, that's very helpful, thanks. Yeah, I left these because I was trying to figure out if I could do something with the values after the period.

display.contents signifies a rule like this-

a {display: contents}. If there is not an underscore in the second portion, it is the value. It would be nice to be able to check for this as well.

Thanks for explaining this. I looked into it a bit and this is more complicated than it seems. Sometimes the identifier after the property name is a literal (as in display.content means display: contents), but sometimes it's a type (content.url means content: url(foo)). So it's not enough to just pull that value and check for it, we'd also need to know what type of node to look for in CSSTree.

And it gets even more complicated with types that actually represent multiple values, like border-radius.percentages, which may be represented by 1-4 nodes. I suppose we could filter and just check on the properties that are known to only have literal values, but I don't know how to automate that.

Ultimately, it looks like sussing out all of these details would be a labor-intensive process, so it's unlikely to happen without outside contributions.

This would indicate a rule like

@media (prefers-color-scheme: dark){}.

I noticed you're not testing types yet, so this is more of a note for the future.

Types are going to be tricky to detect from the key. Some will be fairly straightforward- abs, sign, anchor, for instance, will all show up as functions with that name, in a value in an AST.

A few items like gradient.* and easing-function.* would show similarly show up as functions if you took the substring after the ..

Others like time or string would not show up literally, but would need to be detected in a different way.

Yeah, I figured for the first version of the rule I'd punt on this, but I wanted the data here for easy reference later.

The only way I can think to make this work is to maintain a separate dictionary that maps types to their expected AST locations.

For selectors, feature detection could be fairly straightforward. Some like :has would have a single : and show up in the AST as PseudoClassSelector, others like ::before would have 2 :: and show up in the AST as a PseudoElementSelector.

I don't think there's a way to differentiate between the two classes based on this data.

There are also some items here that are not actually verbatim selectors- for instance, "class" refers to the . notation for selecting classes.

Yeah, that's the challenge I ran into, so similar to types, I figured I'd just make the data was there and I'd come back to it later. Probably will need to be addressed similar to types where there needs to be a separate dictionary indicating which are pseudoclasses vs. pseudoelements vs. other.

[Docs] This reads to me as the opposite of what the rule does. I see the rule as being in the family of "Disallow ..." because it reports to stop devs from using certain syntax.

Suggesting making the description more in line with that:

We only use "disallow" when the rule begins with "no". For others, we use "Enforce" (or "Suggest").

Is this documented anywhere? I can never keep track of the flowchart for how to name a rule.

This is probably the closest we have:
https://eslint.org/docs/latest/contribute/core-rules#rule-naming-conventions

If you want to update that doc, feel free.

[Non-Actionable] TIL the syntax highlighting for author is sensitive to a slash, interesting:

Additional TIL that there's no TypeScript->editor-native way to link to another file. microsoft/TypeScript#47718

🤷 I don't know of a better way to say this is authored by another file. So, not requesting changes, just ... vague interest.

Open question for me: Is baseline the right name? Should it maybe be use-baseline or require-baseline instead?

[Naming] Maybe, baseline-support or baseline-supported, to indicate it's about specifically the support aspect of baseline? But that disambiguation is probably only useful if there are other baseline-related rules to disambiguate from. And there are none. So no strong preference here.