Rendered at 16:51:54 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
jjcm 2 days ago [-]
In their example, they list btn-* as the selector catch all for .btn-primary|secondary|danger. I can't help but think why not just do, .btn.primary for the class name, and just target .btn with the selector?
Don't get me wrong, I appreciate the convenience of this, but I do worry about selector slowdown with what will effectively turn into a regex at some point. I'm dubious that this is needed.
graypegg 2 days ago [-]
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.
nhinck2 2 days ago [-]
> 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.
Gualdrapo 2 days ago [-]
I don't think they will go that far. Just look at the attribute selectors, - they're just 5 of them:
Then you still need a btn class for styling anchor tags
DHPersonal 22 hours ago [-]
The proposed mixin support in CSS will offer a way to reference both button.primary and a.primary without having to duplicate the styles in both, but it’s still in draft status.
dymk 2 days ago [-]
Personally, I don't think this is a great change to CSS. I prefer being able to grep for identifiers to see where they're used. Now you can't rely on that - maybe a rule is now covered by a prefix selector.
zetanor 2 days ago [-]
I suppose someone could have done
[class^="btn-"], [class*=" btn-"]
which would have equally thrown you off, but I do agree that encouraging this is unfortunate.
graypegg 2 days ago [-]
*[class*=btn-] { ... }
I know you'd be matching on the class attribute instead of a single classname, but I feel like we'd see this much more out-in-the-wild if there was an apetite for this syntax feature right?
Like, the issue of `some-other-btn-primary` also matching the rule is pretty inconvenient, but definitely tolerable if people preferred writing style rules like this.
yeargun 1 days ago [-]
Hey,
I don't like Browsers to go CISC way. Simpler -> finer ?
Why?
Any feature that we add up indeed cause some extra CPU cycle. I am not a believer that we need an extra regex like this.
Of course, the overhead caused by this is minimal, so is the benefit. Also very tiny percent of web apps will use this anyways.
It could make the shipped css/js to some extent.
Overal I don't like this tradeoff. I dont want web to have more fanout
lukeify 2 days ago [-]
So the class prefix is actually `-*`, not `*`:
> The Class Prefix Selector is currently limited to hyphen-separated prefixes, at least at first. Other separators, like _, might be added as possibilities in the future as we receive request from authors like yourself about what would be needed.
I'm sorry, but how did they think this a good idea? Why treat the hyphen with special qualities over any other non-whitespace separator? The argument around "accidental overselection" seems pretty weak to me. If you're using a character with known special properties like the asterisk in CSS then you should understand you're wielding a more powerful hammer implicitly.
CM30 2 days ago [-]
This is pretty neat. Definitely seems like something that'll make writing CSS for similar classes a lot more convenient, and another example of how modern CSS seems to be adding a ton of features to make front-end development a lot more efficient.
The increased level of power HTML, CSS and JavaScript have now is honestly kinda insane.
Don't get me wrong, I appreciate the convenience of this, but I do worry about selector slowdown with what will effectively turn into a regex at some point. I'm dubious that this is needed.
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.
Especially now that there is native nesting, these prefix selectors really seem like the wrong way to go.
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/S...
Like, the issue of `some-other-btn-primary` also matching the rule is pretty inconvenient, but definitely tolerable if people preferred writing style rules like this.
I don't like Browsers to go CISC way. Simpler -> finer ?
Why?
Any feature that we add up indeed cause some extra CPU cycle. I am not a believer that we need an extra regex like this.
Of course, the overhead caused by this is minimal, so is the benefit. Also very tiny percent of web apps will use this anyways.
It could make the shipped css/js to some extent.
Overal I don't like this tradeoff. I dont want web to have more fanout
> The Class Prefix Selector is currently limited to hyphen-separated prefixes, at least at first. Other separators, like _, might be added as possibilities in the future as we receive request from authors like yourself about what would be needed.
I'm sorry, but how did they think this a good idea? Why treat the hyphen with special qualities over any other non-whitespace separator? The argument around "accidental overselection" seems pretty weak to me. If you're using a character with known special properties like the asterisk in CSS then you should understand you're wielding a more powerful hammer implicitly.
The increased level of power HTML, CSS and JavaScript have now is honestly kinda insane.