5 CSS mistakes that I see way too often

[@facundocorradini]

Great tips! A word of advice on refactoring: be careful with those comma-separated selectors. If a browser doesn't recognise a selector on the list it will discard the whole rule, turning a small issue into a much bigger one. So avoid using browser-specific o any advanced / recently developed selector on those lists.

[@KevinPowell]

Great point! And no trailing commas either... I've done that before

[@cowboyfrankspersonalvideos8869]

Excellent. I allays try to make sure that any effects I use to make a page "pretty", won't interfere with reading or navigating if that effect doesn't work correctly.

[@WyzrdCat]

Damn never knew that one!

[@TNeulaender]

Only a problem until houdini gets widely used in browsers :)

[@carolmckay5152]

I learnt this recently with :focus-within.

[@BasvanderVeeken]

00:00 Introduction 00:25 #1 Overly complicated selectors 05:23 #2 Make your CSS readable 07:33 #3 Keep your CSS organized 10:58 #4 Refactor your CSS 13:07 #5 Removing the outline 17:24 Bonus: Text contast is too low

[@gastonbengolea6018]

thanks

[@AmodeusR]

It's a nice touch when we need to review the content but not wanting to watch everything from the beginning :D Thank you!

[@aarontheeranitpongtongmuan233]

Thank you so much.

[@ernestomercado8176]

Hero

[@braveshine2579]

thanks

[@malcolmrodrigues911]

One trick I always use for css files with vs code is using regions. Really straight forward : /* #region _optional-name_ */ .css{} /* #endregion _optional-name_ */ Not only does this make it easier to segregate and organize your code, but vs code also allows you to collapse a region just like any JavaScript or HTML block, which in the long run helps you scroll through lengthy css files.

[@janklosowski]

19:00 The BIG reason to avoid a single-line CSS is that if you work with other people using a version control system like Git, it will make your changes much harder to read. The whole line will be highlighted as changed, which makes it annoying to look for what has actually changed. The same about debugging, when you get an issue in "line 331". It's ok to use a single line CSS if it's a single rule like .hide { display: none; } although staying with one convention may be easier for your brain in the long run.

[@lloydthomas4481]

I've been guilty for removing the outline. Adding the :focus to the elements is a really neat trick. Also, I never noticed the contrast warning in Dev tools. Great tutorial as always. I always learn something new x

[@sarfraznawaz7248]

Greetings from Pakistan Kevin, im a bank teller trying really hard to change my career by learning web development and your videos have been extremely helpful for me. Keep up the good work man.

[@PrinceJJGoated]

Good luck man!

[@cosmicegg1283]

Luck mate

[@jawad9757]

I wish you well on your journey

[@mohamedhasen7454]

Good luck man

[@soniablanche5672]

Today I learned Shift+Tab does the reverse of Tab. LOL

[@KevinPowell]

Awesome! I have no idea how I learned that, but I'm so happy that I did, lol.

[@DutchRatedGamers]

However don't try to have it connected to Steam.. The overlay will pop up. -- Dunno why, but some people even connect their IDE to Steam.

[@liondeluxe3834]

I had to search it up last week because I hated manually unindenting code

[@sobanya_228]

@@DutchRatedGamers It's a little hilarious when something like "playing Visual Studio Code" pops up. That one I've seen on discord a lot.

[@allie-ontheweb]

Shift is often the reverse-command button - Alt+Tab moves forward in recently opened tabs, Alt+Shift+Tab moves back. Ctrl+Tab in browsers changes to tab on the right, Ctrl+Shift+Tab moves left Also it's why Ctrl+Shift+Z should be redo, not Ctrl+Y. Looking at you, MS Office.

[@TheElkster]

This type of video is so, so helpful! I've always seen the complicated selector format and have agonized over it (not always understanding it fully), so now you have explained that it isn't even necessary, it has helped me no end!!!!! I'd certainly love to see another video with this type of content! Way to go, Kevin

[@robpuchyr7407]

2:48 Strongly disagree. Using classes for everything just causes classitis. You even said it means more coding in HTML. Too many glasses. I’d rather only class a list or a table as whole in one place without coding list items or rows and cells. Why code classes for every list item or every table row or table cell when you can simply class the list or table and have the CSS do the work? This way, I can change the look or behaviour of a table by just changing the table’s class without recoding rows and cells too. More coding in HTML is not worth a little readability in CSS, especially if you have multiple HTML authors in your team. Apart from that, great video.

[@stevestefler880]

Main aim for CSS was to get rid of ton coding in html. If you type classes for every tags, you can also write all styles in html, why to bother to do it in css at all? Also most of author conclusions are stupid, starting with first one: making it more "readable" makes it hard to manage/add/edit without rebuilding,

