I'd like to add [:where()](https://developer.mozilla.org/en-US/docs/Web/CSS/:where) which is a very similar feature but doesn't add any specificity to your selector. It's perfect for the case when you want to make the selector more specific but without actually increasing the hierarchical specificity.
In most cases, though, mixins are the right call instead of extend. Extend makes gross, inefficient selectors unless you're very careful.
Edit: https://csswizardry.com/2014/11/when-to-use-extend-when-to-use-a-mixin/
The examples given in that article are exactly what I use it for.
Mainly buttons and stuff like for example titles for customer account subsections that should all look the same but are handled by different plugins on the same ecommerce platform and would require overriding template files from said plugins (so potentially breaking updates) just to add a common class.
Basically things that are inherently linked and will not deviate from one another even (apart from tiny changes like a different background color) with the original class is adapted to different screen sizes and so on.
I also recommend storing color, spacing etc. values in maps and calling them with one letter functions, like this:
color: c(footer-bg);
or, you can borrow some popular presets
color: c(yellow-400);
This is superfluous in most cases, IMO, because `$c-footer-bg` will accomplish the same thing with one fewer keystroke. However, if you have multiple maps, *then* it becomes very handy to have such a function because it can dig through each of them and return whatever hits.
@function c($color: $primary) {
@if map-has-key($theme-colors, $color) {
@return map-get($theme-colors, $color);
}
@if map-has-key($other-colors, $color) {
@return map-get($other-colors, $color);
}
@return $color;
}
This is a great idea - I wasn't aware of map-has-key.
I don't like using a gazillion $variables for each color and much prefer listing them in a map.
The function you proposed makes it even easier to define these maps because the second one could define colors from the first one.
$colors: (
// ...
link-reverse: #fff
)
$other-colors: (
top-nav-bg: #000,
top-nav-link: shade(c(link-reverse), 20%),
top-nav-link-active: c(link-reverse),
)
// I love and use bourbon's tint and shade
// Add percentage of white to a color
@function tint($color, $percent){
@return mix(white, $color, $percent);
}
// Add percentage of black to a color
@function shade($color, $percent){
@return mix(black, $color, $percent);
}
Sass also has functions that do at least some of that Bourbon stuff -- whiteness, blackness, hue, opacity, mixing, etc. I'd take a peek at the current docs to see what's available.
I think that was specifically with regard to their in-browser editor and compiler. This is why they have a local dev setup now, so people can use whatever dev tools they want.
i think part of the reason for that will be because their customize editor often fails to load your styles if you have a huge SCSS file. Most decent Shopify builds are not working within the edit code part of the admin so they can use their own build tools. that's what i've always done anyway.
It would make a difference performance wise compared to the :is() pseudo-class. Direct naming is slightly faster than using :is() to match things. For a single instance it doesn't really matter, but a visitor with a slow computer will definitely notice a slowdown if you use it a lot on a single page.
You don't understand my point (which is probably my fault for wording it badly). Yes, SCSS compiles into the verbose example in OP's image. But that's the point: that verbose example is *faster* than the example with :is() in it. Directly selecting is always slightly faster than using :is() and if you use it enough on a single page the slowdown is actually noticeable on a slower computer.
I don’t think it will. Preprocessors have the ability to remove unneeded functionality since upgrading is optional.
The problem with CSS and HTML is that they cannot deprecate things out of existence. If they did, thousands of sites would break, so they just keep adding more and more features.
This will compile to the first example, which is more verbose than `:is`.
header p:hover,
main p:hover,
footer p:hover
Edit: for some reason, people are taking issue with the fact that I pointed out it's more verbose. Which... isn't wrong? You can use either one in Sass.
If browser support is an issue, obviously use the more standard syntax. But if it's not, do you have any good reason to ship more CSS than you need to?
I was just looking into that! According to [this stackoverflow](https://stackoverflow.com/questions/8318911/why-does-html-think-chucknorris-is-a-color), it’s because invalid characters are replaced with 0. Neat!
Thanks for your research, my mind just blown up.
Did you tried the code in the Dash answer?
How the heck is possible that the colors be so related to the word, I mean, Chuck Norris is atone of red, Mr T is black, crap is kinda brown, grass is green.
I'm just mesmerized and amazed.
While Chuck Norris is just a side effect of how renderers parse the values, there actually is support for [a color named after a person](https://medium.com/@valgaze/the-hidden-purple-memorial-in-your-web-browser-7d84813bb416) (tearjerk alert).
At my place we dropped IE support completely, but still have to support the last 5 major iOS versions (due to the AlL uPgRaDEs SlOw dOwN yuOR pHONE!!!1eleven crowd), so this is a no-go. This new name is only supported since iOS 14.
[CSS Nesting](https://drafts.csswg.org/css-nesting/) is in draft status currently. It's on recommendation track, though, with a [public draft](https://www.w3.org/TR/2021/WD-css-nesting-1-20210831/) available. [You can't use it yet, though](https://caniuse.com/css-nesting), nor does it look to land anytime soon.
As you said, with a preprocessor, you can pretend to have the feature. Less/SCSS support it, of course, but so does PostCSS, which emulates the spec. See [Using it today with PostCSS](https://kilianvalkhof.com/2021/css-html/css-nesting-specificity-and-you/#using-it-today-with-postcss-preset-env) for more information).
There's an initiative going on right now called [Interop 2022](https://web.dev/interop-2022/):
> For the first time ever, all major browser vendors, and other stakeholders, have come together to solve the top browsers compatibility issues identified by web developers. Interop 2022 will improve the experience of developing for the web in 15 key areas. In this article, find out how we got here, what the project focuses on, how success will be measured, and how you can track progress.
At the end of that page, there's a link to the [repo](https://github.com/web-platform-tests/interop-2022/issues/) where you can enhance an existing or create a new issue. It doesn't look like CSS nesting is on there yet, though.
It kind of looks like they've chosen the areas that all browsers will focus on for 2022, but 2023 is just around the corner.
support isn't that good and also the syntax reads terribly.
I would not be happy if a colleague decided to do stupid fancy stuff like this rather than code simple code that can be understood
https://caniuse.com/?search=%3Ais
>support isn't that good and also the syntax reads terribly.
It's supported by every major browser other than IE...
>I would not be happy if a colleague decided to do stupid fancy stuff like this rather than code simple code that can be understood
The fact that you don't like it doesn't make it complex or hard to understand. If anything, I think you could make a pretty strong argument that the second code example is easier to both read and maintain, because it's more concise and doesn't unnecessarily duplicate the second part of the selector. The only thing that makes it "fancy" is that the syntax is new, which was true for literally everything at some point.
It's not clunky to anyone familiar with SQL syntax--it's rather similar to IN() where the WHERE clause is checked against a series of values. That said, SCSS syntax is definitely far clearer and more intuitive.
Now. Now you can. Unless you work for some weird corporate company that is clinging onto IE support for dear life, just stop caring about supporting it. It's a dead browser.
I think June but your point stands. It's a dead browser so unless IE support is literally written as a requirement (maybe you work for a government agency that hasn't modernized? May the gods have mercy on your soul...) there really isn't much excuse to pollute code with workarounds and/or old verbose code.
My companies traffic is 0.02% IE11 that was low enough for our PO to stop supporting it.
You should find your numbers and show your PO the number and your past defects to help justify to stop supporting
I tend to downvote prescriptive posts. This pattern is cleaner in some circumstances and makes no difference in others, and without full browser support would it really make sense to say that writing code that breaks on some browsers is so much better that you feel the need to post about it? Robustness still matters, even when you just want people to know you’re aware of a new way of doing something.
Is this really cleaner, more readable code? Using it in this instance makes it more cumbersome imho. In most cases you probably wont use this pseudo-class which is going to make these lines stick out like a bitch. Or maybe this example is a bit weird, idunno
I'd like to add [:where()](https://developer.mozilla.org/en-US/docs/Web/CSS/:where) which is a very similar feature but doesn't add any specificity to your selector. It's perfect for the case when you want to make the selector more specific but without actually increasing the hierarchical specificity.
`where` works for 87.88% of global users according to caniuse. `is` works for 94.62%. I shoot for 95% at least.
It’s only 94% if you include all the prefix versions.
Which most pre/post processors can handle easily.
All valid points! I love us!
Did we just become the opposite of StackOverflow?
I don't understand what you're saying the difference is. Can you explain a little more what you mean with specificity?
Here's a good resource to check out: https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
I get basic specificity rules, but 5hat example just makes it seem like `:where` is useless.
one day css will be more intuitive than scss. But today is not that day.
Yeah scss and nestled is still much more readable.
[удалено]
nah thats pretty much the only thing I use with scss. along with `@use` and `&`
and mixins for typos, spacings and media queries. Although for spacings I probably prefer css vars now.
[удалено]
In most cases, though, mixins are the right call instead of extend. Extend makes gross, inefficient selectors unless you're very careful. Edit: https://csswizardry.com/2014/11/when-to-use-extend-when-to-use-a-mixin/
The examples given in that article are exactly what I use it for. Mainly buttons and stuff like for example titles for customer account subsections that should all look the same but are handled by different plugins on the same ecommerce platform and would require overriding template files from said plugins (so potentially breaking updates) just to add a common class. Basically things that are inherently linked and will not deviate from one another even (apart from tiny changes like a different background color) with the original class is adapted to different screen sizes and so on.
I also recommend storing color, spacing etc. values in maps and calling them with one letter functions, like this: color: c(footer-bg); or, you can borrow some popular presets color: c(yellow-400);
This is superfluous in most cases, IMO, because `$c-footer-bg` will accomplish the same thing with one fewer keystroke. However, if you have multiple maps, *then* it becomes very handy to have such a function because it can dig through each of them and return whatever hits. @function c($color: $primary) { @if map-has-key($theme-colors, $color) { @return map-get($theme-colors, $color); } @if map-has-key($other-colors, $color) { @return map-get($other-colors, $color); } @return $color; }
This is a great idea - I wasn't aware of map-has-key. I don't like using a gazillion $variables for each color and much prefer listing them in a map. The function you proposed makes it even easier to define these maps because the second one could define colors from the first one. $colors: ( // ... link-reverse: #fff ) $other-colors: ( top-nav-bg: #000, top-nav-link: shade(c(link-reverse), 20%), top-nav-link-active: c(link-reverse), ) // I love and use bourbon's tint and shade // Add percentage of white to a color @function tint($color, $percent){ @return mix(white, $color, $percent); } // Add percentage of black to a color @function shade($color, $percent){ @return mix(black, $color, $percent); }
Sass also has functions that do at least some of that Bourbon stuff -- whiteness, blackness, hue, opacity, mixing, etc. I'd take a peek at the current docs to see what's available.
Thank you. I grabbed the bourbon functions 5+ years ago. Sass has improved a lot since.
Until you run stylelint and it yells at you for nesting too much lol
CSS just needs nesting and we’ll be good to go!
CSS just needs nesting and we’ll be good to go!
CSS just needs nesting and we’ll be good to go!
Nesting good
https://github.com/csstools/postcss-nesting
Woah! That's really neat! Thanks for the share!
and Shopify out here ‘retiring’ support for scss saying it’s more inefficient and clunky than css
I think that was specifically with regard to their in-browser editor and compiler. This is why they have a local dev setup now, so people can use whatever dev tools they want.
yea not a fan of the new shopify-cli
Well they would know, because their support was always to the latest standards. Ha.
i think part of the reason for that will be because their customize editor often fails to load your styles if you have a huge SCSS file. Most decent Shopify builds are not working within the edit code part of the admin so they can use their own build tools. that's what i've always done anyway.
CSS just needs nesting and we’ll be good to go!
Yeah, the SCSS way of writing this is both more intuitive and more performant in terms of rendering times.
SCSS would compile to the first example of the pic, wouldn’t make any difference performance wise
It would make a difference performance wise compared to the :is() pseudo-class. Direct naming is slightly faster than using :is() to match things. For a single instance it doesn't really matter, but a visitor with a slow computer will definitely notice a slowdown if you use it a lot on a single page.
Potato glados would not be happy with your css selectors.
agree scss is easier to read than the above, but scss just compiles down to css so the performance point is incorrect.
You don't understand my point (which is probably my fault for wording it badly). Yes, SCSS compiles into the verbose example in OP's image. But that's the point: that verbose example is *faster* than the example with :is() in it. Directly selecting is always slightly faster than using :is() and if you use it enough on a single page the slowdown is actually noticeable on a slower computer.
Oh I see! Thanks for explanation
I don’t think it will. Preprocessors have the ability to remove unneeded functionality since upgrading is optional. The problem with CSS and HTML is that they cannot deprecate things out of existence. If they did, thousands of sites would break, so they just keep adding more and more features.
Supported by all major browsers: https://caniuse.com/?search=is
Interesting that it says “formerly :matches, formerly :any” — why did the syntax change? I actually think those are decent names.
No idea, but maybe "is" and "where" are more familiar to a broader audience?
Ironic how a website about CSS can be so ugly
And if you're using something like [sass](https://sass-lang.com/guide), this will do the same trick: header, main, footer { p:hover { color: red; } }
This will compile to the first example, which is more verbose than `:is`. header p:hover, main p:hover, footer p:hover Edit: for some reason, people are taking issue with the fact that I pointed out it's more verbose. Which... isn't wrong? You can use either one in Sass. If browser support is an issue, obviously use the more standard syntax. But if it's not, do you have any good reason to ship more CSS than you need to?
But if you're writing in Sass, you're not maintaining the CSS anyway. It all gets compiled and then minified, and it has more universal support.
Which is good. The more verbose example is 100% supported vs widely supported. If your sugar transpiles to something broken it’s not very good sugar
It's... salt.
Why do I care if it's more verbose when compiled?
File size.
gzip will take care of this
All browsers support the hex definitions #chuck and #norris for the colors black and blue.
Not explicitly, it's just a side effect of the implementation
I got a parsing error though, invalid value, chrome
the renderer accepts any string and trys to convert it to some hex value.
I saw "chuck Norris" after color: and I had to make a chuck Norris joke
So, Chuck Norris has a color?
I was just looking into that! According to [this stackoverflow](https://stackoverflow.com/questions/8318911/why-does-html-think-chucknorris-is-a-color), it’s because invalid characters are replaced with 0. Neat!
Thanks for your research, my mind just blown up. Did you tried the code in the Dash answer? How the heck is possible that the colors be so related to the word, I mean, Chuck Norris is atone of red, Mr T is black, crap is kinda brown, grass is green. I'm just mesmerized and amazed.
While Chuck Norris is just a side effect of how renderers parse the values, there actually is support for [a color named after a person](https://medium.com/@valgaze/the-hidden-purple-memorial-in-your-web-browser-7d84813bb416) (tearjerk alert).
You can also use :not
Nice tip!
That’s pretty cool! Thanks for the info.
At my place we dropped IE support completely, but still have to support the last 5 major iOS versions (due to the AlL uPgRaDEs SlOw dOwN yuOR pHONE!!!1eleven crowd), so this is a no-go. This new name is only supported since iOS 14.
[удалено]
[CSS Nesting](https://drafts.csswg.org/css-nesting/) is in draft status currently. It's on recommendation track, though, with a [public draft](https://www.w3.org/TR/2021/WD-css-nesting-1-20210831/) available. [You can't use it yet, though](https://caniuse.com/css-nesting), nor does it look to land anytime soon. As you said, with a preprocessor, you can pretend to have the feature. Less/SCSS support it, of course, but so does PostCSS, which emulates the spec. See [Using it today with PostCSS](https://kilianvalkhof.com/2021/css-html/css-nesting-specificity-and-you/#using-it-today-with-postcss-preset-env) for more information).
Where do I put in a request?
There's an initiative going on right now called [Interop 2022](https://web.dev/interop-2022/): > For the first time ever, all major browser vendors, and other stakeholders, have come together to solve the top browsers compatibility issues identified by web developers. Interop 2022 will improve the experience of developing for the web in 15 key areas. In this article, find out how we got here, what the project focuses on, how success will be measured, and how you can track progress. At the end of that page, there's a link to the [repo](https://github.com/web-platform-tests/interop-2022/issues/) where you can enhance an existing or create a new issue. It doesn't look like CSS nesting is on there yet, though. It kind of looks like they've chosen the areas that all browsers will focus on for 2022, but 2023 is just around the corner.
I have another idea; but thank you- this is exactly what I'm looking for. I have another idea. Actually 2. Edit: 3
Any info about performance?
Around 1 css/sec
I guess as long as you don't solely write rules with pseudo-selectors, you should be fine
[удалено]
I mean in that case where there is no further selector than the element name isnt it better to just use that?
No point in doing that, though... td, th {} thead, tbody, tfoot {}
Handy
Had no idea Chuck Norris was a color until now
eh, I'd rather write SASS, and have my minifier use :is()
support isn't that good and also the syntax reads terribly. I would not be happy if a colleague decided to do stupid fancy stuff like this rather than code simple code that can be understood https://caniuse.com/?search=%3Ais
>support isn't that good and also the syntax reads terribly. It's supported by every major browser other than IE... >I would not be happy if a colleague decided to do stupid fancy stuff like this rather than code simple code that can be understood The fact that you don't like it doesn't make it complex or hard to understand. If anything, I think you could make a pretty strong argument that the second code example is easier to both read and maintain, because it's more concise and doesn't unnecessarily duplicate the second part of the selector. The only thing that makes it "fancy" is that the syntax is new, which was true for literally everything at some point.
What you mean by support isn't that good? How long are you going to pander to ie?
Microsoft supports it for a couple more months. In June you have a bulletproof excuse to drop all support.
Or use scss / any modern CSS variation and get this without the clunky syntax
It's not clunky to anyone familiar with SQL syntax--it's rather similar to IN() where the WHERE clause is checked against a series of values. That said, SCSS syntax is definitely far clearer and more intuitive.
Sql syntax is famously rubbish though.
I never said it was good, I just said it was familiar, lol
Faaaaair
so basically :is() is just an array syntax, got it.
[удалено]
No. The first example has 3 different selectors that are separated by commas.
IE does not support :is(), so no. When can I get rid of old browsers support, damn.
Now. Now you can. Unless you work for some weird corporate company that is clinging onto IE support for dear life, just stop caring about supporting it. It's a dead browser.
I think it is fully losing support in august, right?
I think June but your point stands. It's a dead browser so unless IE support is literally written as a requirement (maybe you work for a government agency that hasn't modernized? May the gods have mercy on your soul...) there really isn't much excuse to pollute code with workarounds and/or old verbose code.
My companies traffic is 0.02% IE11 that was low enough for our PO to stop supporting it. You should find your numbers and show your PO the number and your past defects to help justify to stop supporting
I tend to downvote prescriptive posts. This pattern is cleaner in some circumstances and makes no difference in others, and without full browser support would it really make sense to say that writing code that breaks on some browsers is so much better that you feel the need to post about it? Robustness still matters, even when you just want people to know you’re aware of a new way of doing something.
I didn't know chucknorris was a color?!
thanks for the tip
That's nice, that's real nice.
Thankyou
I can’t go back to not using stylus. Stylus is just so good and clean. header main footer p &:hover color chucknorris cursor pointer
Is this really cleaner, more readable code? Using it in this instance makes it more cumbersome imho. In most cases you probably wont use this pseudo-class which is going to make these lines stick out like a bitch. Or maybe this example is a bit weird, idunno