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.