[@williamhorn411]

I don't think that's what he meant by "use classes for everything". Obviously if you have a list, for example, it would be best to style the list and select it's children than manually assign the children their styles. When he says "use classes for everything", I'm pretty sure that was in context to getting rid of unnecessary/overly complicated selectors.

[@harmonicresonanceproject]

I'm finding this channel incredibly helpful in my CSS journey. Thanks!

[@MikkoRantalainen]

4:00 A nice trick to create custom checkboxes is to set checkbox colors to transparent and then render the custom checkbox in pseudoelement. Then you can just use selector [type=checkbox]:checked::before to style the custom display.

[@terryg4415]

Love this, thank you. 35 years ago when I was learning to program, my teachers emphasized readability, commenting, etc, and back then, it was “structured” code, and it still annoys me to see code of any sort that isn’t organized well. Now, learning CSS, this is so helpful to me.

[@KevinPowell]

It's so easy to be lazy, but in the long run it saves you so much time, and makes anyone your working with love you, lol

[@jennifertran3830]

Thanks Kevin! Just discovered you - and I must say, I have a feeling that your content will answer many of my best practice questions, and hopefully after going through your videos, I should be more confident and actually pursue web design! I used to do it in middle school w/ myspace - little did I know, this is an actual career!

[@gempio2634]

I'm coming from a backend background so proper spacing in front end code so that it follows language standards is difficult. What really helped me was installing a formatter plugin and setting it up such that it formats the code every time I press ctrl+save. This way no one can ever complain that I didn't take care about my formatting. Highly recommend it to everyone.

[@omkay2569]

Good points. Most apply to all kinds of code. Some more tips from issues I've run into: 6. Not checking browser interoperability early in the project. I've implemented a whole layout with grids only to realise they aren't fully supported in IE9. Better to check this early and save yourself the headache of rewriting. 7. Not using box-sizing: border-box. CSS's default here was obviously the wrong way to style boxes because trying to put two 'width: 50%'s side by side can result in things wrapping falling off screen if you don't subtract the padding and border sizes. I don't know the arguments for content-box but I've never had an issue with border-box. I guess you have to be more careful with min-width and min-height since you need to account for padding and border. Meaning for a 10x10px image, min-width: 10px; will be too small if you don't add on border and padding. 8. Using too many divs. Divs are great for creating collections of elements to be all within the same box. But I far too often see divs redundant nested divs which appear to provide little or no value to the code. One big example I see a lot is using divs to apply a style to all its descendants. But this can and should be done with a class. The more divs you have, the harder it'll be to reason about the layout so strip them out where you can. 9. Along a similar vein, using divs where a better fit semantically would be a button/section/footer etc tag. This is more of a HTML issue but still involves resetting the existing elements CSS.

[@KevinPowell]

Very good ones! border-box is maybe the best thing ever, shame it's not the default, but at least it's not too hard to fix :)

[@sntxrrr]

Bad color contrast is not a css mistake, it is a design mistake and belongs in a video of common design pitfalls

[@julienbongars4287]

