The problem with mobile-first CSS 

For those of us old enough to remember, mobile-first was borne out of a lack of browser support for media queries. It was really an extension of progressive enhancement/graceful degredation. Now that media queries are well supported and we have lots of other options, there is really no reason to use mobile-first over any other strategy.

If you do have issues going either way, don't forget that you can use `initial` and `unset` for properties to deal with them while not needing to state something explicitly

I think we should break our design into logical components and decide for each component separately whether to use the mobile-first approach or desktop-first.

To me as a web application developer for business applications, desktop has always been the more easy side of the responsiveness spectrum. Menus, forms, (search) tables, tabs, .. they're all easy to give a place on a larger screen. The complexity starts when we have to make it work on mobile. So from that perspective desktop first is so much more appealing. Additionally, most of our clients don't even want to pay extra for their web application to be accessible on mobile. Mobile first sounds great and all, until you meet reality 😅

Mobile-first design was a game-changer for me. Once you've designed for smaller screens then you've already done the hardest part...it's so much easier to scale up to larger screens than it is to scale down to smaller ones.

Mobile First is one of those mantra's that were much more important 10-15 years ago. Designing and Developing mobile first did largely just make everything stack, but it also forced decisions on priority leading to better structured HTML, and in turn making a more accessible document. I will still advocate heavily for pages to be designed mobile first to force hierarchy conversations earlier before larger screens are defined. But I believe you are right when it comes to putting it into code, it really is more about from broad to specific. This just tends to align with mobile first most times. Navigation and tables are two excellent examples of where Desktop first definitions may be the best route as its likely to also align more closely with the ideal markup.

Sometime I prefer to not only use mobile or desktop first, but wrap everything inside its own media query, a menu is a huge example, a lot of the code you write for the mobile version was not reusable in the desktop one, so these styles needs to be inside a media query to avoid redeclaring styles to the default value. This is my rule: if a style is only needed in a specific device, it will always be inside this specific media query; but today you are having the opportunity to even avoid the use of media queries, this is really awesome

This is exactly the way I approach responsive styling. Try without media queries first, then style from common/shared to specific/complex. When you try to avoid media queries first, you'll also get a good sense of resilient design, i. e. make it work with unpredictable content and in unpredictable viewport sizes by default. We always design for the unknown. And: Code should be easy to extend/change, and the first simple, then complex approach, avoiding overwriting previously applied styles, also helps a lot with that.

I build desktop first and simplify down for the same reason that the complex stuff that needs figuring out is on desktop and mobile is just usually stacking

The fact that we can approach the same objective with a different approach from others, and still get everything to work as it should, is both good for everyone and complex for those learning how to code. It is definitely beneficial to understand the many considerations to make and the need to keep your mind open to your approach so you don't get locked into one approach when you can make your job easier with a smarter method.

Omgosh I'm so glad you are brave enough to make a video on this!! I think the SAME thing every time I make a new layout!! My brain says: 'do the mobile first; but reality says but you really need to think about desktop before" , so I compromise with myself and do desktop first with always keeping how it will affect the mobile at the same time. Like others say though I'm not working for an agency so thankfully I have that freedom. It is AWESOME to HEAR it said by Kevin out loud though! Kudos!!

Resize Observer + Vue have been a game changer for me in business applications. I used to fill my web app with mobile and desktop HTML / CSS / JavaScript and then adjust with media queries. Now I can develop mobile / desktop components that only load depending on the current viewport size, and will automatically load and swap themselves out as the viewport changes. Components contain their own HTML, CSS and JS so I'm only fetching what's needed.

Something I always appreciate is the questioning of the “status quo”. I like how you point out there can be use cases when we can just simply lean into using the browser and making our code not as overly complex. Sometimes mobile first is easier but also sometimes it’s not. Great video !

Mobile first is the obvious choice. It's easier to add stuff if you move your things to a big box than to compress and remove stuff if you move your things to a smaller box. And it's the standard... so bootstrap and tailwind are kind of made with that approach in mind.. it's harder to go against the flow Also, on the large majority of cases, most people use the web trough a phone. And finally, it's easier to neglect mobile as we are coding in desktops... So making sure you start doing what you have a higher chance of not doing later is a good idea

Learning so many gems since subbing to your channel. I’d love a video on general best practises and industry standards, especially for working in teams. As a newer developer who’s only done freelance, I’m sure I’ve got some bad habits and there’s probably things experienced devs take for granted that new developers don’t even know

