These CSS best practices might be holding you back 

I wonder if instead of going "mobile first", the best approach would rather be: "least need for style-overwriting", which is actually equal to "accomplish as much as possible with as little CSS as necessary" 🙂

Our frontend and backend (java) developers have an agreement: Front-end stays away from IDs (they are used for backend operations like refreshing and often generated) and back-end doesn't alter any style-classes. Sometimes backend has to use a styleclass but that is always prefixed by 'js-'

I definitely think "mobile-first" held me back a lot. The projects I wanted to work on were things like a chess site, a sudoku site, general mini-games etc. These are things that are best on desktop, but I got so bogged down in mobile first and forward planning for responsiveness that I never even got it working.

The general advice I give for !important is to use it defensively, rather than offensively. Defensively is like the example you gave with the utility class, where you want to be sure a style will be applied no matter what. Offensively means that you are overwriting an existing selector that is more specific. !important is a shield to protect your own, not a sword to conquer others.

I fell in love with this channel when I was searching for answers on the subject specificity. I subscribed and still getting myself schooled about CSS. Thank you.

Many thanks for this Kevin and your newsletter. Much appreciated.

It took me a while to understand why people were complaining about specificity. I think being a print designer shielded me against it to some extent. When you design you think in terms of style guide / graphic charter / design system, so you come up with rules: "X should look like this, but in this context it should look like that". When you are in a situation where specificity becomes a problem, it's possible that you were simply mistaken about the rules of your design. Instead of placing an `!important` or blaming CSS specificity and make the vow to only use classes, maybe you can simply reflect your newly acquired knowledge about the design in your CSS and style guide

Kevin, thanks for addressing this. Here's something I've been asking myself for a while: When developing web components, it's certain that there will only be, for example, a single within the component: If it were different, I might have issues with the entire concept of OOD. Hence, I just style that thing inside the component's shadow directly, without a class selector. It seems that defining classes for something unique in an isolated context is overkill - and might even mask OOD problems? What's your suggestion there?

Thanks Kevin. Very helpful!

I just used a lot of id selectors for a full-stack MERN project where the react-bootrap classes were the same on every page I used them. I could have added my own class as well, but I just decided to add an id for the specific items I needed to style. I rarely do that, but for that case it seemed like the best approach.

so true. sometimes there is just a need for important on legacy classes or external widgets you need to implement that otherwise won't budge... :) loved the video. thank you

Thanks for these very helpful tips for me as a beginner

I think the mobile first or desktop first approach really depends on the project. Sometimes I think it's easier to remove things or complexity rather than adding it, as it needs much more prep work and thinking upfront. There is no right or wrong in my opinion, naturally what is easier results in the right way. What you mentioned, Kevin, about default styling across all screen sizes is very important and can help massively. I like being very specific with my links, paragraphs, headlines and so on. Great video as always. Thanks for that.

the EM vs REM situation actually came up in a major visual regression bug at my job. for some reason, on some pages, the font sizing was absolutely tiny in production despite local testing. i came to discover that additional CSS rules we were being loaded, changing the base font-size, and there was no way to unbundle these rules without a major refactor. a simple switch to EMs for some components reused on those pages solved the issue in maybe 2 or 3 lines of code. flexibility is the key!!

i think using css framework like tailwindcss solve most of these problems out of the box ...and make development alot easier

You touched on something critical when you mentioned "if you're working with a big team." Best practices are always context dependent: what is best for a custom crafted museum site is completely different than a multi-vendor sales site, and if you're working on a framework for a CMS that clients can add custom CSS to, there's a whole different set of demands. Add in apps that use CSS and allow third party plugins (either online or local, like Obsidian), and there are a ton of edge cases that have even more extreme needs. There is nothing universal except the most basic things: clarity, formatting, consistency, communication (aka comments and/or documentation)... and sometimes when you're prototyping a quick throwaway demo to visually present a concept in two hours, even those can get jettisoned for practical demands.

For specificity, sveltejs as a frontend engine, which is great for component scope. I can target a div or section in a particular component and it'll not be applied to any of those in the different component, although they may all live in the same page. For my site-wide global css, I tend to use picocss which mostly targets elements