Great video but there are some things I would like to add to this:- 1. Overly complicated selectors I generally agree with this statement but there is a lot wrong with the way you explain it. Firstly, you should not be naming. every. single. html node in your project. There have been waaaay too many times I had to step in to maintain a legacy web application and see classes like this: nav-menu-item-button-alt-clicked. It's not necessary and it's not worth it. Why? because you styles are going to start leaking into you html and overall make your life (or the people you work with's lives) difficult. Too much, DO NOT do this. You can have generic selectors such as .navigation > btn.clicked. If you think this is hard, you should use scss or less. No one is going to judge you for using webpack or a preprocessor. In fact most websites use preprocessors and so should you. ALWAYS ALWAYS avoid using general or universal selectors at the root of any declared style. selectors like * > div or html are (in my books) very bad practice because it means your styles are uncontained and can cause side effects if your element or page is injected into a different css project. One final point is that I almost never read back css on my IDE but rather, I use element selectors on the browser. If you become proficient in this, you will find it becomes easier to understand the 500 lines of spaghetti that is hitting your element. You can be the cleanest developer in the world but CSS and SCSS are naturally very messy languages and it's ok if there are more than a couple of selectors hitting a particular element. Just be smart about it. 2, 3, 4. Make your CSS readable If you are spending even a couple of minutes to refactor your CSS, JS, Haskell, Cpp, anything, you are wasting your time. You will save so much time if you just installed a linter (like prettier which you already mentioned) and just factoring your code that way. Don't like the way your linter is factoring code? Just configure it using a .prettierrc or otherwise. Using a linter is good for three reasons, (1) is it forces a standard way to format your code in a team, (2) is it catches careless mistakes or bad practices as you are typing them but most importantly (3) is you save so much time! I almost never press "enter" as I am coding these days but my code stays clean because I use a linter. It is the best. If you are lost, install VS Code and use that. It comes with a tonne of linters preinstalled and the process of installing new linters is extremely easy. I remember one of the first projects I completed was a static website I used to promote myself a couple of years back. It had about 500 lines of HTML and about 20000 lines of CSS. No matter how hard I tried to keep it organised, it was always messy and difficult to maintain. Now imagine working in a team where 5 devs are in the office, 5 devs are MIA and 5 devs are working remote over a couple of years? Things are going to get messy. Use technology to deal with this. Use CSS-modules to refactor your CSS into manageable chunks that only target parts of the page. Remember when I mentioned not using universal selectors? This carries on here as you want whatever is written in each module to remain in each module. Segregate by real estate, not by logic. It also helps to keep your design minimal and consistent to maximize re usability. Again, preprocessors like SCSS or LESS helps a lot here. Just don't get carried away. DO NOT just comment all willy nilly. The more you comment, the more comments you have to maintain and there is nothing worse than lying comments. If you structure your code correctly, you will find it easy to read your CSS. If you think otherwise, you need to refactor your CSS before you think about comments. Comments should explain the why and not what or how. On a side note, if you are using VS Code, you have intellisense to tell you the hiarchy of selectors as you code along. One thing I definetly agree with you on is you should always refactor as you work. Always ask yourself if you are over complicating things, if you are inconsistent (suddenly using css grids when you have consistently been using flexboxes) and finding ways to make your code reusable with sacrificing readability are excellent practices in any language (I think you mentioned this already). At the same time, try not to write smart CSS. Just think, you have to be twice as intelligent to debug a block of code than you have to be to write it. Keep in mind what websites you are developing for but always remember you can use a preprocessor like bebel to apply polyfills to make your CSS compatible with your target browsers. 5. Overriding native behavior Yep totally agree with this. Try not to override native behaviors. Just because you can do it in CSS does not mean you should. In addition to the selector boxes, there is also smooth scrolling, caret color, the highlighter color, pop ups, etc... Actually I find this is more of a design thing then a development thing. Two things I would like to add, just imagine when you are using javascript to re-write something that is already available (such as a selector menu) you are spending time to write something that has already been done by someone smarter than you. Does this mean you should go crazy and download every dependency? No but that is something I can talk about for hours. Also, the more you write, the more can go wrong and the more you have to maintain, optimize and secure. This is the trade off you have to make. If you are struggling with starting new projects quickly, take the time to create a nice clean competent boilerplate which you can fork for any future projects. You shouldn't need to manually have to initialize new projects whenever you are given them. Don't be afraid to take shortcuts as long as they do not compromise the quality and integrity of the code. Lastly, you forgot the two biggest cardinal sin in CSS and that is using the !important sparingly or position absolute or pixel perfect CSS. For !important: yes, sometimes you need it (not because you can't but because of all the bad CSS and abundance of !important tags or inject-able elements. Do not do this! This is lazy! Really understand the problem you are fixing and fix it. Negotiate with your stakeholders to clean up the technical debt. They and you will thank each other later. For position absolute and pixel perfect CSS, trust the browser to position and paint the website for you. Just because it looks nice on your screen does not mean it will scale nice to your user's screen. It is also generally not reusable and very hard to debug. Yes sometimes, it can save you a lot of time, but don't over-rely on this. Use it sparingly. Anyway, this has been my thoughts and personal opinion. I hope this helps and didn't come across the wrong way but it is something I feel quite passionate about as a full stack developer. Do feel free to reply to this comment if you have any concerns, clarifications or questions. I'm a nice guy, really.

[@mudrRock]

Wow, this is awesome, thank you! Do you know where (or how) can I learn about writing good CSS (or about things like BEM) (webpage, book, etc)? I'm a beginner and I've been struggling with CSS.

[@juliocodes]

Something that I've seen a lot that could be considered a foul is not using the short hand version of certain CSS properties. Although, I mostly see this with beginners. I've also noticed people not using a fallback font when they use a custom one.

[@kencollins1186]

One could go either way on shorthand versions. The problem is that they are hard to figure out if you haven't reviewed that part of the stylesheet in a few months. I use them sparingly.

[@juliocodes]

@@kencollins1186 How so? The short hand will still be the same as the long way. The only difference is that the short hand will save you time as opposed to doing it the traditional way.

[@kencollins1186]

@@juliocodes The shorthand version only saves you time the first time you use it. Unless you are coding 8 hours a day (which I'm not), the shorthand version takes longer if it has several parameters and you have to look it up to find out what the parameters mean.

[@nikhilmwarrier7948]

Awesome tips! I personally would recommend instead of globally removing outline on focus, just do it on individual elements. Although it is a bit of a redundancy, keyboard users will have a way to navigate, even if you forgot to specify states for focus...

[@rychei5393]

Ya I like this one better.

[@rashikkarmacharya8023]

i was missing out on the focus and outline and surprisingly it never ever came to my mind. Good to know man!! . Cheers!!!. 18:22

[@Asaloy]

outline is also important for handicapped persons.

[@subish20me]

sai vanyou sathi

[@vskand]

The :focus / outline tip is so simple yet so brilliant! Thanks

[@ZackPyle]

Thanks for the reminder to keep CSS clean! I just went in and added a Table of Contents to a really large style sheet I'm working on. Bonus: I added a ToC to my starter file as well so all future projects will have one as well!

[@KevinPowell]

That's awesome 👍

[@filipe.webber]

I’m really glad I found your channel. It’s improving my understanding of css a lot! Thank you for taking the time to record these videos.

[@mindcastsoftware]

Oddly enough, despite working with CSS for over a decade (or maybe because of that), I do the opposite for foul #2. I actually find the compressed version to be easier to work with and sometimes even compress other people's CSS when I bring them into my projects. The primary advantage is that compressed CSS allows me to view a lot more CSS on one screen without having to scroll. For me at least, that's important, because scrolling could sometimes disrupt my ability to maintain a mental model of whatever I'm working on.

[@lukerazor1]

This is the dark secret of coding standards, different people work better in different styles, having a standard only benefits the person setting the standard :)

[@cowboyfrankspersonalvideos8869]

Contrast. My second biggest complaint about so many websites. We're going through the same thing from 20 years ago when some webmasters put dark blue writing on black backgrounds.

[@michaeloosthuizen2383]

One line rules.... wow, that brought back memories. I still tend to do that for single prop rules as a short hand, but thankfully I don't write much CSS anymore.

[@VeitLehmann]

Most of the fouls you mentioned are what we used to do in my first professional job 15 years ago: Preferring IDs, deeply nested selectors to scope everything, and even having all the properties in the same line (we used a CMS which didn't support minification, so we wrote minified code 🙈). I didn't like that and I was really happy when Nicole Sullivan came along and proposed one of the first CSS methodologies, OOCSS, which really resonated with me and was close to what I used to do: Composable classes with low specificity, named according to what I like to call visual semantics! And it's still the way to go today most of the time. Also, regarding using IDs and element names for styling: It happened quite a few times that I suddenly had to have two instances of #sidebar on the same page with the same styles. And, of course, that I needed to style a link like a button or a paragraph like a heading. So, classes for the rescue.

[@johnswanson217]

I've never thought about that last one!! It's about accessibility and it seems important. Thank you.

[@vukkulvar9769]

Also, factor everything using SCSS ! Readability increase a lot ! Help avoiding repetition, keep things neatly together.

[@SaleKnezevic]

The :focus one is quite neat, kudos Mr.Powell. Great as always.

[@rickdiculous23]

I want to thank you Mr. Powell. your videos are a tremendous help to me in my advancement in css. Its been by far the most challenging part of my progress as a web developer. Id be lost without your help and so you have my thanks.

[@adrianobonano]

The end about the focus was such an eye opening thing to me!

[@andreaskarz]

So, the first tipp I don't agree. I like the complete selectors in structure so it's better to understand. And in the moment, you have another link in the Nav but outside of a then you are safer wir the complete selectors

[@_torgeek9108]

Finally I get a channel that will make my transition into front-end development easier. Thanks for the great video.

[@camfre4k]

My biggest problem is how to place items. How to make a navbar over a picture background. How to move divs where I want them as well as the content inside them. I think as a beginner that's a real struggle

[@calvinwilson3617]

Just a quick note, at 3:20 you note how you would need to add a class to all of your elements, thats true but you didnt mention the ability to put a .nav class on the nav element, and using the element selectors afterwords. It allows you to style an entire structure based on the elements with a single class rather than having to add the same 6 classes to the same 6 elements, you can just put it on the wrapper.

[@artemx100]

Firefox dev tools do in fact have that contrast inspector you were showcasing in Chrome. F12 > Accessibility tab > Enable it > Click the button at the top left (while staying in the accessibility tab) and start inspecting

[@KevinPowell]

Thanks a lot, wish that was on by default!

[@mirvids5036]

Nice to hear comments about contrast in text. Too many people think it looks stylish to have feint fonts but its crazy. It also goes against the "accessibility" ideology thats been around for years. That said, you're not getting too old yet, you still speak fast like a teenager !

[@a_l_o_k_1991]

Removing the outline and replacing it with own CSS.....that was AWESOME tip !!

[@pieter-venter]

6. I've seen many projects where developers are too lazy to open the css file or create a class and they just create inline styles. In react they end up creating camel cased css-in-js. When I join a project where people have done that, first thing I do is to introduce the team to styled components

[@paull8678]

Ugh! I used to have a dev on my team who would mix inline and spaced CSS. It was *maddening*. SO easy to miss something when you have each property on a new line, then have two on the same line mixed in. Took me a while to clean that mess up once he left.

[@slobodankustrimovic2538]

2:18 nav isn't necessarily used just for primary navigation. There could for example be a nav for primary navigation and another for breadcrumbs. So targetting nav isn't the best approach in my opinion, better to target it by class. Other than that, great video.

[@KevinPowell]

Great point that pages can have multiple navs, and definitely not the right approach in that situation 👍 A lot of beginners start that way, so I wanted to address it, but maybe I should have pushed more for simply using classes

[@llejk]

About the contrast, something which needs really more attention: Bad monitor settings, especially in combination with cheap monitors. Some people like to tune up brightness and contrast. Unfortunately that can have the opposite effect on light font colors, something like #ccc on white might vanish even with good eyes.

[@calyodelphi124]

Regarding CSS foul #2, I do that all the time with my own CSS, but with a little caveat: If the rule has more than two properties, I break it up into multiple lines. But if it's just one or two properties, I save... well... it's not so much filesize space as it is vertical space in the text editor by doing that. I do this a lot especially when I have blocks of any kind of repetitive code, whether it's CSS, markup, or even code-code, where I will put each repetition on a line unto itself, chunk them all together, then use whitespacing like no tomorrow to vertically align things all nice and neatly. I find it LOADS easier to be able to vertically scan a block of repetitive code that way.

[@sammorris1906]

Wordpress/Elementor is about as far as my web dev experience goes so this is just a bit of a hypothesis - Adding comments and table of contents sounds great, but would it be better to make separate files for your buttons etc if you're going to have massive CSS documents, or would that just cause more problems?

[@miiksn7561]

Good question; you can, and sometimes it might be what you want. But loading many css files might be a performance issue, and it also might just complicate things further as you have to look in multiple files. If you want to seperate files, you might want to use a tool such as SASS/SCSS or maybe try using css modules, which compiles into 1 css file (thereby eliminating most of the issues).

[@fastboy8703]

I saw a few of ur videos and I must say that: Your keyboard is music to my ears :)

[@rachanaa6745]

Much needed topic ! especially when we are working in a collaborative project with multiple UI folks.... Feeling to share the tips with my team... great compilation of topics here... thanks !!

[@octothorpe12]

You kinda implied this a bit in your "Foul #4", but I'd say "not embracing the cascade" is a pretty big foul. CSS is at its best when you make your general case first, and only code for exceptions to your general cases. Otherwise you wind up with way more code than you probably need, which leads to more complexity/bugs/difficulty understanding later (Fouls 1-3).

[@magburner]

I like to organise the CSS rules for each selector according to their role. This usually involves two blocks, one for positioning rules, and one for styling rules. I also like to place them in the same order, I find that this makes quick identification easier.

[@KevinPowell]

I like to group things too, though the order switches sometimes. I try to start with margin+padding, then type, then positioning if I have it, and so on. Whatever flows, but I do like keeping related properties together

[@abrahamf6124]

This was so helpful, I do organized my stylesheet but not enough, this was a great reminder

[@BaldiGiovanni]

Very useful tips, especially the one on focus. I would love to see more on files architecture and writing comments in SCSS. I'm currently following the Sass guidelines but struggle to apply them to complex projects.

[@ITAC85]

Yeah, my CSS is not organized. And I don't put my CSS in a .css file, I literally just use the tag.

[@danielf535]

My advice: Learn how to use a linter like Prettier to format your CSS code. Then you won't have to think about manually formatting your CSS to make it readable. It will just go through the entire CSS file and do it for you automatically.

[@fivebyfivesound]

I’m a beginner and wonder about best practices all the time as I’m learning, so this is very helpful. Thanks!

[@tomaskot9278]

It's a nice video, but I must say I cannot agree with the overly complicated selectors point. The first part (nav ul li a -> nav a) is absolutely fine, but I don't agree with giving everything classes. It's a bit funny because few years ago it was the right and cool thing to use proper tags for everything instead of divs and use as few classes as possible and now the trend is supposed to be classes everywhere again? What is the point of replacing "nav ul" with .nav-list and "nav li" with .nav-list-item? Isn't "nav ul" by itself clearly saying "hey, I'm a navigation unordered list"? By giving it a class and using the class in the css, you are doing extra work that duplicates something what already exists (it's a bit like giving all your 's the class "paragraph"), while gaining no extra performance or readability and also you are increasing the chance of a bug by making a typo. In fact the tutorial videos on css/html on KZbin (I'm not saying it's also your case) are all full of mistakes where the author names the tag "main-content" and then types ".content-main" in the css - something like that cannot happen if you just use the tag names - of course if it's possible and doesn't lead to really complicated seletors like "main section:last-child h2" instead of ".right-column h2".

[@mikeicon8488]

I'm a veteran but I still like to write my css linearly instead of vertically spaced. I prefer scrolling less to find the selector I want. I tend to keep most declarations short enough not to require horizontal scrolling but in instances where there's no way around it, I'll break it to multiple lines. I think it's kind of a habit from the pre-inspector days when finding particular selectors in a really long css file was much harder.

[@alystair]

Re: readable. Over last 15 years I've found I appreciate 'denser' single wrapping lines where properties/their values have no space. Assuming the properties are organized in a specific way (e.g. position first, text formatting last etc) I find I'm able to navigate/review CSS much faster than one line per property.

[@montycora]

Super agree, I think it is super annoying having 12938120983021830912830219 lines of css by keeping everything opened. One lines makes things really compact and easy to find. I am sorry, this is not a beginners mistake, this is taste and choice. I have been coding for 20 years and I write all my css properties in one line. Why waste space like that??

[@arminmatthes]

On the case of chunking related CSS selectors with comments - even for the most simple of projects I won't bother without SASS or PostCSS anymore. These tools take less than a minute to set up and allow you to split your CSS into small files that do only one thing. Plus, they give you awesome superpowers like nesting that make your CSS look cleaner and more readable as well.

[@lucamantova3070]

The contrast bit is important as that affects people like me who have really badly calibrated work monitors. On some websites, i can barely read anything.

[@productplacement39]

one of the biggest annoyances that I keep encountering on some HTML and CSS tutorials (and it has been a trend for the past few years) is, tutorials with annoying music audio, instead of a helpful and easy to understand voice over instructions. This always throws me off when I come across a tutorial clip that has a length of about 10 minutes with a lesson title that makes sense only for me to get thrown off by a music clip running the entire duration. Sure, maybe it's just a way to keep the tutorial brief but some people like to listen to voice instructions (when it's done properly). Voice over instructions help some people understand how to and how not to construct the html and css documents and why some tags and selectors are better choices over others. For me, that helps me learn and understand more complicated concepts in a better way.

[@AbdulKader-jt5gd]

Helped me a lot. Thanks Kevin Powell.

[@maerosss]

I don't really agree with the CSS readability: My way of writing css has been the exact opposite actually. First I was with tabbing everything and then I started to put it in lines (as long as they're not over approx. 5 rules), exactly because it's easier/faster to read. It's beautifuly compact and clean as you said. Though it is true, my approach to styling is different than some have it. Nowadays, when I want to style something or discover the styling of something, 90% of time I use the web inspector, change it in there and only when I'm happy with the result do I copy it to css. Why go back and forth between web and css, when you can make it in one go :-). I use the same technique when I create new element: Create html > add classes > put empty classes in css > inspect in browser and add styling to all classes > copy to css. Btw., about organizing css: You are exactly right. This is where I used to make over 1000 line css and then finally corrected myself to split it into multiple files. Beautiful. Until new colleague came and split it into even more files, including some sass mixins etc. It's nice, when you know where to look for something, but when you're styling something and have to switch between two or even three different css files to do just one element, that's a nightmare.

