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. :)
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)
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!!!
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 =)
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...
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); } }
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 RU-vid algos gave me your channel) hope one day I'll bought your course and say you thanks this way for all your job
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.
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
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.
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.
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.
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
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.
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
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...?
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.
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.
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?
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.
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 :)
@@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. 🫂✌🏼
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 RU-vid covering this topic already