I like those videos from you, Kevin. Because they explain in a very simple way, why one should always use the most simple and clean way to create what you need, so I can share them with co-workers. 😊 Which adds another point to all of this. Using simple and clean CSS (as well as JS and other stuff) makes it much, much less frustrating for another person, if they ever need to change or fix things later on. In my opinion, a template is never really finished, there's just a launch date. If one has to change things in a template from a co-worker, they can become quite frustrated if the CSS file is messy. I have seen things and I'm sure everybody's freaking out by trying to fix some other persons code being like: id id class class class class div.class[data-has-anchor="stuff"] a > span:first-child

I've been using cascade layers in production for a while now. It has changed the way I write CSS quite a lot simply because it makes it so easy to control how all the styles cascade. Now I go crazy with both descendant selectors and ID’s. I reckon it will get even more crazy with nesting and the upcoming @scope rule.

Hey ! The subtitles are not available on that video. Possible for you to turn them on ? My english is not very fluent. And I don't want to miss one of your awesome video. Thank you so much for all your work !

Mobile first never made sense to me, because at least on the projects I worked on, desktop versions are a lot more complicated. So I make a mobile layout that works flawlessly, start making a desktop layout and surprise this section's layout is 2D and I cannot just use grid because of nesting and sub grids are not a thing yet so I have to redo my html and mobile breaks. There a fewer surprises when you are doing things in reverse, there are hiccups, but you can usually make things work without modifying html at all. And if you are working with clients or designers (meaning clients by proxy), they usually want to see the desktop version first (if they even remember mobile exists) So, in conclusion, waiting for mobile when desktop version is approved not only makes the project take longer, but in the end I'll have to make 3 passes with css instead of 2 I would of course be glad to be proven wrong on this, since that would make my workflow easier

You uttered the unspeakable words that send shivers down my spine: page builders. I remember a time I had to inject inline styles with important through js because one of those page builders was extremely liberal with its use of important. Worst css experience of my life honestly

HI Kevin I think it would be a good idea to make a video about how you name your custom properties. For instance, where that "- - clr - primary - 700" come from? Sometimes you use (Primary, Secondary and Accent) but other times you use (Primary and Neutral). So, I think it's worth letting us know how you figure it out.

I’ve always have a difficult time explaining to coworkers why I use max width media queries. Sometimes I’d encounter a problem and it was just obvious that min-width was the wrong tool and so I max-widthed and thought nothing of it. But then I’d fail peer review because some other dev says “at our company we work mobile-first”, and I’m suddenly conflicted because yes, mobile first is a good thing, but I know min-width is a worse choice in this case. So I concluded that mobile-first as a development methodology is stupid and that it’s maybe only useful to give designers a consistent strategy for designing responsive pages. Developers should, as you said, follow the path of least resistance and shouldn’t feel as though any tool in CSS is wrong to use, so long as it does the job well and your code is easy to understand.

Great video to spark the comments. It is great to read all the comments to see the opinions and know what I can implement. It feels like a mix of very talented CSS people that everyone can learn from.

Two things come to mind while watching this video. I sometimes use the same class to boost its specificity : " .clr-purple.clr-purple".. and also the fakt that you can override an important with a id-Selector. "#content .classname" -> overrides ".classname"-Selector if both use important, even if ".classname" came first.

Mobile first ... I think for sure depends on the project or even the 'section' great video!

I tend to reach for !important when I'm overriding some CMS-related stuff, like some WP plugin styling or hiding a hardcoded theme element, etc. It's almost always a choice between a quick botch vs. diving into PHP for half an hour :)

As long as you're working alone with your very own project you can do pretty much whatever you want. When you work as a team member where (for example) one person is responsible for html, another for css and third one for javascript it's good to have common rules for using id:s, classes and data-attributes. One solution is to dedicate id:s for html, classes for css and data-attributes for javascript.

