[selectors-4] Allow * before a type selector

[tabatkins]

I was gonna wait to propose this until after the Nesting issue resolved, but I think it might be useful to bring up earlier now.

The restriction currently imposed by the Nesting spec is that you can't start your selector with an ident. If your selector is a descendant-combinator relative selector, this is easy to fix - rather than div {...} write & div {...}. But if you're adding context to your parent rule, like div & {...}, the fix isn't as easy - you have to write :is(div) & {...} to trigger the correct parsing.

On Twitter, Brandon McConnell suggested an easy fix - you can currently prepend a * to any compound selector for absolutely no effect, unless the compound selector contains a type selector. That is, .foo and *.foo are precisely identical in behavior, but *div is currently invalid. (Effectively, * is a wildcard type selector right now.)

Brandon suggests making that valid, so you can add a * to any compound selector. Then the easiest fix for any nested selector that starts with an ident is to just put a * at the front of it. div {...} can become *div {...}, div & {...} can become *div & {...}, etc. And putting a * in front of anything else is already valid and doesn't change the meaning, so this works well as a generic "just spam it if you want to be safe" technique, if people don't want to learn the rule.

[plinss]

One way this proposal is fragile is if the user accidentally puts a space after the *, e.g. * div instead of *div (I can already see people I know adding the spaces because they think the *div was a mistake).

And if putting a * in front of everything is acceptable, why wouldn't putting a @ in front of everything be acceptable? The advantage to using an @ is that it's already the universal mechanism in CSS to indicate something special.

[plinss]

Another concern is that I can see a use for allowing * in tag selector matching. For example if I want to select all custom elements from a particular library: custom-*, or *-input.

I think this is another example of a work-around for nesting issues winding up constraining future expansion, which is the crux of my objection to the current nesting syntax.

[fantasai]

And if putting a * in front of everything is acceptable, why wouldn't putting a @ in front of everything be acceptable?

• We want to minimize syntactic differences between rules that are valid in nested context and those that are valid in other contexts (such as top-level or inside @scope), so that they can be copy-pasted between contexts.
• A lot (probably most) of selectors in real-world websites don't start with a tag name, they start with a class, pseudo-class, or ID selector and therefore don't need a prefix.

[plinss]

We want to minimize syntactic differences between rules that are valid in nested context and those that are valid in other contexts (such as top-level or inside @scope), so that they can be copy-pasted between contexts.

In the real-world, this only helps when copying from a context where the leading * is necessary to one where it isn't.

I suspect (at least at first), the bulk of copy/paste is going to be from a top-level context to a nested rule, and that's going to require fixups after the paste (or at least a manual check to see if fixups are necessary).

Allowing style rules with a prefixed @ at the top-level would be a trivial and safe change and would allow copy/paste from nested blocks to top-level without midification.

A lot (probably most) of selectors in real-world websites don't start with a tag name, they start with a class, pseudo-class, or ID selector and therefore don't need a prefix.

Right, but not all. If you can't accept all rules without fixup, then I assert making copy/paste easier in some cases is actually worse. People are going to be more prone to copy a large block of rule and miss the few cases where a fixup is required and are going to have broken rules. If there's a simple and consistent change that has to be made to all rules when pasting into a nested context, then the change can be easily made by tooling.

[bramus]

Also not a fan of reusing * for this, for the same reasons as detailed in #8253 (comment) and #8253 (comment). For *.foo is does make sense, but *div it does not.

@ seems the more obvious choice as a prefix, but not a big fan of this very short version of @nest (which it essentially is). If we were to introduce a nestable at-rule such as @progress or @color later on, those could easily be confused with @ progress and @ color by the author if they miss the space while reading. Using the long form @nest is more explicit in the intention (… until a nest element gets introduced that is).

[Loirooriol]

I keep getting the impression that nesting is bending the language so hard just to avoid 1 character.

Is it really worth it to add *div when we already have *|div? I have the impression that virtually nobody is declaring default namespaces, so they should be the same.

[bradkemper]

* div (with a space after the *) could often be a decent alternative to :is(div). If you knew the div is a child, then you could write > div. Otherwise if you knew it isn't a child, that means there is an intervening element, and * div would work. If you wanted to select all descendant divs, including children, then you'd need something else, like :is(div) or *|div.

That said, I'm still a fan of a bare @ (with a space after it). We could say that if it is in the middle of a selector, like main @ div, that it is treated the same as a space, or that it has no effect on the surrounding simple selectors (that is, would mean same as main div in this example). Maybe that would help with the copy pasting.

[bradkemper]

I don't think *div has to be nonsensical. It can mean "any element that is a div", in the way that *.foo means "any element with 'foo' class."

[Loirooriol]

If a default namespace is declared, would *div behave like div or *|div?

Also, does this proposal include things like *svg|* which would be the same as svg|*?

putting a * in front of anything else is already valid and doesn't change the meaning

Putting * in front of * (i.e. **) is not valid. Putting * in front of |div (i.e. *|div) changes the meaning.

[tabatkins]

A lot (probably most) of selectors in real-world websites don't start with a tag name, they start with a class, pseudo-class, or ID selector and therefore don't need a prefix.

Right, I'm poking in here to try and find a generally-usable, very short way to write selectors starting with type selectors unambiguously (rather than the current "wrap it in an :is() suggestion). All the rest of selectors are already unambiguous.

It can mean "any element that is a div", in the way that *.foo means "any element with 'foo' class."

Right. Currently * is defined to be a wildcard tagname selector, but that doesn't necessarily have to be the case. It can just be a wildcard selector in general. Or we can just say that * is an optional part of the tagname selector syntax; you can omit either the * or the tagname, or leave them both in. Multiple reasonable ways to interpret it.

(I'd forgotten that namespaces exist; being able to write svg|* does suggest it's a tagname selector, or at least something very close to it.)

Putting * in front of * (i.e. **) is not valid.

I'm happy to bite the bullet that my statement "you can put * in front of anything" naturally excludes things that already start with *. ^_^ (I'm not trying to imagine something that a machine can blindly spam in front of every selector; combinators would also fail the "put a * in front of it" rule then. I just want a short, easy way to write the one problematic case.)

Putting * in front of |div (i.e. *|div) changes the meaning.

You're right, that does violate my general statement. Luckily it's not an issue since |div already goes down the selector path due to starting with a symbol. (Plus it's an incredibly niche case (explicitly needing to select a null-namespace element when there's a namespaced element with the same local name also on the page) of an incredibly niche case (caring about namespaces at all). Multiple nines of authors will never even get near this.)

Is it really worth it to add *div when we already have *|div?

Maybe not, I'd just forgotten about namespaces existing entirely. Tho starting a selector with foo|div would still be problematic.