[@kedigiller111]

Removing the outline... that's was awesome tactics for me. Thanks a lot.

[@chrispratt3047]

I know it's only a small thing because I can quite easily specifically select a link to open in a new tab, but I absolutely hate it when they don't put a target blank in their links! Considering how easy it is to do too

[@PeaceOutILoveMrYoung]

I LOVE custom classes and ID's. I was kind of worried I was overusing them. Thanks for the reassurance.

[@Morrile1]

Once again you talk about things others do not, very positive, love it, thanks

[@ahmedr.]

One thing I noticed, when I used compound selectors (as a way to make code more understood!) that media queries for different screen can not override whatever style being used for that element that was selected with compound selectors .. I guess compound selectors are not not just a clutter in code , it add more specificity that should be taken into consideration when using media queries.

[@jamiemarshall8284]

Good video! I have one bone to pick here. If you globally set outline:none for focus, you are kind of setting yourself up for some troubleshooting hell later when, when messing with tab orders. Much better to just remove focus in each class, even if its not DRY.

[@clevermissfox]

Great tip about styling focus!! Thank you!

[@Thebiggestgordon]

Is it reccomended to split a big or chaotic css file into multiple smaller ones? I'm just wondering whether it's better practise to separate styles for different components into different files, or to have all your css in one place.

