When did the CSSWG accept this idea as a viable, universal one for a web standard? Let’s have a look at the issues that immediately come to my mind:
-*is a pattern, not a standard. CSS has never been about naming things like classes. Now it would. A proprietary selector for people using a-[something]notation. It’s fine in Scss or similar but not for a web standard.*is used as a regular expression syntax here. The current state is to not allow it to match emptyname-classes? That’s misleading and non standard in terms of Regular Expressions. If it should not allow empty, it should use-+— and yes, you see how misleading that would be.
Let me quote the draft spec here: "has at least one character beyond the prefix, and the first such character beyond the prefix is not also a hyphen". This would be entirely different to any regular expression syntax developers currently know.- The current state says
.card-*-primaryshould not be a match. This make the selector very specific and I’d still need the pattern selector for this case. So it’s half a problem solved with bad syntax. - If
-*is a thing, will we get full RegEx in future? Why wouldn’t we allow-[a-z]selectors here? It would be of better performance, clearer, allow even for typed selectors. And the dev world loves typed properties, right?
We already have pattern selectors ([class*=" btn-"]) that are universally working, yet a performance problem. But a performance problem is no reason to introduce slop syntax to a powerful language like CSS that’s being used by millions of people for decades.
What are your thoughts? Am I wrong here?
What I get behind the idea
- Solve the performance issue in UAs that Substring matching attribute selectors currently have, specifically class selectors here.
- Provide an easier way to build wildcard class selectors for developers.
- Provide a new strict, simple subset selector that has no big performance implications.
What I do not get behind the idea
- A specific class substring selector is not universal.
It does not work for IDs and other CSS selector types easily (even thoughdata-is stated for future extensions here) - Using a Regular Expression Syntax for matching behaviour that is not implemented as the common Regular Expression syntax is specified. Even in CSS
*works differently than in the suggested example ([class*=" abc"]). - The named example of using BEM with double dashes (
.btn--subtle) shows the problems and limitations of the suggested syntax. It’s not flexible enough to allow take this example into account. Current idea is to not match a double dash selector as prefix class. Two solutions: You need to prefix your BEM (horrible) or it’s not a useful tool for BEM and you resort to substring class matching selectors again. - Speaking of BEM, what about BEM prefixes?
.component__subwould not be supported by this, highlighting the inflexibility of this selector syntax. - Why would
.foo-ab\/cbe matched by.foo-*but.foo--would not be matched? At least to me, this is confusing.
I know it’s a draft currently. It’s the reason why I wrote a blog post about it, otherwise it wouldn’t be worth it anymore. In my opinion, a web standard specification should be very universally applicable. It should be logical to follow (CSS specs have made this mistake way too often in history already).
To be honest, I have not much ideas how to exactly improve this selector syntax to solve my raised issues. And that is because I think the entire idea of a "prefix class selector" is not universal. If we want such a thing, we need a selector for a variety of HTML attributes (ID, class, data, maybe more) that is more performant than the current subtring matching attr selectors can be.
Updates
I like the feedback in this comment by vrugtehagel which states that this is a solution for opinionated namings and therefore will not be flexible enough to be a web standard and universal to a variety of naming conventions used out there. This thesis is supported by weruv here as well as by paceaux.
paceaux suggested a different approach which is not directly solving the same issue but sounds like a good idea to me: For wildcard attribute selectors he suggests to add w as modifier. We already have s and i modifiers (for handling case in/sensitivity) for it, so it would be just another that restricts the match to word boundaries.
I think -* is syntax-wise not a great choice. The more I think about it, the more examples I see that do not work as expected. But here’s what came to my mind, matching as close as possible the desired prefix selector:
To me, what would be closest to what seems to be desired here would be something like ^.foo- { or .^foo- { as the attr selectors matching [attr^=foo-]. This btw matches -- as well so it would be consistent between both.