I agree with you. I think I automatically gravitate towards an additive-first approach. Sometimes it is a desktop first and sometimes it is mobile first.

Was looking for this since morning...and you posted it 😁🔥

Makes me feel relieved, since I generally use a "default first" approach when styling. Nice video.

It's kinda funny to see you try to put up with mobile-last adventure there in the start. xD

It took a lot of time for me to get used to the mobile first workflow. It's the same problem, I hated to unset a lot of properties for desktop, and hated building layouts for mobile. But using Tailwind and SASS made it a lot easier. Now I just set all the media queries inside the class. It still feels a little weird, but it's a lot easier to manage.

I always start with the larger screen and then work my way down to the mobile view. This approach makes it easier for me to develop any website.

The first time I heard and learnt "Mobile First" was actually here with Kevin lool

I layout HTML after desktop design then start mobile first CSS. Makes it easy to scale.

I love the broader message, I think of it like the computer has feelings too. I love to exhaus all the cheap approaches I can think of, first. And this simple code can give a pretty good looking result! I went a little extreme and let my menu items look like vanilla links, blue and underlined, and then by tweaking the style of all the links it actually turned out pretty good! I'm keeping it. For now.

This video got the wheels turning. I’ve always leaned towards the ‘Mobile First’ approach, but sometimes it feels like a tug of war with styles, especially when mobile layouts are more complex. It led me to think about a ‘Simplicity First’ approach. Start with the least complex layout, no matter if it’s for mobile or desktop, and then venture into the more complex territories as we go. It’s like easing into the deep end, keeping the code tidy and our minds uncluttered. The ‘Simplicity First’ approach isn’t about ditching ‘Mobile First’, but more about embracing a flow from simplicity to complexity. It feels like a friendly handshake between mobile and desktop design, each learning from the other. Just a fresh perspective that’s been brewing post-video!

Thank you for making this video... this has always been my approach and it's great to see some people admitting it has it's benefits. Mobile first forces you to write a property twice and from my experience makes the code so much larger.

I think instead of randomly having to choose a break point for smaller screens it would make more sense to use a (new) media query which determines if a specific element has overflow. Would be great if somebody with influence could push this to the CSS specs...

Navigations are these things where I personally prefer to render them twice, one for desktop and one for mobile. Its not only about these CSS issues but also about the DOM being structurally different to accommodate for a different design, making the CSS borderline impossible.

Remember two decades ago, before the smartphone era, websites were desktop only and there were separate versions for mobile, text only, PDAs and iPhones? Mobile first design means there's only one codebase for all the clients, and it is not just about layouts, but also about code structure. Mobile first plus some good use of semantic HTML meant if the HTML got loaded before the CSS file finished loading, the user still gets to use the webpage in a usable way, having a well-formatted menu at the top and the page contents after it. This is especially important for users with slow and unstable mobile connections. Wrapping desktop CSS in media queries was also a way to drop old IE support without cutting them access to content completely, they still can view the page in a mobile layout while we can use the latest CSS standards for desktops without worring about IE.

It always intersting to see how we the Dev's love playing with the "new toys" so we start using them at work then 6 month later we just fall back to something "basic" because it just feels easier or nicer to use :D It doesn't mean the "new toys" aren't great in the end it probably comes down to your personal preference. Mobile first approach is great and I usually start my design using it but we also have to adapt to different situations and shouldn't stick to only one pattern/approach. Really nice video as always Kevin! :)

Kevin, You are one of my top favorite YTubers, and I subscribed to a ton of ppl. Wish U the best! Love your content ❤

I love this. Well explained and demonstrated. ❤❤

Love your vids learned a lot with you! Thanks a lot!

Brilliant video, as always! My biggest struggle with mobile is I HATE the hamburger menu. I understand it's purpose and by now, many more people are used to it, so it's not a mystery, but I don't like it AND I see it "creep" into non-mobile displays. This video has given me some great "food for thought" and I'll try this approach out on a project I really need to get started on. :) Thanks for posting!

I agree 100%. Most of my clients want to see a wireframe layout for desktop. I then explain how the design will cascade down to mobile. I won't be changing the way I do this for a while.

