I have noticed it's pretty common for devs used to CSS-in-JS to imagine classes as being an exact 1:1 mapping to a specific DOM element, so maybe this is aiming to simplify things for that crowd? I guess similarly to BEM class names from a several years back.
Personally I prefer `class="btn primary"` over `class="btn-primary"` just because it aligns conceptually with what "class" literally means, but I have run into folks that would think it's confusing that there's no top-level .primary rule.
For performance... ehhhh yeah. Nesting and :has() already let you easily slow stuff down if you're not careful. Adding just wildcards, even if they're as restrictive as the blog post talks about, is still going to hang another easy-to-reach footgun on the proverbial wall.
> Personally I prefer `class="btn primary"` over `class="btn-primary"` just because it aligns conceptually with what "class" literally means, but I have run into folks that would think it's confusing that there's no top-level .primary rule.
Especially now that there is native nesting, these prefix selectors really seem like the wrong way to go.