"Uh oh, looks like we've run into a specificity issue..." so mischieveous 😂 I cannot wait for the official release. CSS Layers are going to be a game changer!
I am really looking forward to cascade layers, as they make my CSS life so much easier! Thank you, Kevin, for explaining this new feature in detail! Also a big thank you to the implementers and the specification writers for pushing this feature forward in such a short time! Special thanks go to Miriam Suzanne here!
This is brilliant! Makes CSS specificity far less mysterious - when you find yourself searching through modules. Now nodules are essentially layered namespaces. Thank you for the clarity.
Great video again. not an easy subject to explain, but Kevin battles through and gives everyone a good understanding . thank you. its nice that the video isn't too long either
Something that's missing from this video is that you can set a layer to imported CSS files like "@import 'utilities.css' layer(utilities);". So you could import the CSS from a component library this way and have an easier time overriding some styles it defines.
Hey bro, I have a problem with this. I am using gulp to concatenate component css files into a main styles.css. In each css file, I have the css within layers, but when the files get concatenated, there are multiple components inside the @component layer for example. this causes the layer specificity to not work. Any idea how to get this to work with my use case?
You prefaced by saying it's around the corner, and listed the experimental dev browsers that supports it, but it's really important to drive home the point of how CSS Cascade Layers has a whooping 0.04% support right now in the web space. I think we'll be waiting a long time before this CSS feature becomes relevant, but it's still a lot of fun to experiment with and learn!
By being in the experimental browsers right now without a flag, it won't be long for it to make the jump to the production ones, and at that point support will hit 70% within a few weeks (of it being in all 3 of course). It'll take awhile before they're safe to use though, since you won't really be building in fallbacks.
Great video. I was thinking about this technique to override bootstraplike frameworks with importants though. If you have such framework, isn’t it always loaded first? I.e. you can define the layers order but at that point the framework is already loaded?
Your placeholder text is much more interesting and entertaining than Lorem Ipsum...did you use a gibberish random text generator, if so, where can I find it? Sorry for the off-topic question and thanks for the great tutorial.
If I understand this correctly, that means that for instance plugin creators for wordpress or similar can declare layers to their css, which then makes my job of overwriting their styling to integrate it better into my theme a lot easier? Because that has been an annoying battle for several occasions.
I'm happy about the reversed !important order, because it will allow people to overwrite styles at User (or even browser) level when needed. We, the designers/developers, always want to make stuff visually look good and be user friendly for "all" visitors. However some things may be bad for specific end users due to visual issues, and not being able to overwrite styling without breaking 90% of the time in a uniform way is an actual issue. So this new standard will actually be a welcome one. Accessibility will always be extremely important, but this will help as well.
!important is for when the user wants to overwrite something and can't figure out why it gets overridden by the creator. I use it all the time in reStyle when I want a page to have a dark theme that doesn't burn my eyes. But, it really should never be used in production code. If your website code has !important in it, you're doing something wrong. This layers thing sounds real useful. Hopefully, this and nesting become mainstream soon.
it would be nice if we could put a class-layer="isolatedLayer" on an element, and then that element and its children would ignore any author styles css rules not in a specified layer (and maybe even an inverse of that to ignore certain layers), so if you had bootstrap on the page and its screwing with something, instead of trying to counter it, you could have a div that completely ignores those bootstrap styles (i always have issues where a site designer has used tag name style definitions, and it screws up my apps styles, to be able to easily switch off some styles for an area would be a lifesaver. or maybe instead of/as well as on the element itself, having the css definition be able to do something like that.
The fact that un-layered classes always have greater priority makes this feature nearly unless with any legacy code of much size. Shame, wonderful feature if they reversed that so layered items always were first in priority over non-layered. Only solution for a legacy site is to come up with new class names and semi-by-pass the legacy code which it a ton of work, would have been lovely if layers sat on top of the priority stack :( -- oh what could have been so easy
I find that it's a great addition for people who are new to CSS, since it makes things more organized, and it makes it easy to deal with problems quickly. Though having said that, I still think that not using it is better if you have the time to write organized and structured CSS, since less lines of code would be needed, and layering could be done through splitting up your stylesheet into multiple ones. Thank you for the video, I found it very informative! ✌🏼
Nothing worse when trying to add/update a new framework/module and seeing breaking changes in layouts/font styles/etc. I've always used an id at the top level in my templates to override: my button #main { .section { .button { } } } Nice once all browsers adopt this cascade layer specificity can set the styling order.
Seems to me like there'd be a lot of issues here especially for library / framework developers. What would be more useful imo is proper namespacing & scoping.. yeah usable scoping (:scope).. and not just for CSS variables. At least we're getting nesting soon but I really am looking forward to the time when I can use is(), has(), where() without worrying about wrapping everything in @supports and pollyfilling. Parent selector is my dream CSS feature and potentially kinda possible with has() but we shall see.
has() will be a gamechanger for sure! And scoping is on the way as well, though that's going to be a bit longer still. I also think this will make libraries and frameworks easier to work with, rather than harder. Could be useful within site builders with custom CSS with WP themes as well. We'll only really know once it's out in the wild though!
@@KevinPowell Yeah I think if the scoping was there it would help, I just think there's going to be issues with ordering and redeclaration on the user side. Seeing as you mentioned WP, the naming could be solved with just prefixing everything with something very unique (like most do in WP themes / plugins). I suppose the more I think about it, the more it makes sense it just doesn't seem like an ideal solution to me but for sure it will be helpful for some specificity issues. Anyway, thanks for the video Kevin, I was unaware of layers and you covered them well 👍
@@fredhair Lucky for you, `@scope` is the primary feature planned for the next update to the Cascade. :) Here's the current draft: www.w3.org/TR/css-cascade-6/
@@MiriamCodes Yeah it's progress but it will be a long while before it's usable in production. That's still at first draft stage and was only published just over a month ago but at least it's moving in the right direction!
That went through my mind as well. Maybe create a wrapper that consists of nothing but a layer with an @import inside it? I can see where that could or couldn't work, so I'll have to test it. Using @import is/was discouraged, I'll have to test how this would affect the reasoning as well.
Kevin, I will be looking for a front-end designer very soon for our animation festival that will feature our selection online. Perhaps someone in your comments is proficient enough and reasonably priced.?!
I just wish there was a way to undo !important in CSS - for those times where you work on legacy code and old projects where a client has been puking !important tags all over everywhere they couldn't figure out how specificity actually works - or you know, just because... Because you dont really just wanna go in and remove them all as you could end up breaking something else, because its not like they wrote any tests or snapshots to tell you when something gets broken either - and some clients have systems that go back 2-3 decades and just simply have too much code to realistically be able to know all the places that would rely on that style rule...
Could you make an example of this issue using BEM methodology? Maybe this is not a problem with specificity but bad naming and using tag/class/id mash?
Awful example.Why do you use class .button for link? Why do you use tag selector? Do anybody write CSS like this? Do you realy need custom properties if you are using nesting selectors and mix it with id/class/attr selectors 🤨
So, because people can't grasp the cascade, they decided to add another layer to the onion? I find specificity as is to be elegant if done right, never really thought it to be difficult. I guess maybe it will help people....I just don't understand the need. Is it just a QOL kind of thing?
As was mentioned in the video - if you've ever had to 'work' with Bootstrap and had designs that differed from its defaults, you'll soon find that you need to write more and more overriding selectors because of how opinionated it is. This will allow you to isolate imported third-party styles without resorting to .class.class.class and other ugly specificity boosting.
Doesn't this have the potential to become a complete bloated mess if not carefully handled, especially if working on a large team? This seems like it would be very easy to abuse this power if in a hurry under a tight deadline (or just being lazy).
If there are a lot of !importants floating around in an old code base, I'd probably wouldn't look at updating it with layers cause yeah, it would be a bit of a nightmare.
I mean, all of this is great, but using SCSS with nesting (or anything else that offers similar features, like scoped classes, etc) is much better than using plain CSS. My question is, why would anyone bother with vanilla CSS in this day and age?
It's simple. Those tools can use layers under the hood. If they can use native features like layers instead of having to do complex processing, build steps get faster. Also, not everyone uses CSS tools. The ideal should always be focusing on getting vanilla CSS as usable as possible, so that we can one day use it directly instead of wrappers. CSS can also do things that stuff like sass cannot, like custom variables for instance. And now with Houdini, it's going to get a whole lot more powerful.
Well, nesting can cause problems, as I looked at in this video when my .button wouldn't work in the nav, because it had a descendant selector. So, in this case at least, nesting doesn't solve that. I do think this will play SUPER well with Sass, tbh.
@Kevin Powell but it's much easier to keep stuff organized so that this doesn't happen, you just make a button component, and off you go, no need for complex selectors. But I guess more features and options never hurt anybody :)
@Ritwik but with SCSS you can avoid this complex selector completely as you just make a button component instead of specifically selecting button in certain spots. But as I mentioned in previous comments, the more features the merrier :)
@@whynot9963 like I said, not everyone uses scss, and scss has to transpile to css under the hood. Kevin already mentioned a very real world use case for layers with the framework overrides. Pretty sure the number of people using scss is a miniscule minority compared to the people on frameworks like bootstrap.
"Uh oh, looks like we've run into a specificity issue..." so mischieveous 😂 I cannot wait for the official release. CSS Layers are going to be a game changer!
Nerdiest. T-Shirt. Ever
@@peternicholson26 If Kevin turned this into a shirt, I would totally buy it lol!
I would buy it just out of respect for the amount of times he said specificity without mispronunciation. Ridiculous
HAHA I laughed at that too lol!
I remember you struggling to say specificity, I think there is actually a dedicated video about it, glad you're saying it with ease is.
I am really looking forward to cascade layers, as they make my CSS life so much easier! Thank you, Kevin, for explaining this new feature in detail!
Also a big thank you to the implementers and the specification writers for pushing this feature forward in such a short time! Special thanks go to Miriam Suzanne here!
This is the “Great stuff” that Kevin is a godsend in sharing and explaining in a way we can follow.
this video was one year ago and i didnt even know this was existed
this will be a life changer
Letting the developers defining the layers is going to save their life in large projects. Feeling relieved.
This is brilliant! Makes CSS specificity far less mysterious - when you find yourself searching through modules. Now nodules are essentially layered namespaces. Thank you for the clarity.
Great video again. not an easy subject to explain, but Kevin battles through and gives everyone a good understanding . thank you. its nice that the video isn't too long either
Something that's missing from this video is that you can set a layer to imported CSS files like "@import 'utilities.css' layer(utilities);". So you could import the CSS from a component library this way and have an easier time overriding some styles it defines.
Hey bro, I have a problem with this. I am using gulp to concatenate component css files into a main styles.css. In each css file, I have the css within layers, but when the files get concatenated, there are multiple components inside the @component layer for example. this causes the layer specificity to not work. Any idea how to get this to work with my use case?
Lovely explanations! I understood better than when read from Tailwind, for instance.
thanks for the explanation and examples. Extremely handy!
This will save me Kevin, I'm working on an old project with such bad css practice. I will create my layer and voila! :D
the browser support is good for this feature so we can use it now :) great video!
Great video! Very exciting times ahead for CSS with layers and Houdini.
Thanks for the video. This thing is awesome. Real problem solver for large projects.
Very clear, as ussual. Thanks Kevin
Congrats on your specificity victory!
Great way to start the day.
You prefaced by saying it's around the corner, and listed the experimental dev browsers that supports it, but it's really important to drive home the point of how CSS Cascade Layers has a whooping 0.04% support right now in the web space. I think we'll be waiting a long time before this CSS feature becomes relevant, but it's still a lot of fun to experiment with and learn!
By being in the experimental browsers right now without a flag, it won't be long for it to make the jump to the production ones, and at that point support will hit 70% within a few weeks (of it being in all 3 of course). It'll take awhile before they're safe to use though, since you won't really be building in fallbacks.
Oh Kevin ! Thanks so much !!!! Can’t wait official release !
But i so this in tailwind yet. Can you think they used post css preset-env ?
Great video. I was thinking about this technique to override bootstraplike frameworks with importants though. If you have such framework, isn’t it always loaded first? I.e. you can define the layers order but at that point the framework is already loaded?
Love the tumbnail
Thanks Kevin it a gr8 video. I have a question this will works for all browsers? Chrome,safari,firefox and IE ?plz help on this
Right now, no, but all of them are actively working on it, so in the not too distant future it will work in all of them, yes
@@KevinPowell Er, well, it ain't never going to work in IE...
Excellent video. Thx a lot!
Your placeholder text is much more interesting and entertaining than Lorem Ipsum...did you use a gibberish random text generator, if so, where can I find it? Sorry for the off-topic question and thanks for the great tutorial.
This is HUGE!
Specificity: 31
Specificicity: 0
You've set a new record Kevin!
If I understand this correctly, that means that for instance plugin creators for wordpress or similar can declare layers to their css, which then makes my job of overwriting their styling to integrate it better into my theme a lot easier? Because that has been an annoying battle for several occasions.
Yes, exactly!
Very important video thx
I'm happy about the reversed !important order, because it will allow people to overwrite styles at User (or even browser) level when needed.
We, the designers/developers, always want to make stuff visually look good and be user friendly for "all" visitors. However some things may be bad for specific end users due to visual issues, and not being able to overwrite styling without breaking 90% of the time in a uniform way is an actual issue. So this new standard will actually be a welcome one.
Accessibility will always be extremely important, but this will help as well.
I need this t shirt! Where the hell did you get it!? Also, great stuff as usual!
This is amazing! By the way, do you have any ideas on making content have a border, but also have rounded corners?
I assume you cant just make a border radius with a border?
@@DTunezOfficial Yep. I used border and then border-image gradient, not sure if that disables the border-radius.
I think box-shadow could enable that.
@@hugoanderkivi thanks, though i alreay figured it out some time ago
Thanks!
Thank you so much!
Nice to see you’ve overcome your specificity issue. I mean the one getting tongue tied 😁
I totally made this comment before you even mentioned it loll
you can easily give a value of inherent to the a, to avoid that specificity issue
!important is for when the user wants to overwrite something and can't figure out why it gets overridden by the creator. I use it all the time in reStyle when I want a page to have a dark theme that doesn't burn my eyes. But, it really should never be used in production code. If your website code has !important in it, you're doing something wrong.
This layers thing sounds real useful. Hopefully, this and nesting become mainstream soon.
Or you’re caught by corporate bloat and it’s the only way to override shitty corporate “frameworks”
This is confusing, but.. still interesting!
Thank's Maestro
What lorem are you using?
Kevin, what do you think of Metaverse buzz? Is HTML/CSS going to be history in 10 years?
Tolkien ipsum, very cool.
Edit: It appears to be called LOTRem ipsum, if anyone else is interested ;)
Great video. Better shirt
it would be nice if we could put a class-layer="isolatedLayer" on an element, and then that element and its children would ignore any author styles css rules not in a specified layer (and maybe even an inverse of that to ignore certain layers), so if you had bootstrap on the page and its screwing with something, instead of trying to counter it, you could have a div that completely ignores those bootstrap styles (i always have issues where a site designer has used tag name style definitions, and it screws up my apps styles, to be able to easily switch off some styles for an area would be a lifesaver.
or maybe instead of/as well as on the element itself, having the css definition be able to do something like that.
The fact that un-layered classes always have greater priority makes this feature nearly unless with any legacy code of much size. Shame, wonderful feature if they reversed that so layered items always were first in priority over non-layered. Only solution for a legacy site is to come up with new class names and semi-by-pass the legacy code which it a ton of work, would have been lovely if layers sat on top of the priority stack :( -- oh what could have been so easy
Gamechanger 😍
I find that it's a great addition for people who are new to CSS, since it makes things more organized, and it makes it easy to deal with problems quickly. Though having said that, I still think that not using it is better if you have the time to write organized and structured CSS, since less lines of code would be needed, and layering could be done through splitting up your stylesheet into multiple ones.
Thank you for the video, I found it very informative! ✌🏼
Nothing worse when trying to add/update a new framework/module and seeing breaking changes in layouts/font styles/etc.
I've always used an id at the top level in my templates to override:
my button
#main {
.section {
.button {
}
}
}
Nice once all browsers adopt this cascade layer specificity can set the styling order.
After third SPECIFICITY word i was like Who are you and where is real Kevin😮 And then you told about the word🤣
Seems to me like there'd be a lot of issues here especially for library / framework developers. What would be more useful imo is proper namespacing & scoping.. yeah usable scoping (:scope).. and not just for CSS variables. At least we're getting nesting soon but I really am looking forward to the time when I can use is(), has(), where() without worrying about wrapping everything in @supports and pollyfilling. Parent selector is my dream CSS feature and potentially kinda possible with has() but we shall see.
has() will be a gamechanger for sure!
And scoping is on the way as well, though that's going to be a bit longer still.
I also think this will make libraries and frameworks easier to work with, rather than harder. Could be useful within site builders with custom CSS with WP themes as well.
We'll only really know once it's out in the wild though!
@@KevinPowell Yeah I think if the scoping was there it would help, I just think there's going to be issues with ordering and redeclaration on the user side. Seeing as you mentioned WP, the naming could be solved with just prefixing everything with something very unique (like most do in WP themes / plugins).
I suppose the more I think about it, the more it makes sense it just doesn't seem like an ideal solution to me but for sure it will be helpful for some specificity issues.
Anyway, thanks for the video Kevin, I was unaware of layers and you covered them well 👍
@@fredhair Lucky for you, `@scope` is the primary feature planned for the next update to the Cascade. :) Here's the current draft: www.w3.org/TR/css-cascade-6/
@@MiriamCodes Yeah it's progress but it will be a long while before it's usable in production. That's still at first draft stage and was only published just over a month ago but at least it's moving in the right direction!
Is there, or will there be a way to import an external css like this: ?
That went through my mind as well. Maybe create a wrapper that consists of nothing but a layer with an @import inside it? I can see where that could or couldn't work, so I'll have to test it. Using @import is/was discouraged, I'll have to test how this would affect the reasoning as well.
is there a way to check if said framework is using layers? and if not, a way to wrap it?
so lit t-shirt, man!)))
This sounds like a pain and a blessing at the same time.
Kevin, I will be looking for a front-end designer very soon for our animation festival that will feature our selection online.
Perhaps someone in your comments is proficient enough and reasonably priced.?!
Great!
I just wish there was a way to undo !important in CSS - for those times where you work on legacy code and old projects where a client has been puking !important tags all over everywhere they couldn't figure out how specificity actually works - or you know, just because... Because you dont really just wanna go in and remove them all as you could end up breaking something else, because its not like they wrote any tests or snapshots to tell you when something gets broken either - and some clients have systems that go back 2-3 decades and just simply have too much code to realistically be able to know all the places that would rely on that style rule...
interesting feature
Is this similar to SASS nesting where we use a parent-element class selector (e.g. .navbar) and then style all children elements in it?
With this make it easier to manage dark and light themes?
Is there ever a valid reason to use !important? It always seems to be used as a hack because the dev didn't want to do it the right way.
Could you make an example of this issue using BEM methodology? Maybe this is not a problem with specificity but bad naming and using tag/class/id mash?
Awful example.Why do you use class .button for link? Why do you use tag selector? Do anybody write CSS like this? Do you realy need custom properties if you are using nesting selectors and mix it with id/class/attr selectors 🤨
For a second I was afraid that Mozille would introduce (document) layers again... It's the stuff nightmares are made off!
Can we name layers however we want or are there already existing names for them: reset, base, components, etc?
We can name them however we want, and create as many as we want :)
So, because people can't grasp the cascade, they decided to add another layer to the onion? I find specificity as is to be elegant if done right, never really thought it to be difficult. I guess maybe it will help people....I just don't understand the need. Is it just a QOL kind of thing?
As was mentioned in the video - if you've ever had to 'work' with Bootstrap and had designs that differed from its defaults, you'll soon find that you need to write more and more overriding selectors because of how opinionated it is. This will allow you to isolate imported third-party styles without resorting to .class.class.class and other ugly specificity boosting.
16:29 There's 292 !important in the latest Bootstrap version :(
The reason unlayered rules have higher specificity is because they get put inside an anonymous layer that is below all other layers
I think this technique will either make thing simplier, or mess up the CSS LOL
and btw !important is still evil..damn boostrap
In Chrome, the User Agent throws an !important on a input’s writing-mode.
Doesn't this have the potential to become a complete bloated mess if not carefully handled, especially if working on a large team? This seems like it would be very easy to abuse this power if in a hurry under a tight deadline (or just being lazy).
I try to go for the everything-is-a-class thing and get super annoyed when the fix for my problems is to copy-paste to a different place. Argh!
I didn't like that selectors outside a layer have higher specificity, it should be the opposite
is there a way to set a level of importance? such !important Lvl 9
Me after watching this 👀😳🤩😍❤️
cool
Old code with tons of important (that aren't important at all). Think this is just going to make it harder to maintain.
If there are a lot of !importants floating around in an old code base, I'd probably wouldn't look at updating it with layers cause yeah, it would be a bit of a nightmare.
I kind of wish the important would vanish from modern browsers, but this would most likely break most corporate code looks.
What about .nav-list a:not(.button)?
Is it possible to '@import' css within a layer?
I tried and it didn't work in Chrome Canary, but I think it's supposed to, so I'm not sure where it'll end up.
html * {
font-size: 16px;
line-height: 1.6;
}
I mean, all of this is great, but using SCSS with nesting (or anything else that offers similar features, like scoped classes, etc) is much better than using plain CSS. My question is, why would anyone bother with vanilla CSS in this day and age?
It's simple. Those tools can use layers under the hood. If they can use native features like layers instead of having to do complex processing, build steps get faster.
Also, not everyone uses CSS tools. The ideal should always be focusing on getting vanilla CSS as usable as possible, so that we can one day use it directly instead of wrappers.
CSS can also do things that stuff like sass cannot, like custom variables for instance. And now with Houdini, it's going to get a whole lot more powerful.
Well, nesting can cause problems, as I looked at in this video when my .button wouldn't work in the nav, because it had a descendant selector. So, in this case at least, nesting doesn't solve that. I do think this will play SUPER well with Sass, tbh.
@Kevin Powell but it's much easier to keep stuff organized so that this doesn't happen, you just make a button component, and off you go, no need for complex selectors. But I guess more features and options never hurt anybody :)
@Ritwik but with SCSS you can avoid this complex selector completely as you just make a button component instead of specifically selecting button in certain spots. But as I mentioned in previous comments, the more features the merrier :)
@@whynot9963 like I said, not everyone uses scss, and scss has to transpile to css under the hood.
Kevin already mentioned a very real world use case for layers with the framework overrides.
Pretty sure the number of people using scss is a miniscule minority compared to the people on frameworks like bootstrap.
@layer === position : z - index :)))))))
Kevin thanks 🎓
If the js can access @layer then it will be totally gane changer i think 🙄
Wait. Does this mean i can finally throw away all those god awful CSS-in-JS libs?!
Say "specificity" 10 times fast!
First yo get here
To me it looks like a and !important block lol
No more !important; ? :/
CSS specificity is one of the easiest things on Earth.