I have always thought of CSS as "desktop-first, mobile-next", but maybe that's just because I personally prefer to use websites in desktop mode. I just think it makes more sense to treat your desktop layout as the "normal" one, and your mobile and/or tablet layouts as the "secondary" ones. I took a college class a few weeks ago on web development, and for all their examples, they forced mobile-first CSS design. The code took up twice as much space as it should have, and I had a very hard time remembering that my media query stuff was for the _desktop_ version. I spent dozens of minutes pulling my hair out over why something wasn't applying, only to realize it _was_ being applied, but only to the mobile layout. I like what you are saying here; "simple-first CSS" is the way to go!

A concept that I've taken a liking to from the backend world is composition over inheritance. Especially for scenarios like this where the shared behaviour is next to nothing, and those that are shared could easily be subject to change for one context, so it's easier to just think of them as seperate contexts from the start.

Mobile-first is still the way to go IMO. It's always easier to add things on desktop especially since they are much more powerful compared to phones. They can deal with different breakpoints or changing code much faster

I visually design for desktop first as that's generally the site to show the client. It's also the size with the most bells and whistles. As Kevin says the mobile version is generally just one column (sometimes 2 or 3 on tablet), so it's not a problem to adapt a more complex desktop layout down to mobile. The css though is mobile first, with the larger sizes overriding any of the default css.

Thank you Kevin for your useful content.

I usually think minimal first. It tends to work out well. I think it is similar to this approach, it's not exactly the same in my case, but that is largely due to my lack of experience.

This made me realize I have never done "mobile first" even when I thought I was. I just always design with mobile in mind, so that I don't run into surprises, but I always put all the mobile styling in media queries.

Love it! I always hated mobile first approach exactly because of what you covered in this video. Sometimes its just easier and less complex to start with the high complexity and reduce. Never understood why everyone always preached mobile first!!! Thank you for this video😀

What I do is design the page for desktop-first but then code it for mobile-first. That's my way of getting the best of both approaches.

I love this concept. I even "get" mobile first better now.

There exist a lot of discussions out there which approach you should go with. Actually, there is no right or wrong, the truth is both have their pros and cons, and personally I go through my page layout section for section and decided when it is more complicated. Is it on mobile or on desktop sizes. Then I can decide in which CSS file I throw in my CSS.

I recently just started mobile first. It can get a little tricky when you want to move to a larger screen especially when the divs are not in good positions to do display flex. 😅

The best example I have seen was viral screenshot of bathhouse site. On mobile everything looks fine. On desktop main picture is cut slightly more than needed - it cuts out all towels and context of poses, so it looks like frame straight from adult film

Wow, you really jumped into the fire with this one.😮

With the icons, you could always add a ::before and use a custom font with those icons in it. Then you don't need to "hide" them at desktop sizes, and instead you add them at mobile sizes.

The double selector has just blown my mind. LOL

as a dev it's a wealth of knowledge to start development from both ends. The project and user base will dictate which platform is used the most, and that's where the focus will land

We sometimes have layouts that are so different from one another that overriding behavior in CSS is no longer an option because even the HTML changes between mobile and desktop. That's when we start to have two versions of the header, one for desktop and another for mobile; there might be duplicated HTML code. But in the end, we take all the common functionalities to a controller, and the differences can be better divided among components, making the complexity of each one of them lower.

When I started developing web apps, I didn't know about mobile-first design. It just hit me when the UI had go from landscape (desktop) to portrait (mobile) mode. The narrative took me up for mobile-first. Recently, as I am working on the web app for my company, mobile-first have become something that's just make things complex. With a bit of research, I found somethings to help the front-end faster and easier to develop: - Notion/Atom/VS Studio like design is universal in nature is the content is simple like markdown or editable. - There are some generic blocks layout and functions, that changes like a transpose or just dimensions like the search bar if primary function is to search. - Flex is much responsive compared to Grid - Design and develop the web app like it's a single-page web app, it would help to reduce less used components.

Ive been saying this since I first heatd the term. Thank you!

I've always been comfortable doing desktop first and making everything work for mobile with media queries

Most of the time the only component that is more complex on mobile view is the navigation. Mobile first will be the easiest and simpler layout for everything else.

@7:56, I couldn’t agree more! I have been practicing Web Development for almost 2yrs, now, and I have always disregarded the “theory” of mobile-first design principles for this very reason.