[@CarlitoProductions]

One foul I am doing is I end up adding useless css/Sass attributes I don't even need and don't do anything, because I forgot to remove them or check if they contribute to a component

[@jaceborg]

Ref. the contrast at the bottom of the inspector popup: is there a setting that's needed to enable this as I'm not seeing this on my PC? I can see it with the colour picker when i look at the styles panel but it's absent from the inspector popup. Thanks :)

[@KevinPowell]

Not that I'm aware of, it just showed up for me one day.... hrmmm.

[@kerryoneill1210]

Thank you so much for these tips. Being new to CSS...I've come across many templates that use Foul #2 and Foul #3 (Organising the CSS). I've spent hours in reformatting the CSS so that I can understand it and know what the CSS is doing.

[@tolstoise]

"I find out white people don't make this mistake to much" 😂 18:22 Kidding aside, the : hover tip is something that I would definitely use in the future!

[@andrei8299]

I paid attention to this too ahahah

[@jellycoding]

I also had to listen to it a couple of times. But can't really hear what he said...?

[@bawaparampreet24]

he said on white, people don't make this mistake too much, but on dark....

[@F00dCHAiN]

Uhhh based?

[@DavidNitzscheBell]

2:07 You said it correctly! Well done, Kevin!

[@ze_chooch]