honestly i nest all the time while using scss haven't run into issues with it either but i know i could, that being said i recently switched to tailwind with react for my own projects don't want do think of class names all the time :D Regarding the media query while i think it can make sense to go for desktop first it seems odd to mix and match it since you would have to adjust your thinking depending on what you're working on. But i haven't worked on any real project or large on either

Hey Kevin. Can you make more video of best practices.

Is there a way to style an element that has position: sticky BUT only apply those styles once it’s anchored and scrolling down the page with the user?

Is it recommended to use :nth-of-type when selecting one of the two/three nav's for example? Just to avoid using classes or id's. Provided that there are no more than three of course. Or perhaps it also helps when accessing the DOM???

Can you do tailwind.css trick for css professional as it is sometimes needed in project

How do you get backdrop-filter to work smoothly?? I've never once been able to figure out how to use it without janky scrolling.

I've recently found !important useful in combination with custom properties for ensuring consistent styles when working against highly specific styles added by third parties. E.g. woocommerce has lots of very specific styles for various buttons. I want all buttons to look the same so... .button { color: var(--btn-clr) !important; background-color: var(--btn-bg) !important; } I have full control of the button colors, and I'm able to adjust them without more !importants. ( I'm pretty sure you can pick the woo button colors in customiser, but the method still has its uses )

Please do video on popover and anchor

Kevin, if I may ask how did you come up with the numbers you used for clamp there? or maybe a better question is, how did you first learn how to use calculations for font/color-styling? cause even though I think I'm quite comfy with css since I started coding 1.5 years ago, I still have no idea how to implement those kind of calculations for styling purposes.

Hey Kevin, informative video as always! Do you think it's ok if to go production with Dynamic viewport units right now?

Nice video.

What is this for a font-Family?

I mostly work with various forums software so I’m an avid advocate of desktop first.

Why do you assign classes to the Nav elements instead of selecting them by "header nav" and "footer nav"?

About the mobile-first approach - I tend not to think about it as "adding complexity" (although it frequently is), but as more of a "what layout works for the most devices". I agree that a hamburger menu is definitely more complex than a simple navigation menu, but what if, due to a weird aspect ratio/pixel count on a few mobile devices, your media query doesn't trigger? Now your mobile users are stuck using a desktop menu that doesn't work for them - whereas if the same thing happens with min-width, so a tablet gets misidentifed as a phone, or a laptop as a tablet, sure, the layout might be less intuitive for the device type, but it still works. Is that not better? Just a thought!

For me, mobile-first is not a thing. I actually do my styling based on the projects. It could be the other way around: a bigger screen first, then a laptop and then a mobile phone. I did a project where I had more elements to add on desktop designs. What do you think? Another issue I had recently on a project was, not being able to overwrite a reset I did in my boilerplate.scss. I did the reset with an element selector with an element selector which has a specificity of 001. I tried to overwrite the reset using an element selector and a class which has a specificity of 011 and it didn't work.

Wouldn't it be possible to just addressing nav by using "header nav" and "footer nav" as you are already using the semantic mark-up and therefore not having to use class="xx?

I personally still used Id's, but I would say it's more out of habit from what was drilled into me in school than anything else. Single occurrence of a specific element on a page = gets an Id. Multiple occurrences of an element on a page = gets a class. I will say the place that practice tended to run aground later in my coding work was styling dynamically generated content. Like for example a displayed list of article posts. It had to go from "Well there's only *one* title to this article so it gets an Id!" to "This block of code is going to be used several times, even though it's here once in my template."

A mistake I see often is people tend to forget that classes are composable-you can use multiple classes for a single element and scope them. If you keep them small enough you avoid the cascading issues that you didn't intend. I often use classes as a way to define variants of a given base class for reusable components. Say for a button, I could have a base class `.Button` and define variants to changing its appearance based on preference and state; e.g. For size I'd have a `.Button.size-5` that sets properties that changes it size (paddings, font-size, dimensions), A `.Button.purple` that changes its background, foreground and any SVG fills to a specific color scheme (as well for its states) and `.Button.state-loading` for custom states that overrides the previous ones. This also works really well with :where selectors, for selecting, say dark mode class from its nearest ancestor, as well as for states, like `:where(:hover,[data-state=open])`.

Another best practice I’ve heard of awhile ago, though haven’t used for awhile, is putting the styles under each selector in alphabetical order. Unless there’s a vscode extension for this, it seems like it could waste time. Or is this actually a good best practice? If so, is there a vscode extension for this?

I would just avoid using em and rem in media-queries. According to MDN, it will always be calculated from 16px, regardless of the font size. However, it can be extremely confusing for a beginner because they expect it to change based on the font size.

I usually tweak prebuilt themes for clients, and I often facepalm over how much of the code is patching problems created by the approach in the first place. I've preferred using element selectors for setting root defaults (for mobile *and* desktop), then cascading from there as pertinent since I started nigh 2 decades ago. Sounds like we take the same approach, just describe it differently. :)

Class selectors for everything is a bad idea for me, I prefer your approach where you do some kind of hybrid between class selectors and descendant selectors. That's how I'm working too and I feel this is better because sometimes I don't have to think about how to name everything and loose time just for that. Instead I can just add a class on a container like nav, ul or div and then use element selectors to achieve my goal. For ID selectors, I think this is a good practice to not use it everywhere. This is because when you see and id selector in a stylesheet you can understand that this has been used maybe to create a link using the "#" or maybe this is used to create some interactivity with the :active pseudo class. I mean, if someone use the id selector only once or twice in a stylesheet, you can guess that this is for another reason than just rising specificity so this can sometimes help to understand how a system in the site is working. I never use "em" unit because I feel a little bit uncomfortable with it but this seems to be very useful in some case like you said. Your advices about "mobile first" are great ! I've made a little project today where the mobile version was very simple et the desktop version was very complicated and I've the desktop version first ... WHAT A BAD IDEA ! 3 media querries, a lot of "!important" and a lot of problems with specificity in general ... Starting by the simpliest version and then adding more complexity is a very good advice so thanks for that. The !important is a nightmare for me. I'm working with Wordpress and the other developpers have used "!important" everywhere and now it's a real nightmare ! I should refactor the code but I can't do it alone so I have to throw "!important" everywhere too :/ So yeah, don't use "!important", please ! x) Thanks for this video ! It was very interesting :D Unfortunately I don't have any other best practice to share ^^'

Mobile first as popularised by the famous book on responsive design, doesn't prescribe code organisation or style. The author was only saying think about the mobile version before thinking about the desktop version.

Best kevin Ever

Hey Powell, am a newbie in programming and web development, please what path would u advise me to follow (backend or frontend). Any suggestions will be highly appreciated.

Why is raising the specificity of a nav with an id a problem? What exactly are you doing with the styling and at what point will you change something that won't take effect because of the specificity?

Never saw this clamp function. Can anyone explain to me what is used for?

It's useful to think of !important as an "escape hatch". It's there in case you really need it, but it's a last resort, not a general-purpose tool; you should only resort to using !important when you don't have another reasonable choice.

The link for CSS Demystified isn't being displayed correctly on mobile

A very nice video, but oh my, this comment section is a pleasure to read!

When I find myself with no choice but to select an id, I usually use the attribute selector [id=“”]

Instead of .primary-navigation or .footer-nav, why not `header nav` and `footer nav` with just compound element selectors?

Mobile first in my opinion doesn't make sense if you're going for a website that's going to be primarily viewed on desktop An admin site or a website that's super artistic.

I dislike that [data-attribute] selectors in CSS seem to have a higher specificity than just class-names. It renders them kinda useless as soft-selectors... Is there a way around this?

sir, is ur course at udemy??

why does Kevin remind me on my dentist more than my dentist

👏👍

essentially. Just use tailwind

I hardly ever use css classes. Perhaps vuejs components does not really need them Here I would use header nav and footer nav

That's why I don't understand why people saying Mobile First😂

Almost the first to comment😊

I’m strongly against mobile first practice it just doesn’t make sense and web is much easier to develop first and then modify for mobile

why no translate

!important is important to get the job done. 😂

How much do you talk!!! Explain the main topic! All your videos are like this! You make people tired!

You have to cut your videos to 6-10min.. these are just way too long.