It's an interesting thought, actually. I completely agree that it is much more of a case to case thing, and agree with people mentioning to keep checking how responsive (or unresponsive) the page is. I find myself repeating "mobile-first", but in reality what I do is understand how complex something is and how I can produce more with less code, thinking of maintainability as well! It's funny because I had some bad designs when I started where mobile-first would've been good. Then I learned about mobile-first, but that quickly transitioned into something way more flexible just because of how much experience with CSS I have now! It really is about understanding your tools and the system you have to work on which leads to good code-writing and maintanable structures!

I use approach, begin from device development first, then smaller smaller to implement the change of skeleton and then back larger and larger to improve and perfection it.

Mobile first approach is just makes all layouts messy and complex, because we're coding this layout on computer, so we can more easily realize how it should work desktop first layouts and what changes should occur on mobile or tablet widths.

The title alone is enough to make you my hero for 2024, no one is going to top this👍✌

Interesting thought. I agree on strategizing development and considering the path of least resistance in your implementation. However, I still feel mobile first makes sense in terms of displaying "default" or non media query relative styles on page load and only using media queries as he viewport grows. I do this for 2 reasons. 1) there is a greater likelihood for users to have poor bandwidth on smaller screens and 2) maintain a pattern of consistency. That being said, depending on the design or component structure, I will often start at large screens and deconstruct as I reverse engineer for small screens. Either starting small or large, though, I try to plan ahead for the path of least resistance and using the power of the tools available to me (like your flex-wrap or grid examples / intrinsic design). I may just be old and used to this method of operations, but it works for me. (getting into react or other frameworks - could be an entirely different video - strategic thinking)

I like this idea, write code which has less maintenance rather than choosing some standard because we have been told so.