Creating custom focuses is a fantastic idea. Thank you!

[@VixieTSQ]

I generally group similar properties on one line such as height and width. I think it makes it easier to read for me

[@iankirkpatrick2022]

One thing I see a lot: Unnecessary absolute positioning... I see people using position absolute to do things that could have easily been done using margin/padding... Then they wonder why their site breaks on smaller screen sizes. This is especially true when they do it to put some graphic down "off to the side" outside of an element when they could have just wrapped the element and the graphic in a parent and used margin/padding.

[@pastorcastillo970]

Hello from Venezuela. You have Awesome channel. Would like some video dedicated to css effects for mobile. Thank you for being a teacher and sharing your knowledge...

[@wimverpoorten3386]

Great tips. I would really, really advice everyone who has difficulty with this to use both Sass and BEM, which makes avoiding most of these pitfalls way easier than basic CSS.

[@TheLollercaster]

first CSS mistake: I was like "oh nooo", then I realized I use SASS :D second CSS mistake: if someone is lazy to format it then just please use an extension (something like Beautify CSS). It was kind of painful to watch pressing space every single time haha 13:09 - guilty lol (but I only remove it when it comes to form buttons, even though I shouldn't really because of accessibility) and also good advice (focus + hover) 17:42 - also good to know

[@violet-trash]

I really hate how so many websites use slow transition durations. Yes, you're showing of the neat CSS trick you did, but it's making everything _feel_ sluggish even when it isn't!

[@Anakin1990Skywalker]

Great tips! Thank you Kevin for every thing you’re sharing. I’m a beginner front-end and I find these tips very useful. Cheers!

[@ashawesomeone]

12:15 actually I believe that's the wrong way because in future is you have to change one font weight, you have to remove it all and add it all back separately.

[@gkoymnbxykfb]

6:25 Turn on Word Wrap globally in VS Code, and you will never have to scroll sideways again. (But keep the lines short anyway, there are many good reasons)

[@kablamopow]

Thanks for the video, nice upload. Very clear and got all the points across well.

[@felipembraga]

Kevin, i met you in this week and i'm loving! Can you say in some video whats is the better font-size to text (like blog texts)

[@massimodambrogio]

I really love your channel. Straight, clear and rich of good valid content.

[@KevinPowell]

Thanks!

[@lenarnie2973]

thanks for giving new look to writing css

[@SergiuVacari]

Thank you, Kevin, especially for the :focus, really nice... I've noticed it before, didn't really know what's that, though it's kind of obvious, but you explained it well. Well done! Keep up the good work!

[@KevinPowell]

Thanks! Glad you liked it learned something along the way 😁

[@SergiuVacari]

@@KevinPowell oh yes. I've learned a lot from you.

[@silkeschumann7261]

3:06 is something I consider a bad habit, because it quickly results in inline styles type of markup, where the effort is on style and not on structure. The nav tag is not a style feature but a semantic and such an important tag to use. Using classes on everything blows up the markup unnecessarily and unless you have a site with nav tags that have a semantic styling with difference depending on page or section and a class becomes necessary, I wouldn't overindulge in classes. I even think that a corporation that ends up with an unmanageable bloated css code didn't do their managing and proper structure with a clear separation of structure, semantic and style in the first place. As to IDs and classes - if you adhere to structure and semantic first and the design principle form follows function what is an ID and what a class usually falls into place all by itself and the choice of IDs becomes self-explanatory.

[@KevinPowell]

I'm not a fan of atomic CSS, where each class is just one line of CSS, so you end up with 30 classes on an element, but giving everyhing a single class name, I think, is good practice, or two (say, .btn .btn-accent). As someone else pointed out, it's possible to have more than 1 nav on a page, for example.

[@silkeschumann7261]

@@KevinPowell When there is a second nav then there is structural and often a semantic reason and class or ID should reflect this. By putting structure and semantic before form, classes and button are self explanatory and only set when actually required. Stuffing the HTML with classes when you can just as well address the element comes close to inline style. mtc

[@dealloc]

@@silkeschumann7261 the whole idea with classes is exactly why you want to use them this way. they are meant to be composable, hence why you can have multiple classes for an element. i don't agree that your styling should know anything about how your document is structured, nor the schematics of it. it only makes the styling less reusable and harder to maintain in case you want to apply it to other structures. separating the concerns between the two makes it much easier to reason about and change, especially if you work on a website that is constantly changing (like e-commerce). my view of atomic css is that it makes it much easier to make conventions and make those conventions usable and accessible to non-code people. on top of this, it can make your css bundles much smaller by eliminating unused classes and only keep properties which are used. so rather than having twenty font-family properties, you can have just one. this makes serving the website faster for people with slow connections. of course, writing atomic classes inline in HTML will make the HTML very unreadable, so it's often best used with other tooling (e.g. Tailwind) to get the best of both worlds.

[@silkeschumann7261]

@@dealloc Keeping your CSS semantic and not style-organized doesn't mean you can't combine classes. I never had any trouble maintaining a site with semantic oriented CSS. Though it's been a while that I worked in the field. I stand by the benefits of well structured style guide that doesn't treat classes just as shortcut inline styles.

[@Shrinehi1]

Thanks! If found the discussion on focus styling helpful.

[@blonduose]

You are golden! NR 4 & 5 were especially useful. I think you can spot the "better" web developers also by how they keep and make their pages accessible, in my codecademy course there was nothing on accessibility and on freeCodeCamp there was a whole section. So I always know when someone pays special attention to that, that their content is good

[@MrW0rDs]

I actually like to have css inline on the stylesheet. I find it easier to have a look at multiple classes at one glance instead of scrolling up and down. Nicely separated with structured comments of course.

[@FrancisBoudreau]

Me too. With BEM and good naming of classes, you don't need to see every CSS declaration... the name of the class will tell you what it's supposed to do.

[@MrW0rDs]

@@FrancisBoudreau I'm glad I'm not alone, but I'm yet to find an editor that autoformats css in inline style. So until I figure this out I stick to standard css styles but I still prefer inline for quick navigation.

[@randy918]

Wow. Searchable CSS table of contents. Never thought that one up. What a great idea

[@formwebdesign7208]

The first CSS mistake you listed, "Complicated Selectors". This works fine if you are designing the site from scratch, but if you are customizing a CMS theme with custom CSS, the unfortunate part is sometimes you will have to be very specific and maybe using a complicated set of selectors to be able to target that element to customize it. I have found, at times, I had to enter all 7 selectors used by the CMS theme style sheet just to make the customization. What this says is how the site is configured using CSS in the first place. So if your site you are building is requiring complicated set of CSS selectors to make things work, then you need to review the element or elements involved to see if you can simplify it.

[@rumble1925]

At that point you just slap an !important on that sucker

[@wepped482]

I love when people try to make a spot the difference game with the focus state still tab-through-able..

[@daemonsilverstein8633]

Actually, checkboxes *can* be customized, using "-webkit-appearance: none; appearance: none; " then stylizing it in many ways (border, background, et cetera)

[@KevinPowell]

Good point, but don't put -webkit- in the front! I don't know if any current webkit browsers even need that anymore, and if you do use it, it'll only work in webkit browsers and nothing else. Won't work in IE at all no matter wahat... but if someone doesn't get the custom checkbox, it probably won't be the end of the world.

[@sebastianwei542]

Kevin: „Make your CSS readable“ Tailwind: „Hold my beer“

[@adamonjourney3726]

Helped a lot! Learned much! Thank you!