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" 🙂
For me usually mobile first does produce the least CSS, but I do agree that it doesn't make sense to go mobile first if that would mean overriding a bunch of styles when a better solution would be a max-width media query.
If I'm making a B2B site only for use by a client company's internal staff, I'd probably go desktop-first (I have worked on a few projects over the past few years which didn't even have mobile designs because that just wasn't a use case).
Maybe. If you want a polished UI and a professional look, or something artsy, that probably won’t work. If it’s some stuffy business app, especially an intranet one, sure, make it simple and focus on functional value over aesthetics.
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.
That’s a great way to think about it! I also think it’s good on utility classes because it forces users to actually remove the utility class from the element if they don’t want the style instead of just overwriting it.
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 !
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.
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-'
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?
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
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.
To an extent, i agree because most, if not all projects can be achieved via desktop but not all projects may work via mobile. But then again, in my opinion advantage of mobile-first > disadvantage of desktop-first. I think as Mr Powell mentioned, you can avoid it at times
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
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.
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
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
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.
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
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])`.
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.
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.
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 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.
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'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 )
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.
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."
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.
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.
No, one h1 per page. Most of the time, sections are h2 for me. If you read things about the document outline where sections or articles could also have h1, it was something that was added to the spec a very long time ago, and no browser ever implemented it, so they caution against it in the spec as well now
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 :)
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.
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
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.
Generally, I use IDs only for JS hooks. I know querySelector is a thing, but readability and not least performance wise, getElementByID is still easier to understand, it does only one single thing, it has been in JS like forever, and it's faster too. So, you can for example have a JS function hooked to a specific ID, where the content table goes, and then reading all the Hx then making the table placing the table into that ID. Article table of content I never use more than once on a page, so that is a good example. Another example is a JS generated calendar, usually used on blog pages, I never use that more than once either. Small JS tools doing just one single thing and hooking to an ID is very easy to understand, you add the ID in the HTML where the function should be used, and it works. Of course, when you go to more advanced frameworks, often the framework uses class, because the function can be used many times on a page, but the idea is the same.
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.
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!
Either way around, min- or max- wouldn't change anything in when it gets triggered though, but if you went min-width only, you're over-writing a lot more styles to "reset" things back to how they were
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. :)
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???
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 ^^'
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 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.
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.
Mobile first UI wise came out of the short sighted trend of making mobile apps first, before bothering with a website, because for a few years, mobile apps were still a novelty, had far less competition, and brainless VCs threw money at every mobile app idea. Before that people just made separate sites for mobile web. It wasn’t responsive functionality that drove mobile first on web, it was mobile first, period, as in mobile apps. Then because you had all this work done to make mobile app UIs, the idea was to use that to build out your site since you already had it. There was also this idea that it was somehow easier to show and add elements for larger screens than to hide and remove, which made no sense at the time and doesn’t to this day.
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?
Most of the problems I've seen with ID selectors are on larger teams where several people are working on a project, and the person who uses it is too focused on the small thing they are responsible for. Either causes issues with re-use, (like styling a tab component with an ID, when you might need several on the page), or with specificity, mostly because the project grows and they need modifier or different versions and the ID starts getting in the way. On smaller projects, other than silly mistakes, they're rarely an issue
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?
You can use a linter to do that. I personally hate it, and most people I know who write a lot of CSS do as well. The two main arguments I've heard are that it's easier to prevent duplicate properties declaring different things (but even VS code's default linting can catch that), and that if you are going to make a change, it's easier to find something that way, which I don't really get either. I like grouping relate things together, I want position absolute with my top, bottom, left, and right, for example.
Oh my god, that sounds AWFUL. why would anyone ever do that >_< put them logically next to things they are used with, which mostly happens naturally! Alphabetical would be a nightmare!
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.
Backend and front end are less and less separate these days. Firstly definitely learn CSS and HTML and JS fairly well and build things with them before moving on to frameworks.
I would recommend only HTML first (to understand how a web page is working), then add CSS to beautify things. Only these two first because they are the most visual and so the most fun for most beginner. Only after, learn JS. Learning JS after CSS would also prevent you from making beginner mistakes of doing anything interactive with JS where CSS should be used. If you want to add a backend you could probably go for Next or any JS to not have to learn a new language (this one still has React). I personally prefer Django but it's in Python
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'd use them with a fallback right now. The majority of iPhone users are still on versions that don't support it, and that's usually the most common use case.
Allows you to have minimum size, an ideal size (in something that can change, like viewport units), and a maximum size. Basically, you have a size that changes, like a percent or viewport unit, but that has a min and max size "clamping" it
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?
At this point, it is what it is 😅. I've worked at being more concise and I've improved, but a topic takes as long as it takes. I'm sure I could shave them down more, but it's how I like to present stuff, so most are in this range, with some occasional ones that are shorter and others that are longer 🙂
![[#2024MAMA] G-DRAGON - 무제(Untitled, 2014)+POWER+HOME SWEET HOME+뱅뱅뱅+FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/Ox29z5Nf1Uk/mqdefault.jpg)
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" 🙂
Yeah, I like to call it the "path of least resistance". The less CSS, usually the better :D
For me usually mobile first does produce the least CSS, but I do agree that it doesn't make sense to go mobile first if that would mean overriding a bunch of styles when a better solution would be a max-width media query.
If I'm making a B2B site only for use by a client company's internal staff, I'd probably go desktop-first (I have worked on a few projects over the past few years which didn't even have mobile designs because that just wasn't a use case).
Maybe. If you want a polished UI and a professional look, or something artsy, that probably won’t work. If it’s some stuffy business app, especially an intranet one, sure, make it simple and focus on functional value over aesthetics.
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.
That’s a great way to think about it! I also think it’s good on utility classes because it forces users to actually remove the utility class from the element if they don’t want the style instead of just overwriting it.
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 !
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.
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-'
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?
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
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.
To an extent, i agree because most, if not all projects can be achieved via desktop but not all projects may work via mobile.
But then again, in my opinion advantage of mobile-first > disadvantage of desktop-first.
I think as Mr Powell mentioned, you can avoid it at times
Maybe I'm feeling the mobile-first work flow because i haven't come across an issue with it🤔
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
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.
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
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?
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
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.
Many thanks for this Kevin and your newsletter. Much appreciated.
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
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])`.
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.
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.
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 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.
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'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 )
Mobile first ... I think for sure depends on the project or even the 'section' great video!
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.
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."
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.
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.
Thanks for these very helpful tips for me as a beginner
Regarding only one on a page- what if you have tags? Shouldn't the header of the section be an ?
No, one h1 per page. Most of the time, sections are h2 for me.
If you read things about the document outline where sections or articles could also have h1, it was something that was added to the spec a very long time ago, and no browser ever implemented it, so they caution against it in the spec as well now
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 :)
Wordpress themes and plugins :@
I feel you😂, overwriting wordpress styles is sadly most of the time impossible, without using !important
Yeah overwriting others' bad css and bad markup choices is mainly only time I ever need it
Yup. It gets funny when the framework already comes with !important styles on basic elements ...
@@thought-provoker uninstalled at that point. If they are doing that with css I shudder to think what's going on under the hood
I mostly work with various forums software so I’m an avid advocate of desktop first.
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.
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.
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.
Generally, I use IDs only for JS hooks. I know querySelector is a thing, but readability and not least performance wise, getElementByID is still easier to understand, it does only one single thing, it has been in JS like forever, and it's faster too.
So, you can for example have a JS function hooked to a specific ID, where the content table goes, and then reading all the Hx then making the table placing the table into that ID. Article table of content I never use more than once on a page, so that is a good example.
Another example is a JS generated calendar, usually used on blog pages, I never use that more than once either.
Small JS tools doing just one single thing and hooking to an ID is very easy to understand, you add the ID in the HTML where the function should be used, and it works.
Of course, when you go to more advanced frameworks, often the framework uses class, because the function can be used many times on a page, but the idea is the same.
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.
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!
Either way around, min- or max- wouldn't change anything in when it gets triggered though, but if you went min-width only, you're over-writing a lot more styles to "reset" things back to how they were
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. :)
Thanks Kevin. Very helpful!
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.
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???
Why do you assign classes to the Nav elements instead of selecting them by "header nav" and "footer nav"?
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 ^^'
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?
It would be, yup!
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.
Can you do tailwind.css trick for css professional as it is sometimes needed in project
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.
In the same manner, I don't quite grasp the use of ems in the media queries, as well. Would love to know more.
Mobile first UI wise came out of the short sighted trend of making mobile apps first, before bothering with a website, because for a few years, mobile apps were still a novelty, had far less competition, and brainless VCs threw money at every mobile app idea.
Before that people just made separate sites for mobile web. It wasn’t responsive functionality that drove mobile first on web, it was mobile first, period, as in mobile apps. Then because you had all this work done to make mobile app UIs, the idea was to use that to build out your site since you already had it.
There was also this idea that it was somehow easier to show and add elements for larger screens than to hide and remove, which made no sense at the time and doesn’t to this day.
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?
Most of the problems I've seen with ID selectors are on larger teams where several people are working on a project, and the person who uses it is too focused on the small thing they are responsible for. Either causes issues with re-use, (like styling a tab component with an ID, when you might need several on the page), or with specificity, mostly because the project grows and they need modifier or different versions and the ID starts getting in the way.
On smaller projects, other than silly mistakes, they're rarely an issue
@@KevinPowell Ok, got it
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?
You can use a linter to do that. I personally hate it, and most people I know who write a lot of CSS do as well.
The two main arguments I've heard are that it's easier to prevent duplicate properties declaring different things (but even VS code's default linting can catch that), and that if you are going to make a change, it's easier to find something that way, which I don't really get either. I like grouping relate things together, I want position absolute with my top, bottom, left, and right, for example.
Oh my god, that sounds AWFUL. why would anyone ever do that >_< put them logically next to things they are used with, which mostly happens naturally! Alphabetical would be a nightmare!
Please do video on popover and anchor
Waiting for better browser support before I make a video on them :)
When I find myself with no choice but to select an id, I usually use the attribute selector [id=“”]
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.
Depends what you like to do 🤷 - Try both out, see what you like better?
@@KevinPowellGOAT
Backend and front end are less and less separate these days.
Firstly definitely learn CSS and HTML and JS fairly well and build things with them before moving on to frameworks.
I would recommend only HTML first (to understand how a web page is working), then add CSS to beautify things. Only these two first because they are the most visual and so the most fun for most beginner.
Only after, learn JS. Learning JS after CSS would also prevent you from making beginner mistakes of doing anything interactive with JS where CSS should be used.
If you want to add a backend you could probably go for Next or any JS to not have to learn a new language (this one still has React). I personally prefer Django but it's in Python
What is this for a font-Family?
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.
Instead of .primary-navigation or .footer-nav, why not `header nav` and `footer nav` with just compound element selectors?
That would work as well :D
Hey Kevin, informative video as always!
Do you think it's ok if to go production with Dynamic viewport units right now?
I’ve been using dvh in production but if I do I just add a fallback using vh because support is still meh
I'd use them with a fallback right now. The majority of iPhone users are still on versions that don't support it, and that's usually the most common use case.
Never saw this clamp function. Can anyone explain to me what is used for?
Allows you to have minimum size, an ideal size (in something that can change, like viewport units), and a maximum size.
Basically, you have a size that changes, like a percent or viewport unit, but that has a min and max size "clamping" it
A very nice video, but oh my, this comment section is a pleasure to read!
The link for CSS Demystified isn't being displayed correctly on mobile
What's the problem? I just tested and it looked okay?
essentially.
Just use tailwind
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?
Attribute selectors have the same specificity as ordinary class selectors, so there must be something else that causes your issue.
I hardly ever use css classes. Perhaps vuejs components does not really need them
Here I would use header nav and footer nav
Best kevin Ever
Nice video.
why does Kevin remind me on my dentist more than my dentist
sir, is ur course at udemy??
No, I don't have any courses on Udemy
That's why I don't understand why people saying Mobile First😂
👏👍
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. 😂
Almost the first to comment😊
You have to cut your videos to 6-10min.. these are just way too long.
At this point, it is what it is 😅. I've worked at being more concise and I've improved, but a topic takes as long as it takes. I'm sure I could shave them down more, but it's how I like to present stuff, so most are in this range, with some occasional ones that are shorter and others that are longer 🙂
How much do you talk!!! Explain the main topic! All your videos are like this! You make people tired!