I don't normally comment (long-time viewer here!), but I feel the need to point out how it seems like most people missed the main point of the video, and this might be due to the video title being slightly misleading. Judging by a lot of the comments, the discussion revolves mostly around mobile-first vs. desktop-first. The thing to understand is, going desktop-first with the same level of complexity and with just as many media queries is a problem as well. Kevin's point (if I understood it the way it's intended to be perceived) is actually not about mobile/desktop first but the "path to least resistance", as he says. The problem is simply how we may overuse/misuse media queries instead of properly leveraging the capabilities of the browser in the way we use CSS. I really think this video could have been titled differently to better reflect the points he discussed. I appreciate Kevin acknowledging at the start that he had also used this term "mobile first" in his videos because I learned about using a mobile-first approach from Kevin himself. I also learned from him many videos ago how it's possible to use a desktop-first approach just for that mobile navigation (exactly what he demonstrated in this video). It's just unfortunate when some misinterpret his message to be a "mobile-first vs. desktop-first" issue because his focus isn't really on one being better than the other; rather, it's more about the "path to least resistance" or even "simplicity-first", as some commenters said.

I find using multiple media queries per classes much cleaner approach, than one global media query and then slamming all other necessary classes in it.

As a simple user, I've noticed the mobile first approach affects design itself. I've noticed a lot of websites where the desktop version makes you scroll down endlessly waisting most of the horizontal space and making navigation tedious. Including sites like Apple's. Those sites are good looking but impractical.

Here here! Using the browsers native capabilities is a great way to start! Venture out only when you truly need something very custom.

I've always thought mobile first was a misnomer...it should really be "multiple sizes from the start". If you focus on one and ignore the other you'll have more work to fix the one you ignored later. If mobile users matter you need to be switching between layouts regularly.

In my previous company, Mobile-First became as much as a trending buzzword as Agile. The more people talk about it randomly through your work, the more you know they have no idea what they are … managing. Yes. Mobile-First was decided by management as a moto while it’s a technical consideration to be decided by the devs when the requirements are brought to them.

I have an issue with either Mobile first or desktop first... issues or problems pop up after the fact that you then spend way too much time trouble shooting. For the team I manage I have an approach I have called as 'Parallel development' and for the UX team 'Parallel design'. For each element we are considering desktop tablet and mobile in parallel, moving between each and deciding on what works, if i do this on desktop how will it transition to mobile and vice versa, what are the compromises. I think it is just about being more fluid in where you need to start based on the complexity and moving back and forth to achieve the end result with efficient code. `Thanks for having raised this issue on your channel... too many non technical managers site mobile first as a requirement without know the implications of this. CSS, Grids, Flexbox have all changed how we develop, so this mobile first thinking is already old school.

I tend to make stuff desktop-first then copy the CSS code into a min-width media query, the result ends up being the same. I prefer that approach because I spend 99% of my time in front of a PC, I barely use my phone.

I love your videos

"Path of least resistance" is a good paradigm for design. Often, mobile-first will satisfy this criteria, but it's worth keeping in mind when implementing a UI design.

I like to go ahead without worry and build on desktop but think about what I would need to do for mobile as I add each new thing.

I have been making a base first, that looked good at first glance, then I play around with browser to see where the ui breaks, the first thing I try is using min() and max(), if that's not cutting it I try to use some calc() or even a mix of all of them (ps I still can't exactly understand clamp's behaviour, and tend to avoid it). I also try to use em, rem and ch a lot to have it work with the native font sizes, which often times makes ui work very good. And if absolutely necessary or if I literally want to have a completely different design for certain casses I try out queries (both media and container). I also tend to work in parts/components, I finnish each standalone part of the ui first and then put emm' together, which could potentially be bad, but so far worked out for me. The thought of mobile first design never really crossed my mind, and often times it's the last thing I do. (On my portfolio I have a css only hamburger manu for screens having too little with to have the nav bar)

I think the most important thing with mobile design is usability; just to remember we may use that page with our big fat fingers on a small hi-resolution screen without a chance to hover over elements.

What i was looking for here is inclusion of the design phase. When a visual designer works in, say, Figma, do they design for medium screens ie desktop, or very small screens first? We design desktop first because it's natural for most websites. The layout is subsequently adapted for mobile. Building the site will naturally follow the same way. It makes sense for CSS media queries to use 0 as a starting point, so that aspect could be termed mobile first. But that doesn't make sense for the overall design and build mobile centric unless the project is something like an app that is meant primarily for phone.

For me mobile first is just a way to figure out the extent and tone of content I want. I feel like with doom scrolling habits engrained into mobile users it becomes important for me to optimize a small screenful of information, low text density, high visual contrast, get the message across quickly and then spread that in a more easy going layout on the desktop. I find it easier to simplify and “slow down” a message than the other way round. But I understand that everyone is different and there is no silver bullet. Some prefer going from desktop to mobile and that’s fine too.

I always thought of the "mobile first" idea more like a restriction for the designers, more than any specific implementation. If the designer is forced to make a fairly linear layout for phones first, they are less likely to make a complex layout that requires a huge screen to be understandable. And forcing the designer to think this way was of course much more important in the early days of smart phones, because now all designers I work with think about how their wide screen design should wrap to a mobile design automatically. When it comes to the specific order in the css and whether to use min-width or max-width; it used to be important when we still had to support Internet Explorer; because whatever was inside the media queries would not be applied at all on those ancient relics. So my implementation philosophy weren't mobile or desktop first, but rather the medium sized screen compromise layout first (what we would think of as a tablet in landscape orientation size today) and specific very narrow screen and very large screen adjustments in media queries. Today nobody bothers with supporting IE; and all modern browsers support media queries, so it really doesn't matter if you put absolutely everything within media queries... in fact it might sometimes be easier to make a print stylesheet if everything for the normal layout is wrapped in media screen and something media queries. I tend to just have all the common styles (i.e. things that apply for print, mobile, tablet and big screens) outside of media queries, making it as responsive as possible without breakpioints, and just add specific narrow screen and super wide screen stuff in queries. And print styles tend to be just the common styles plus a bunch of display none of UI stuff inside a media print block. The common styles still tend to accidentally still largely work as an old compromise layout; but I no longer care at all if the menus are completely messed up and includes duplicated and redundant elements if you comment out the media queries. So I almost never display none things outside a media-query and then display block it inside one; that's just silly.

Mobile first is not about css, but about a design. For sure, your solution must solve the problem, not create a new one. But focusing on style direction is pretty good way to resolve most of the requirementa.

In the navigation example, if they have to work differently, I have a personal approach of building 2 sets of navigation and turning them on and off at different screen sizes. I find this removes the dependencies on each other, and allows for more intuitive code organisation - both of which make updating each easier. It has a downside of have two things to update if the options change, but I find that’s often much simpler than handling css inheritance dependencies that are easier to miss. Have you ever taken that approach and does it have other issues I’m not aware of?

it depends on the use cases, if your building something that will be used mostly on desktop, mobile-first makes no sense, example : management sites

Creating a website from scratch with "mobile first" in mind is good, but I'm not sure about switching from desktop first to mobile first. I did it on a huge website, it took a lot of time (not even ChatGpt was very useful in making the transition) and in the end the lighthouse scores were just a little bit better. In my case I would say that I lost time doing it. One thing that I found particularly annoying was using the display: none. It's easy to use it in media queries when you start with desktop first for any type of elements, but things become awkward if you start with display: none and then you give it a different value in the media queries, because that element could be a table-cell, an inline-block or something else, so you need different definitions for different types.

Great video, can you please provide the code link? Of this toggle menu?

More straight-forward apporoach would be just to wrap mobile-version of the menu in mobile-only media query as well as desktop-only query. Then u have defaults on both ends and then it doesn't matter which goes first especially in components that differ completely as shown in the video🙂

Finally... I feel vindicated... a guru like,you saying what I have been saying and doing makes me feel vindicated and happy....🙏🙏🙏🙏🙏🙏👌👌👌👌🌹🌹🌹🌹🖖🖖🖖🖖🖖🖖

As I go through the comments it seems not many developers have an UI/UX team that provides design to them, like they seem to chose they want to implement things. In many of my experiences you get designs already done by the design team and all you have to do is replicate it with CSS, you don't really have a choice on "do I really need media queries?". What is true on the other side is that we should always do the less demanding (code wise) first and increase specificities after.

"Sadly, most things have a lot of nuance in them." That's just good life advice.

Curious what your thoughts are about splitting up the entire template into two separate templates (desktop/mobile) and having the server choose which template to render depending on their device type / screen width. Flask for example can detect if you're using a mobile or desktop device and choose which template to render. You can even split up the backend logic depending on what device you're using or do what sites like fb does where it redirects you to a mobile subdomain.

I think mobile-first makes sense from the perspective of the state of css like 10 years ago. flexbox wasn't even standard yet, we didn't have grid at all, there were no minmax functions, etc. and it was the heart of the smartphone boom. but from both a design and engineering perspective the mentality never made sense to me and I'm so grateful we have tools now that make them mostly unnecessary. it's been my experience that the mentality is embraced by people who just don't want to deal with css at all. I begrudgingly respect that the majority of web usage is mobile, but I personally hate using websites on mobile because the experience is always so dumbed-down and flat. but what really bothers me is that mobile-first has led to bland homogenization of web design on desktop. 99% of desktop sites use the exact same format of vertically stacked segments under a hero image. it's not even mobile-first, it's mobile-only, and you end up getting a compromised user experience regardless of what device you're using. it does avoid complex code but like... at what cost??? thank you for making this video.

For elements that are very different, you need to write separate components for min-width and max-width. At the same time, it is better not to mix them and not try to create common styles.

Mobile first never worked for me. But not because of resetting values for elements but because "Desktop"-sized layouts might need additional layout-helper tags, like a or something like that. You will only realize this after you've reached the point where the current html isn't sufficient, so you need to change it and maybe even change the CSS code again. Also I think it's better to start with the layout the designers created, and keep that version as long as possible, for example: change the menu to a "mobile" version only when the menu entries won't fit any longer. This also means I don't have fixed breakpoints.

I’m curious to see how container queries will shake up these kinds of methodologies.

Most of the browsing today is done on mobile devices, hate it or love it but that is a fact. So depending on your product, mobile first is 99% of the time the correct and smarter approach.

That's exactly the process I use and it's much more efficient

how did you make this hamburger menu transition? very interesting, is there a CSS only solution? is this only an opacity change?

Hello Mr. Kevin. What is wrong to use separate components on creating Navbar?

Generally speaking I think you should _add_ content conditionally. If that means "min width" or "max width" depends on the context, but in 9/10 times there's less content on mobile.

Great video. But I would honestly like to generalize to "the problem with **add-any-design-paradigm here**. The issue is not that mobile-first, atomic-design, intrinsic-design or whatever have limitations but rather that people (especially in the web design / web development sector) too often see them as dogmas. For me it boils down to use those ideas as basic rules, but you always have to think for yourself (like you presented here very well) about what still makes sense and when to breake those rules. Thats true for individual projects as well as new paradigmes like Tailwind, which breaks every "common sense" of what we thought we knew about stuff like code and style separation and so on and still makes sense for a lot of projects / teams.