As a fullstack i think frontend is very easy but just more and thus more complex, backend is also very easy tbh - but styling is the most easy frontend task
There is one important thing worth noting regarding browser support that Can I Use doesn’t show: The current Safari implementation is based on an older version of the specification. This seems to be fixed in Technology Preview, but it’s not yet in stable (and I have not seen this mentioned in the release notes for the 17.6 nor 18.0 betas). The main interoperability issue between the two specs is that the current one implemented in Chrome and Firefox treats the color channel tokens as unitless values in calculations, whereas the older spec implemented in Safari gives many of those tokens an implicit unit, such as `%` or `deg`. As such, by adhering to the Safari behavior, you risk making the entire declaration in Chrome invalid and vice versa. This is only important to keep in mind when using addition or subtraction on certain color channels, since you can’t for example subtract `180deg` or `20%` with a unitless value or vice versa (but you can multiply and divide). Worth noting is also that Safari treats the channels in relative rgb colors as values between 0% - 100%, whereas in Chrome they are unitless values between 0 - 255 (still not a problem if you use multiplication or division). Relative (ok)lab colors don’t have this problem since all those channels are unitless in both implementations. Same for chroma and lightness (but not hue) in relative (ok)lch colors. It’s also worth underlining that both implementations accept unit values not inside a calc function. Luckily you can test for both behaviors using support queries. That opens up for a solution looking something like this: :root { /* Test for the correct behavior implemented in Chrome, Firefox and Safari TP */ @supports (color: hsl(from red calc(h + 1) calc(s + 1) l)) { --u-deg: 1; --u-%: 1; } /* Test for the old spec behavior in Safari. Returns false in Chrome, Firefox and Safari TP */ @supports (color: hsl(from red calc(h + 1deg) calc(s + 1%) l)) { --u-deg: 1deg; --u-%: 1%; } } .element-with-relative-color { color: hsl(from red calc(h + 25 * var(--u-deg)) s calc(l - 20 * var(--u-%))); }
Kevin, when you were giving examples like `rgb(from purple r r r)` or `b b b`, you said "we don't really have a lot of red in there" and the text became gray. The reason for that is very easy: if you put the same value on all rgb channels, you always get a grayscaled color.
He said that because the text became rally dark, because the r value is low so he's getting a dark color. He then used the b because the b value was higher so the text was lighter, and so more legible because of the dark background.
@@lacavernedug33k but he also followed up the `b b b` with the comment "and then we might get a bit more of a color coming through", hence my original comment. But then again, I trust Kevin knowing what he's doing and it might just be the mouth running quicker than the brain sometimes. :)
This is one I’ve been checking on every two weeks and started using in an @supports last month ! Makes everything so clean and more convenient so I’m not having to manually convert hex values to oklch ❤ relative colours rock!!!
Opacity is great but being able to replace darken and lighten from scss with a way that supports custom properties is a big game changer for cleaner css (especially cleaner :root var definitions)
Wow! That is just great. This is giving me a real nice color scale. Without opacity. Calculating from 68% (for this example) to 95% (really light version) in 9 steps.. --color-primary: hsl(227, 100%, 68%); --color-primary-10: hsl(from var(--color-primary) h s calc( l + (( 95 - l ) / 9) * 9 )); --color-primary-20: hsl(from var(--color-primary) h s calc( l + (( 95 - l ) / 9) * 8 )); etc...
You speak about CSS with such ease, despite a lot of the things having a skill curve of, "oh boy, I am going to need a separate video before I continue". That is the mark of the master.
Careful adding/subtracting to color components as you can go out of gamut limits quite quickly e.g. oklch(from red l calc(c + 1) h). Prefer using multiply and divide.
When I just want to change the brightness of a button on hover, I normally use filter: brightness(). I find this method more convenient for such cases. However, for creating color schemes and other fancy coloring, relative colors are fantastic. Thank you for showing this. It opens up so many opportunities. Thats why i love your channel. Learning more good stuff every day =)
Hey @KevinPowell, someone might have already pointed out... At the top of the video (first lines of code, in :root) your have a mistaken --clr-brand: rgb(var(--clr-brand)); I think you meant: --clr-brand: rgb(var(--clr-brand-rgb)); as refleted in the second block of code (with all the other color variables) Great video, thanks for all the quality content!
OMG, this! I couldn't believe this wasn't possible when I started trying to mix colors to achieve the right contrast for accessibility across several color schemes🙈Feels like CSS has been catching up with the developers' demands for yearzzz! Thanks for your great updates💚
Here is another approach for hover/focus states using variables with fallback values. I think I’d prefer it in situations where declaring an extra variable for the origin color feels a bit verbose. button { background-color: oklch(from var(--clr-button) var(--bg-lightness, l) c h); &:hover { --bg-lightness: calc(l - 20); } }
I literally finished my project yesterday with the same exact issue. I had a accent color but had to constantly put it's value everywhere I wanted some transparency.
Kevin, have you thought about doing a video where this new "relative colors" can be implemented with tailwind css variables... Would be a great video! Thx in advance.
OMG, it's just crazy) Kevin, can you advise something to read/watch about hsl and all this "weird" color functions? I where I could understand how this works) p.s you are a css monster and I happy that TH-cam algos gave me your channel) hope one day I'll bought your course and say you thanks this way for all your job
Great video! Question: How can you ensure the colors with these changes match the Color Safety within the WCAG Guidelines? Thanks! Colors aren't easy when it has to do with these guidelines. If you have any way to simplify the process of creating color schemes within these guidelines, I will forever be grateful.
I've been waiting a long time for this! Big question, though: IN GENERAL, how long should one wait before using new CSS features in production? Either a fixed set of time, or a number of browser versions that have been released with this feature support, or...?
Usually you want to keep an eye on support numbers ( caniuse.com is where to do that). Ideally, you'll know your own analytics to be able to make a decision. Many teams have a percentage support they aim for... knowing your audience helps here, with some you might want to wait for 97%+ support, others are more comfortable with lower 🤷
Even though I like this for most cases and would use it on something like a blog. I feel like it has maintainability issues in the long term. Colors can change from season to season and due to how accessabilty works with colors this might not work for that. Not saying you can not edit all of the things per season, but it sort of goes back to the pre-way to do this stuff before.
Can you make a video about vw vs w unit, why does vh used in height when creating a page website but not vw for width? I rarely see vw unit being used for width and percentage are frequently used over it. Im a html/css beginner
I have a question. I'm trying to understand the behavior of REM units when used for element positioning. While pixels (px) maintain a fixed position regardless of font size, using REM seems to lock the element's screen position and it is a good thing but i don't know if it is applicable to every scenario. I expected REM unit to cause some shifts in positioning based on the root font size. Can someone explain the relationship between using REM for positioning and how it affects an element's screen location?
A shame it doesn’t work with light-dark, but you can create for primary eg -primary-light: blue -primary-dark: lightblue -primary: light-dark(var(-primary-light), var(-primary-dark)) And now you can use both light and dark for like hover or whatever -primary-hover-light: hsl(from var(-primary-light) h s calc(l * 0.5)) -primary-hover-dark: hsl(from var(-primary-dark) h s calc(l * 0.5)) -primary-hover: light-dark(var(-primary-hover-light), var(-primary-hover-dark)) If it could just work we could have this: -primary: light-dark(blue, lightblue) -primary-hover: hsl(from var(-primary) h s calc(l * 0.5)) But I’ve only played around with this for the past hour or so maybe I’ve missed something. If anyone could share some light to this would be cool
i'll stay with my --color: X X% X%; and using hsl(var(--color)); or hsl(var(--color) / .X); for now, because the new approach has only a partial support
Hey Kevin, go look at the browser support link again? It's different than what you're showing in the video. They are all marked as partial support now...?
Hey guys! I am always wondering where do you guys test these new CSS features, because when I try to do so in my React apps I can never achieve this. Not sure if I need to update something or if CSS updates are automatically spreaded over the code bases.
Not sure where the win is over what I was doing before. Literally, the CSS on my company page: --root-hue: 165; --base-hue: var(--root-hue); --contrast-hue: calc(var(--base-hue) + 180); --alternate-hue: calc(var(--base-hue) + 90); --base-color-100: hsla( var(--base-hue), 100%, 1); --base-color-90: hsla( var(--base-hue), 90%, 1); ... --contrast-color-90: hsla( var(--contrast-hue), 90%, 1); And the HTML looks like this: Hello World Click me A simple change to --root-hue recolors the entire page in a consistent way, and it will always look good.
i was watching your videos for a while and i never heard you talking about lch and oklch.....this is my first time hearing them can u please make a simple video about them
Thanks Kevin, this is awesome, but I'm confused about 1 thing...why is it divide and not multiply? For example, if we take 200 and divide by 50%, that becomes 400, which is actually an increase in the values. Note - referring to the first part of the video.
It's not a division, it's just a visual separator between the color values and the opacity. If it was a division, it'd be inside a calc() or other math function.
While these new color opportunities are kind of amazing, I find myself struggling using them effectively. 🫠 What I mean is: I‘m doing CSS for almost two decades now. And Hex and RGB(A) is so embedded in my mind, that I don‘t think about hsl or other stuff when it actually would make sense. At least, I‘m starting using color-mix(), though. Kevin, if you‘d like, a beginners video about all color related options would be great. 😊 (As a non-English-native speaker, I can‘t even grasp what the basic idea of hsl really means (is it hue, saturation and lightning?) And how it‘s affecting my color. While with rgb, obviously it affects the main three colors. That is my problem really. 😢)
HSL is hue, saturation, lightness. Hue is the color of the rainbow. Lightness is how bright or dark the color is. And saturation is how much color the item contains. To get a feel for this, you probably should mess around with a color picker. Look up HSL color picker on Google, and play around with sliders for HSL to see how the colors change.
a video explaining a little about the science behind the multiple color models in CSS would be great! there is probably others on TH-cam covering this topic already
Oh, I use it in TailwindCSS with --picked-color and deep/bright/neon/pastel versions of it with options to add/multiply lightness and chroma and rotate hue over oklch!
They keep adding more and more things to CSS. I think almost all of the added things are good but I do worry that we're heading towards a Franken-CSS monster with so much complexity that new web devs will be unable to learn enough for CSS to be a useful tool.
The nice thing is, all the new things are on top of what's already there. You can still learn the basics and make websites, and as you continue to learn, add the newer things. The hard part for new devs is being able to know where to go, or what to learn first, and that's on the people who are educating to make that part easy :)
And the fun part about covering CSS based on a working draft, a new feature was added to the working draft so now the CanIUse chart looks a lot worse despite the fact that the new feature is the only thing not covered in most browsers. The new feature? You can use currentColor or a system-color as your origin color.
The functionality of this method is great, but my issue with it is the human legibility of it. It's very abstract. If someone comes into the project with no lesser knowledge, they are going to be wondering wtf is going on.
@@blazingelse9104 I don't think that's really true because CSS is clearly trying to adopt the ideas behind "preprocessors" (Sass) and why would you care about the code that Sass generates? It's just simply CSS that you have written, nothing more. Do you really look the code "bandel" that the frameworks generates? Perhaps, if you know Sass well, you can generate advanced color palettes and other styles with many useful and much simpler functions that Sass has, and use lists, maps, loops and more programming functionalities to generate a complete themes, just as the most famous CSS frameworks do, for some reason they also use Sass. It's just my opinion, I totally respect other ways of developing.
@@ToniTerremoto I didn't say Sass/Scss is bad or anything. I like it for mixins for example. I Just said it's less powerful and usually more verbose for features that CSS has adopted itself. You simply cannot generate shades of a color with sass if they color itself is set at runtime. With CSS you can. With sass, you cannot calculate with relative sizes. With CSS you can. Unfortunately, CSS functions like min or max now name clash with scss functions. Scss should just drop those functions in order to stay compatible and be more useful.
@@blazingelse9104 Thanks, I totally respect your opinion and your way of developing. CSS does not have the Superpowers that Sass has, yet. For that example of the shadow in runtime that you propose, you would not have it done well only with Css (without Js) and Css clearly does not use logic to know if that shadow will be cast on a dark theme background or if it has good contrast, and that's why I think it's always a good idea to separate the "presentation" (CSS) from the "behavior" (JS, runtime), the same for the other cases that you propose, like relative measures. It's just my way of developing, those things are not useful to me. A cordial greeting. 🫂✌🏼
I want to share this with all the backend dev's that have teased us frontend devs by saying "but you just change colors right?"
They think it's easy but when you review their CSS or JS it's absolute💩
@@bazzle_brush They still use the easy "jQuery lib". Horrific!
lol
@@bazzle_brushfull stack of 💩
As a fullstack i think frontend is very easy but just more and thus more complex, backend is also very easy tbh - but styling is the most easy frontend task
There is one important thing worth noting regarding browser support that Can I Use doesn’t show: The current Safari implementation is based on an older version of the specification. This seems to be fixed in Technology Preview, but it’s not yet in stable (and I have not seen this mentioned in the release notes for the 17.6 nor 18.0 betas).
The main interoperability issue between the two specs is that the current one implemented in Chrome and Firefox treats the color channel tokens as unitless values in calculations, whereas the older spec implemented in Safari gives many of those tokens an implicit unit, such as `%` or `deg`. As such, by adhering to the Safari behavior, you risk making the entire declaration in Chrome invalid and vice versa.
This is only important to keep in mind when using addition or subtraction on certain color channels, since you can’t for example subtract `180deg` or `20%` with a unitless value or vice versa (but you can multiply and divide). Worth noting is also that Safari treats the channels in relative rgb colors as values between 0% - 100%, whereas in Chrome they are unitless values between 0 - 255 (still not a problem if you use multiplication or division).
Relative (ok)lab colors don’t have this problem since all those channels are unitless in both implementations. Same for chroma and lightness (but not hue) in relative (ok)lch colors. It’s also worth underlining that both implementations accept unit values not inside a calc function.
Luckily you can test for both behaviors using support queries. That opens up for a solution looking something like this:
:root {
/* Test for the correct behavior implemented in Chrome, Firefox and Safari TP */
@supports (color: hsl(from red calc(h + 1) calc(s + 1) l)) {
--u-deg: 1;
--u-%: 1;
}
/* Test for the old spec behavior in Safari. Returns false in Chrome, Firefox and Safari TP */
@supports (color: hsl(from red calc(h + 1deg) calc(s + 1%) l)) {
--u-deg: 1deg;
--u-%: 1%;
}
}
.element-with-relative-color {
color: hsl(from red calc(h + 25 * var(--u-deg)) s calc(l - 20 * var(--u-%)));
}
Crazy how this isn't mentioned on caniuse. How does one report something there? Couldn't find a way.
Kevin, when you were giving examples like `rgb(from purple r r r)` or `b b b`, you said "we don't really have a lot of red in there" and the text became gray. The reason for that is very easy: if you put the same value on all rgb channels, you always get a grayscaled color.
He said that because the text became rally dark, because the r value is low so he's getting a dark color.
He then used the b because the b value was higher so the text was lighter, and so more legible because of the dark background.
@@lacavernedug33k but he also followed up the `b b b` with the comment "and then we might get a bit more of a color coming through", hence my original comment. But then again, I trust Kevin knowing what he's doing and it might just be the mouth running quicker than the brain sometimes. :)
This is one I’ve been checking on every two weeks and started using in an @supports last month ! Makes everything so clean and more convenient so I’m not having to manually convert hex values to oklch ❤ relative colours rock!!!
Opacity is great but being able to replace darken and lighten from scss with a way that supports custom properties is a big game changer for cleaner css (especially cleaner :root var definitions)
Hey Kevin, everything you do with these videos is so great, clear and to the point... thank you... keep it up please !!!
This feature is the best addition to CSS ever!! It makes implementing colorblind accessibility much easier on my projects!!!
Absolutely love it, been waiting for something like this for years, thanks for sharing!
Wow! That is just great. This is giving me a real nice color scale. Without opacity. Calculating from 68% (for this example) to 95% (really light version) in 9 steps..
--color-primary: hsl(227, 100%, 68%);
--color-primary-10: hsl(from var(--color-primary) h s calc( l + (( 95 - l ) / 9) * 9 ));
--color-primary-20: hsl(from var(--color-primary) h s calc( l + (( 95 - l ) / 9) * 8 ));
etc...
Amazing video! Always thankful to have someone cover on css features like this. 👍
I remember trying to make this work in SASS last year. 😂
Now, it's finally a feature. Nice! 🎉
You speak about CSS with such ease, despite a lot of the things having a skill curve of, "oh boy, I am going to need a separate video before I continue".
That is the mark of the master.
Thanks!
Thanks 😊
I was using color-mix function for this type of things:
color-mix(in srgb, red, transparent 50%)
But now it’s much easier!
Careful adding/subtracting to color components as you can go out of gamut limits quite quickly e.g.
oklch(from red l calc(c + 1) h).
Prefer using multiply and divide.
When I just want to change the brightness of a button on hover, I normally use filter: brightness(). I find this method more convenient for such cases. However, for creating color schemes and other fancy coloring, relative colors are fantastic. Thank you for showing this. It opens up so many opportunities. Thats why i love your channel. Learning more good stuff every day =)
Hey @KevinPowell, someone might have already pointed out... At the top of the video (first lines of code, in :root) your have a mistaken --clr-brand: rgb(var(--clr-brand));
I think you meant: --clr-brand: rgb(var(--clr-brand-rgb)); as refleted in the second block of code (with all the other color variables)
Great video, thanks for all the quality content!
OMG, this! I couldn't believe this wasn't possible when I started trying to mix colors to achieve the right contrast for accessibility across several color schemes🙈Feels like CSS has been catching up with the developers' demands for yearzzz! Thanks for your great updates💚
Here is another approach for hover/focus states using variables with fallback values. I think I’d prefer it in situations where declaring an extra variable for the origin color feels a bit verbose.
button {
background-color: oklch(from var(--clr-button) var(--bg-lightness, l) c h);
&:hover {
--bg-lightness: calc(l - 20);
}
}
oh, that's a cool idea!
This is great. I have been over using color-mix with transparent and a percentage to do this.
Super cool! I generally use hsl and constantly have to go and convert things. Now I can make the browser do my bidding for me
Wow 😖where was this years ago... I had to use SASS and some hacky way of splitting the HSL in each variable 😭😪... thanks Kevin
I literally finished my project yesterday with the same exact issue. I had a accent color but had to constantly put it's value everywhere I wanted some transparency.
I have a feeling css syntax is gonna be assemblish soon :)
ahh, its kind of like destructuring. so cool!
Daym, this is actually a sick feature
Great video Kevin! 💜
Kevin, have you thought about doing a video where this new "relative colors" can be implemented with tailwind css variables... Would be a great video! Thx in advance.
This is very cool I can't wait to use it in production
OMG, it's just crazy) Kevin, can you advise something to read/watch about hsl and all this "weird" color functions? I where I could understand how this works)
p.s you are a css monster and I happy that TH-cam algos gave me your channel) hope one day I'll bought your course and say you thanks this way for all your job
Great video! Question: How can you ensure the colors with these changes match the Color Safety within the WCAG Guidelines? Thanks! Colors aren't easy when it has to do with these guidelines. If you have any way to simplify the process of creating color schemes within these guidelines, I will forever be grateful.
I've been waiting a long time for this! Big question, though: IN GENERAL, how long should one wait before using new CSS features in production? Either a fixed set of time, or a number of browser versions that have been released with this feature support, or...?
Usually you want to keep an eye on support numbers ( caniuse.com is where to do that). Ideally, you'll know your own analytics to be able to make a decision. Many teams have a percentage support they aim for... knowing your audience helps here, with some you might want to wait for 97%+ support, others are more comfortable with lower 🤷
This is great! Thanks for sharing this.
Even though I like this for most cases and would use it on something like a blog.
I feel like it has maintainability issues in the long term. Colors can change from season to season and due to how accessabilty works with colors this might not work for that. Not saying you can not edit all of the things per season, but it sort of goes back to the pre-way to do this stuff before.
Can we use “ifs” inside calc?
This came at the right time
I love it. How about browser support?
Just saw you already addressed it in the video. Thank you.
Can you make a video about vw vs w unit, why does vh used in height when creating a page website but not vw for width? I rarely see vw unit being used for width and percentage are frequently used over it. Im a html/css beginner
This is great. Thanks for this.
It would be interesting to see if you could make a full 3 or 4 color palette based on a single color tweaked up and down.
So, can we sunset sass like with lodash? Both great products. Both advanced the developer experience. And both no longer necessary
This is pretty cool gotta admit
I have a question. I'm trying to understand the behavior of REM units when used for element positioning. While pixels (px) maintain a fixed position regardless of font size, using REM seems to lock the element's screen position and it is a good thing but i don't know if it is applicable to every scenario. I expected REM unit to cause some shifts in positioning based on the root font size. Can someone explain the relationship between using REM for positioning and how it affects an element's screen location?
A shame it doesn’t work with light-dark, but you can create for primary eg
-primary-light: blue
-primary-dark: lightblue
-primary: light-dark(var(-primary-light), var(-primary-dark))
And now you can use both light and dark for like hover or whatever
-primary-hover-light: hsl(from var(-primary-light) h s calc(l * 0.5))
-primary-hover-dark: hsl(from var(-primary-dark) h s calc(l * 0.5))
-primary-hover: light-dark(var(-primary-hover-light), var(-primary-hover-dark))
If it could just work we could have this:
-primary: light-dark(blue, lightblue)
-primary-hover: hsl(from var(-primary) h s calc(l * 0.5))
But I’ve only played around with this for the past hour or so maybe I’ve missed something. If anyone could share some light to this would be cool
Isn't there a way like using: color-mix(in srgb, var(--clr-brand) 20%, transparent); ?
That works too, yup! But this does more, as I show in the rest of the video :)
@@KevinPowell Yup, I commented too early 😬. Anyways, Thanks for the video ❤️
i'll stay with my --color: X X% X%; and using hsl(var(--color)); or hsl(var(--color) / .X); for now, because the new approach has only a partial support
Hey Kevin, go look at the browser support link again? It's different than what you're showing in the video. They are all marked as partial support now...?
Hey guys! I am always wondering where do you guys test these new CSS features, because when I try to do so in my React apps I can never achieve this. Not sure if I need to update something or if CSS updates are automatically spreaded over the code bases.
Not sure where the win is over what I was doing before.
Literally, the CSS on my company page:
--root-hue: 165;
--base-hue: var(--root-hue);
--contrast-hue: calc(var(--base-hue) + 180);
--alternate-hue: calc(var(--base-hue) + 90);
--base-color-100: hsla( var(--base-hue), 100%, 1);
--base-color-90: hsla( var(--base-hue), 90%, 1);
...
--contrast-color-90: hsla( var(--contrast-hue), 90%, 1);
And the HTML looks like this:
Hello World
Click me
A simple change to --root-hue recolors the entire page in a consistent way, and it will always look good.
Cool video, thanks! Is the `h s 80% / 0.5` 80% *and* 0.5?
Right on the money!
Can you make the yellow button turn from black text to white text automatically if the contrast isn't high enough inside the hover state?
There is an upcoming feature in CSS to do this, color-contrast()
@@erickdavid4257 Oh goody! 😁
wow, now you can create shaders!
wheres the vid on nesting the css selectors?
i was watching your videos for a while and i never heard you talking about lch and oklch.....this is my first time hearing them can u please make a simple video about them
It's so pretty
Thanks Kevin, this is awesome, but I'm confused about 1 thing...why is it divide and not multiply? For example, if we take 200 and divide by 50%, that becomes 400, which is actually an increase in the values. Note - referring to the first part of the video.
It's not a division, it's just a visual separator between the color values and the opacity. If it was a division, it'd be inside a calc() or other math function.
@@KevinPowell Okay, that makes more sense, thank you very much for your response and wisdom. 🙂
Can I ask for a good book or video course on modern css please? All cool stuff in one place
I tried with box shadow like this: `box-shadow: 0 0 0 3px var(--field-input-focus-border-color);` and it didn't work :/
While these new color opportunities are kind of amazing, I find myself struggling using them effectively. 🫠
What I mean is:
I‘m doing CSS for almost two decades now. And Hex and RGB(A) is so embedded in my mind, that I don‘t think about hsl or other stuff when it actually would make sense.
At least, I‘m starting using color-mix(), though.
Kevin, if you‘d like, a beginners video about all color related options would be great. 😊
(As a non-English-native speaker, I can‘t even grasp what the basic idea of hsl really means (is it hue, saturation and lightning?) And how it‘s affecting my color. While with rgb, obviously it affects the main three colors. That is my problem really. 😢)
HSL is hue, saturation, lightness. Hue is the color of the rainbow. Lightness is how bright or dark the color is. And saturation is how much color the item contains.
To get a feel for this, you probably should mess around with a color picker. Look up HSL color picker on Google, and play around with sliders for HSL to see how the colors change.
a video explaining a little about the science behind the multiple color models in CSS would be great!
there is probably others on TH-cam covering this topic already
This actually is a game changer. Except I need functions to completely replace my SASS madness color variant generator
i'm not sure how hsl(from var(--color) h s l / .5) is more convenient, useful, or practical than rgb(var(--color) / .5)
I tried to make this work in SCSS but couldn't get it to. Has anyone figure that out?
Can we also calculate margins, paddings ..
Yeah, you can use calc() anywhere :)
This is very cool
Where's the postcss plugin?
Oh, I use it in TailwindCSS with --picked-color and deep/bright/neon/pastel versions of it with options to add/multiply lightness and chroma and rotate hue over oklch!
CSS is getting more amazing. It is sad that companies are going the tailwind route.
I really wonder from where to start on your channel???
Can anyone tell me if this works with Sass???
They keep adding more and more things to CSS. I think almost all of the added things are good but I do worry that we're heading towards a Franken-CSS monster with so much complexity that new web devs will be unable to learn enough for CSS to be a useful tool.
The nice thing is, all the new things are on top of what's already there. You can still learn the basics and make websites, and as you continue to learn, add the newer things. The hard part for new devs is being able to know where to go, or what to learn first, and that's on the people who are educating to make that part easy :)
And the fun part about covering CSS based on a working draft, a new feature was added to the working draft so now the CanIUse chart looks a lot worse despite the fact that the new feature is the only thing not covered in most browsers.
The new feature? You can use currentColor or a system-color as your origin color.
Haha, yeah, but at least nothing changed on what I showed in the video 😅
The functionality of this method is great, but my issue with it is the human legibility of it. It's very abstract. If someone comes into the project with no lesser knowledge, they are going to be wondering wtf is going on.
I think tailwind made them even easier :D
Css God)
6:37 wdym except for firefox? You can clearly see it is in firefox 128 - 130. I don't understand.
127 is the current release, so unless you're running the Beta/Developer/Nightly versions, it's not out yet.
That's why I said, but look at that, it's coming there too. 128 isn't in public release yet
@@erics2133 Oh that the thing. I should have checked first, my bad :)
@@KevinPowell Right, silly me :)
Love the functionality, but the syntax ... yikes!
css is turning into a programming language
*SO* weird syntax that one have to DIVIDE by 0.5 or 50% to get half the opacity 😳
It should be MULTIPLY instead.
Its not dividing, the / is just a visual to separate from the color values.
@@KevinPowell Could've been a pipe instead then :D
@@d.l.3807 now that would be weird
Why does it feel like CSS is becoming more like JS. 🤔
Because it needs to get emancipated from JS one day
Still seems cumbersome
Bye-bye hsl, welcome color-mix!
Finally
It's very verbose and complicated, Sass has better tools and even solves it better, but css is on the right way
Sass is not runtime though. The code ist produces is more verbose as well.
@@blazingelse9104 I don't think that's really true because CSS is clearly trying to adopt the ideas behind "preprocessors" (Sass) and why would you care about the code that Sass generates? It's just simply CSS that you have written, nothing more. Do you really look the code "bandel" that the frameworks generates?
Perhaps, if you know Sass well, you can generate advanced color palettes and other styles with many useful and much simpler functions that Sass has, and use lists, maps, loops and more programming functionalities to generate a complete themes, just as the most famous CSS frameworks do, for some reason they also use Sass.
It's just my opinion, I totally respect other ways of developing.
@@ToniTerremoto I didn't say Sass/Scss is bad or anything. I like it for mixins for example. I Just said it's less powerful and usually more verbose for features that CSS has adopted itself. You simply cannot generate shades of a color with sass if they color itself is set at runtime. With CSS you can. With sass, you cannot calculate with relative sizes. With CSS you can. Unfortunately, CSS functions like min or max now name clash with scss functions. Scss should just drop those functions in order to stay compatible and be more useful.
@@blazingelse9104 Thanks, I totally respect your opinion and your way of developing.
CSS does not have the Superpowers that Sass has, yet. For that example of the shadow in runtime that you propose, you would not have it done well only with Css (without Js) and Css clearly does not use logic to know if that shadow will be cast on a dark theme background or if it has good contrast, and that's why I think it's always a good idea to separate the "presentation" (CSS) from the "behavior" (JS, runtime), the same for the other cases that you propose, like relative measures.
It's just my way of developing, those things are not useful to me.
A cordial greeting. 🫂✌🏼