Been working in frontend development for 15 years (self taught). Never knew about collapsing margins and I want to cry over all the hours of frustration it could have saved me. Thanks for the hours you will save me in the future
A great way to think about collapsing margins is remembering the good old covid times... Back then we should keep a distance of 2m, so everyone walks around with a ""margin" of 2m. Once you approach someone you dont stop at 4m as the sum of your margins suggests. Instead you approach up to 2m. So your 2 margins of 2m each collapsed into each other... css margins work basically the same...
This is the first I've heard of collapsing margins. I think I've had to work around them before but didn't understand wtf was happening. Sometimes i try to add space and nothing happens, other times i try to add a little but get a lot. Your demo showed and explained both. It makes much more sense now!
Same! Never understood why a senior of mine kept using padding where margin clearly worked, so I changed it to margin and stuff started collapsing. Now I know this is a whole thing in CSS.
For those wondering why 'grey' is darker than 'darkgrey', the reasoning is that 'grey' was defined first in HTML to be 50% between black and white (fair enough), but then a bunch of colours from X11, a Unix window system, got pulled in, and there 'grey' is closer to around 75% of the way from black to white. Grey already existed at 50% and couldn't be changed, but darkgrey and lightgrey were pulled in from X11 where darkgrey is 66% and lightgrey is 83%, sensible values for a grey of 75%. If you want to abide by the X11 standards for named colours, you would instead choose 'darkgrey', 'silver', 'lightgrey' as your gradient instead, as HTML silver is very close to X11 grey. Unfortunately this is another case of 'weird CSS quirk that has to remain for backwards compatibility reasons'.
If you declare `display: flow-root` on an element it will prevent all descendant margins from collapsing outside of that element. There are times I find that more practical than declaring padding values.
@@7starsgeneral649He's talking about styling the element with outline rules. But that's not representative of the actual layout because space boxes are layered (margins -> outlines -> borders -> padding -> content) so it's more appropriate to use the browser DevTools to inspect these kinds of things visually. Plus it makes it more convenient since you don't have to clear all these styles after you're done.
Your explanation of parent vs child control for grid vs flexbox is a great way to think about which one to use, which has been a struggle for me. Thanks!
CSS positioning is one of the most frustrating things I've had to deal with in UI development. Although I'm doing better now as I learn more I still get stuck sometimes. Thanks, Kevin, for helping to clear up some of the confusion!
Regarding the position containing block; that's one of the first things I mention to people when I teach colleagues CSS, since as you said, it's something that's not too much talked about. You may stumble upon or you never find it. Back then, for me it was a game changer to finally understand it.
I used to make my class recite "An absolutely positioned element is positioned relative to its nearest positioned ancestor" until they could recite it like a calming mantra when their layouts broke.
#1 mistake: using tailwind Jokes aside, one I've noticed a lot of JR devs doing often is overusing "height" and "width". 90% of the time, you don't want to specifically set the height or width of an element.
I’m colorblind, so I always have a hard time finding good colors. I use TailwindCSS’ color scheme as it’s a really great way to find the right colors and shades. I even use them when I’m working on projects without Tailwind
You stated that we should use classes over ids for styles, which I agree with only one exception. Which is using ids just for the main content grouping containers of you website e.g. site-header, site-menu, site-content, site-footer. As these containers with these ids form the main layout and grouping of content for the pages of your site. Thus, you would mostly apply layout styles to them. Which means for these styles you would want a high specificity and would not want them to be overwritten, which is more likely if they were a class. Then for any other non layout styles like your example with the background color red which is applied to a header and used in other areas of your site you could extract into a class, as you demonstrated and also apply that with a class attribute to any of the main content grouping containers I previously mentioned.
I never knew the name for the collapsing margins phenomena but I have had to work around it many times to the point my usual way to diagnose thes things is to put a nasty red background, with some other contrast border around it and then adjust margin or padding etc. Sometimes the collapsing is helpful though but I think one thing you can watch out for, is use classname and id in css so you aren't putting layout for specific elements in more general ones.
You can also make the counter arguement to your very last tip about specificity and whether or not you specify the #ID or a class. The key takeaway really is knowing what you want to do and apply the correct one. It might be the case that you want to style exactly that element and never any other element in which case using # would be exactly what you should be using.
One thing that ID's are very useful for that you didn't mention is things that are attached to the viewport. Like a fixed sidebar or an -ish content element that fills the viewport with its own overflow scrollbar. Communicating that you aren't allowed to have more than one the things on a page can be a feature not a bug. IMO Styling those to achieve your app's layout is good. The colors and fonts can be styled with classes. You use both id's and classes on the element.
I use an id on elements that are going to be used only once on a page. Examples of this are: navigation, sidebar, footer, header, and maybe the main content section if it has the need for a container around the entire thing. You can name your grid areas using an id and then only use the grid-area property to define where you want your layout, this should be something that you don’t change frequently and will lead to easier understanding of the page, but not only that, you can only use a name for a grid area only once if you don’t want overlapping elements. But my biggest advice for using an id is to only use the id for your selector and if you have the need to adjust the style of an element that is a child, do so with the fewest properties. Here is an example, if you have a navigation section that has different color scheme, then I would only change the color and leave the other properties alone to pick up styles from any other changes you make later on. You will start off in CSS putting more properties into each selector than necessary, but eventually you’ll see that defining the smallest number of them per selector and then using classes for the majority of styling will give you the best flexibility in your design, especially when you go back to update the page.
For the elements examples you gave, why not just use the right html tag? Like footer, header, nav, aside and main. That way you just call the tag without increasing specificity with ids.
@@DrakkariusUsing an id will give a clear indication that something should only be used once, where it is possible that someone will go back and use a tag again. One example, if a page loads content from another website, that would break everything, but using ids would protect against the page from breaking. I would always encourage the use of the proper tags and yes, it is fine to just use those, but you will also not give an indication that adding properties to this selector should be minimal as well, as most people don’t have a fear of using a tag selector as they do with ids. TLDR: Use an id when you want to signal to other developers that a property is to be used for a specific case.
@@jfftck thank for the explanation. So in an ideal world the correct use of tags would suffice but to make sure other devs understand the element is supposed to be use only once you use ids. I dont really have much experience, and im the only one working on the website of the company that i work for. Learnt something new today.
Might also be worth mentioning 'columns: var(--number-of-columns)' for masonry layouts, since development on this feature doesn't seem to have gone anywhere. Funnily enough, even though I would consider this an outside-in approach, I do tend to combine it with flexbox and a direction of column rather than grid.
I recall a tweet from Steven Pemberton outlining that the original point of !important was to set font sizes for legalese reasons and it was never intended to be used for anything else. Although I definitely have used it to override inline styles a bunch of times.
Collapsing margins are weird 100%, but I think margin is way too often used anyway and the wrong decision when picking between margin and padding. I consider margin "dead space" and in most cases you get better away with padding. Plus, margin can't have background color, unlike padding can. Another big hit if you run into it and wonder why is it not going edge to edge.
Many problems that occur in CSS layouts are due to browsers vendors not providing a way to access font metadata so CSS can allow consistent spacing of text. There are work-around approaches but the margin collapse issues can break them, which force even more hackish work-around approaches. I wish everyone would focus on demanding features from the browser vendors and HTML/CSS/DOM protocols instead of doubling down on bad frameworks or unnecessarily bloated HTML. 😥
It's probably a dumb question but... can't we just set * {margin: 0; box-sizing: border-box} in our css to prevent browsers from adding random default margins around to mess up woth our code? I know this is not a solution for collapsing margins, but it still takes away a lot of unnecessary complications.
Hi, I encountered a strange behavior on Safari and Chrome in mobile sizes. While layout works wonderfully on these browsers in desktop sizes, when you switch to mobile sizes, the html element fails to fit and/or fixed to the bottom of the viewport. I had to use bottom: 0; for html element in case of mobile sizes. Am I missing something here?
14:52 saying you "can't really do that with flexbox", eh? width:33% should do it. use a :where selector to avoid specificity issues when targeting the children, and you get exactly what that grid does, just with more flexibility. (like being able to add a class to override the size of certain children) I will openly admit, I just don't like grid - it's too complex and the syntax is too difficult to remember. I love flex - it's delightfully simple and easy to remember, and I almost never run into anything I can't do with flex. I would like to see a video on flex vs grid, showing off things only grid can do. So far, I've never been sold. The typical grid uses I've seen either would be simpler as flex, or they end up creating limitations and have to be ported to flex anyway.
Thank you for the great video. I struggle with positioning when I want to overlay content on top of each other. The designs are never responsive. Can I overlay content with z-index using grid or flexbox ? Or is there a way to make my code responsive while using positioning without having to use a million breakpoints?
I follow you since years and I learn a lot in css because of you. But there is one point I fell behind and it is not about css, but html becoming so semantic and I'm a little lost about the main tag the article tag, the section tag etc... do somebody know a up to date article or video course, so I can refresh my mind. Thanks
I think it's probably more likely that you have but didn't realise it. It is less common nowadays though since flexbox and grid are so pervasive, pure block layouts are rarer.
I am currently working for a customer on a azure extension, the previous team used fluent ui (microsoft) and griffel, basically styling with typescript. Which is something I never did before. Do you have a video where you try that out and test its limitations? especially griffel
Only disagree with the last one for the reasons you stated. Also i think it would promote waste code; blocks of code that may be left behind doing nothing because it was already overridden later on and the visual need was already met. Not saying one should always use IDs as selectors but if it being annoying is what they get from that, i think it would promote better practices overall, regardless of which they decide to use.
I love when ids exist on the elements, but are not styled using them. I use a plugin to inject custom styles and fighting with whatever the devs did (or worse, whatever the whacky WordPress plugin did) is a pain while I am grumbling about nobody implementing dark mode on their modern websites.
sometimes a mistake can be a good thing, happy mistakes are cool.... in all the years ive been tinkering with css i still dont understand how to use grid properly
Other "beginner mistakes" "pros" still make: Using tailwind - or using class names that describe what they do/how they make something look like, not what they are for: ".color-red" is total bs, as is ".mb30". Something like ".nav_left" will bite you when the customer wants the menu to be at the top or somewhere else. Now you have a class name that neither reflects what it does/how it looks like NOR what it is for. Sure, changing things like this is not that difficult when the project isn't that big, but as soon as you start working on bigger projects, you'd have to get rid of those habits or you will have a hard time. Use "color-main" and whenever the customer decides to make the color a bit different (and the logo a little bit bigger), you only need to change one line in the CSS file, not hundreds of occurances in the HTML. Also do not overdefine selectors: Using "ul li" or "ul > li" is mostly already too much, except you want to explicitely style the list items inside an unordered list. But having ".nav ul li" can be shortened to ".nav li" since you will most likely do not have two different types of lists inside the navigation. This rule especially applies to element selectors (table tr td is a big no no) but if you look at your (old) stylesheets, you will most likely find selectors that can be simplified. Which leads to the next point: Never use !important: If you need to, you haven't understood selectors and their weight, or have used way too specific selectors somewhere else. As soon as you use one !important, you will have to use it again and again, even though regular selectors would be enough. Style everything to a decent looking default and only use specific classes where required. For example: always style your h1-h6 using the element selectors and only add classes to those elements where the style diverges from the default. There is absolutely no need for every h1 to have a class "headline" or for h2s to have "subheadline" or whatever. And please never do something like or i will find you and I will make you create newsletter templates that need to work in Outlook. Never just put a few (pre-defined from your framework?) breakpoints in your code and think you're done. Making something responsive while keeping the interface usable AND visually appealing isn't something that can be done in a few lines of code. And please don't just use the browser-presets for display sizes of (a few) mobile devices. Not only do an unknown amount of possible screens sizes in between those exist, you can also never be sure that someone with a 1920x1080 resolution will have their browser maximized and not have installed three toolbars that will reduce the available viewport size. Unreachable content is bad, mhkay?
7:46 What sane person would ever use position: absolute for a side by side layout? That's what the float and display properties and clear fixes were for. Named colors are actually good, you just need suffixes. Instead of grey use grey-lt as a starting point and work to md, dk etc. Gives you more room to expand while still using a pattern that's easy to read.
Sometimes I mess up a lot while writing CSS,,, I get confused between modern css and old css !! Because I learned CSS from an old book from 2018 .When I finally stipple and see that there is a more modern and short compact version of that CSS, I'm disappointed with myself. How do I come back from this and know that the CSS I wrote already has a short and compact version? It is not always known by online search whether there is a separate website or place for this.
You could ask ai like chatgpt, to tell you if there are more modern ways to do something. Unless you don't like using exorbitant amounts of water for every prompt. I'm not sure if there's any other way of doing this, but you might want to watch a modern course on CSS ir read a modern book. It shouldn't take too long because you already know more than the basics
2018 is not old, it is a blink of eye in the css timeline, basically not much changed. Also, nothing changes really, just more is added, so everything you learned is still useful, you just have a few more new things waiting to be discovered, that is all.
You can use Tailwind CSS documentation, even when im not using tailwind their documentation is so good that i use the search to look what i want and then scroll to where the css code is. From what I have seen most of the stuff is always using the most updated css code. Plus they also provide visuals of how the things are supposed to look.
The coding aproach and system we are using to manipulate the DOM reminds me of a puppeteer using strings to control and move a marionette. Right now this is the only way but there has to be a better way.
Oh, apropos! Kevin, please talk about the nonsense in Facebook's and Twitter's source code. They use CSS to compress inline formatting. 🤦♂ (Twitter has even a JS-based hover… 🤦♂ 🤦♂ 🤦♂ )
I am sorry. But i really love to use id's when i know that i have only one of that element. It helps my brain organize things better. I also know the thing about grid and flexbox. I learned flexbox and found it confortable and easy. I will learn also grid in the future
Still is better to just use a class instead of id even if for only one element. Keeping the specificity low so you dont need to resort in the future to keep stacking selector or using !important.
18:14 Not gonna lie, I have some nightmares with specifity and using ID‘s in CSS. Ever seen something like body #wrapper #main .image-text-box[data-attr-anchor="newsletter"] img.image-text-box-image {} What are your worst declarations you‘ve ever seen?
div[style*="color:red"] {color:blue !important;} I'm serious. I wrote that (actually it was a worse equivalent, relating to table cell styling) to override damned third-party CSS coming in from a busted framework. I hurt my soul.
That looks like the type of thing that gets generated by things like Dreamweaver, where it automatically makes a selector based on whatever it's nested inside, and if people don't know any better, they stick with it. At least, I hope that's what it would be from :D
Plenty of bad WordPress themes and plugins use ridiculous selectors. The worst are ones that use the #top anchor as an overriding ID selector, then 6 or 7 ancestor classes and then a couple of utility classes just to select something and give it a style that has nothing to do with the utility classes. One way to solve this issue - say to the client "Oh, you want to use the 'Enfold' theme, that'll be an extra $50 per hour, on top of my usual rate. Eases that soul crushing feeling you get when trying to customize that theme (or the 100 other premium themes that do stuff like that).
Please use named colors. You can look at what they look like when choosing them. Some "unexpectedness" between what you think something could be named in comparison to another color, vs what it actually looks like, does not mean that if you find a color you want you can't use it.
The more I understand about how CSS works, the more I hate it and dread needing to use it in any of my projects. If I had to choose between learning to make all of my own tools for every project I make or use CSS to the same level as front end designers, I'd choose to write every project in brainfuk on my own OS written in brainfuk using only Wingdings font.
@@fabsn182 For an attribute selector that targets an id? I mean, sure, if the situation called for it, but there's not going to be more than one of those id's :).
Kevin is the reason the internet and UA-cam is so great. Wish there more people like him.
Kevin is great, UA-cam not so much. YT tries to take down all the videos and comments that tell the -|-ruth about certain political topics.
Been working in frontend development for 15 years (self taught). Never knew about collapsing margins and I want to cry over all the hours of frustration it could have saved me.
Thanks for the hours you will save me in the future
I was just about to say the same thing! I've got 7 years in, and not once heard of this!
A great way to think about collapsing margins is remembering the good old covid times... Back then we should keep a distance of 2m, so everyone walks around with a ""margin" of 2m. Once you approach someone you dont stop at 4m as the sum of your margins suggests. Instead you approach up to 2m. So your 2 margins of 2m each collapsed into each other... css margins work basically the same...
Reading the first 3 words and just looking at what you wrote it sounds complex
This is the first I've heard of collapsing margins. I think I've had to work around them before but didn't understand wtf was happening. Sometimes i try to add space and nothing happens, other times i try to add a little but get a lot. Your demo showed and explained both. It makes much more sense now!
Same! Never understood why a senior of mine kept using padding where margin clearly worked, so I changed it to margin and stuff started collapsing. Now I know this is a whole thing in CSS.
For those wondering why 'grey' is darker than 'darkgrey', the reasoning is that 'grey' was defined first in HTML to be 50% between black and white (fair enough), but then a bunch of colours from X11, a Unix window system, got pulled in, and there 'grey' is closer to around 75% of the way from black to white. Grey already existed at 50% and couldn't be changed, but darkgrey and lightgrey were pulled in from X11 where darkgrey is 66% and lightgrey is 83%, sensible values for a grey of 75%.
If you want to abide by the X11 standards for named colours, you would instead choose 'darkgrey', 'silver', 'lightgrey' as your gradient instead, as HTML silver is very close to X11 grey. Unfortunately this is another case of 'weird CSS quirk that has to remain for backwards compatibility reasons'.
Grey being darker then light grey makes complete and absolute logical sense. There is also dark grey... which is darker then grey.
Oh man I ran into the grey one the other day, to the point I actually created variables to make the names make more sense for my styling!
Kevin, I'm a professional developer from Brazil and I've been watching you for some time. I should tell you that your content is amazing!
I really love him, I will always follow him for the betterment of my life.
In our team we have a rule, do not style with IDs. Style with classes. We have IDs only for javascript etc.
IDs are also good for anchors
If you declare `display: flow-root` on an element it will prevent all descendant margins from collapsing outside of that element. There are times I find that more practical than declaring padding values.
I'm gonna try this out!
When I first learned CSS I could never get my stuff where I wanted. Using outlines to figure out what's relative to what was an absolute game changer.
What do you mean outline??
outline works like border, but doesn't take up any space in the layout.
@@7starsgeneral649He's talking about styling the element with outline rules. But that's not representative of the actual layout because space boxes are layered (margins -> outlines -> borders -> padding -> content) so it's more appropriate to use the browser DevTools to inspect these kinds of things visually. Plus it makes it more convenient since you don't have to clear all these styles after you're done.
Your explanation of parent vs child control for grid vs flexbox is a great way to think about which one to use, which has been a struggle for me. Thanks!
CSS positioning is one of the most frustrating things I've had to deal with in UI development. Although I'm doing better now as I learn more I still get stuck sometimes. Thanks, Kevin, for helping to clear up some of the confusion!
Regarding the position containing block; that's one of the first things I mention to people when I teach colleagues CSS, since as you said, it's something that's not too much talked about. You may stumble upon or you never find it. Back then, for me it was a game changer to finally understand it.
I used to make my class recite "An absolutely positioned element is positioned relative to its nearest positioned ancestor" until they could recite it like a calming mantra when their layouts broke.
#1 mistake: using tailwind
Jokes aside, one I've noticed a lot of JR devs doing often is overusing "height" and "width". 90% of the time, you don't want to specifically set the height or width of an element.
I’m colorblind, so I always have a hard time finding good colors. I use TailwindCSS’ color scheme as it’s a really great way to find the right colors and shades. I even use them when I’m working on projects without Tailwind
position absolute is great for fixed size containers, eg. preview images inside of which you want a few buttons to pop up.
You stated that we should use classes over ids for styles, which I agree with only one exception. Which is using ids just for the main content grouping containers of you website e.g. site-header, site-menu, site-content, site-footer. As these containers with these ids form the main layout and grouping of content for the pages of your site. Thus, you would mostly apply layout styles to them. Which means for these styles you would want a high specificity and would not want them to be overwritten, which is more likely if they were a class. Then for any other non layout styles like your example with the background color red which is applied to a header and used in other areas of your site you could extract into a class, as you demonstrated and also apply that with a class attribute to any of the main content grouping containers I previously mentioned.
I never knew the name for the collapsing margins phenomena but I have had to work around it many times to the point my usual way to diagnose thes things is to put a nasty red background, with some other contrast border around it and then adjust margin or padding etc.
Sometimes the collapsing is helpful though but I think one thing you can watch out for, is use classname and id in css so you aren't putting layout for specific elements in more general ones.
You can also make the counter arguement to your very last tip about specificity and whether or not you specify the #ID or a class. The key takeaway really is knowing what you want to do and apply the correct one. It might be the case that you want to style exactly that element and never any other element in which case using # would be exactly what you should be using.
Didn't know about those mistakes. Now i will introduce them to my codebase. Thanks!
One thing that ID's are very useful for that you didn't mention is things that are attached to the viewport. Like a fixed sidebar or an -ish content element that fills the viewport with its own overflow scrollbar. Communicating that you aren't allowed to have more than one the things on a page can be a feature not a bug.
IMO Styling those to achieve your app's layout is good. The colors and fonts can be styled with classes. You use both id's and classes on the element.
I use an id on elements that are going to be used only once on a page. Examples of this are: navigation, sidebar, footer, header, and maybe the main content section if it has the need for a container around the entire thing. You can name your grid areas using an id and then only use the grid-area property to define where you want your layout, this should be something that you don’t change frequently and will lead to easier understanding of the page, but not only that, you can only use a name for a grid area only once if you don’t want overlapping elements.
But my biggest advice for using an id is to only use the id for your selector and if you have the need to adjust the style of an element that is a child, do so with the fewest properties. Here is an example, if you have a navigation section that has different color scheme, then I would only change the color and leave the other properties alone to pick up styles from any other changes you make later on.
You will start off in CSS putting more properties into each selector than necessary, but eventually you’ll see that defining the smallest number of them per selector and then using classes for the majority of styling will give you the best flexibility in your design, especially when you go back to update the page.
For the elements examples you gave, why not just use the right html tag? Like footer, header, nav, aside and main. That way you just call the tag without increasing specificity with ids.
@@DrakkariusUsing an id will give a clear indication that something should only be used once, where it is possible that someone will go back and use a tag again. One example, if a page loads content from another website, that would break everything, but using ids would protect against the page from breaking.
I would always encourage the use of the proper tags and yes, it is fine to just use those, but you will also not give an indication that adding properties to this selector should be minimal as well, as most people don’t have a fear of using a tag selector as they do with ids.
TLDR: Use an id when you want to signal to other developers that a property is to be used for a specific case.
@@jfftck thank for the explanation. So in an ideal world the correct use of tags would suffice but to make sure other devs understand the element is supposed to be use only once you use ids. I dont really have much experience, and im the only one working on the website of the company that i work for. Learnt something new today.
Kevin, after I found your channel, I've been learning new thing every video!
Thank you for all knowlegde shared.
You're the best!
Might also be worth mentioning 'columns: var(--number-of-columns)' for masonry layouts, since development on this feature doesn't seem to have gone anywhere.
Funnily enough, even though I would consider this an outside-in approach, I do tend to combine it with flexbox and a direction of column rather than grid.
I knew all of this but i really enjoy the way you are explaining these advices and good practices
it took me a whole year to realise that you say front end friends
🤯omg I thought he was saying "My Friend and friends" and it really really irritated me. Now I feel like a fool! Thank you for clarifying!
@@TravisHi_YT no problem my front end friend glad i helped
@@TravisHi_YT me too 😂😂😂
I recall a tweet from Steven Pemberton outlining that the original point of !important was to set font sizes for legalese reasons and it was never intended to be used for anything else. Although I definitely have used it to override inline styles a bunch of times.
i didn't know about outline and it is sooo useful.. thanks.
Collapsing margins are weird 100%, but I think margin is way too often used anyway and the wrong decision when picking between margin and padding. I consider margin "dead space" and in most cases you get better away with padding. Plus, margin can't have background color, unlike padding can. Another big hit if you run into it and wonder why is it not going edge to edge.
Many problems that occur in CSS layouts are due to browsers vendors not providing a way to access font metadata so CSS can allow consistent spacing of text. There are work-around approaches but the margin collapse issues can break them, which force even more hackish work-around approaches. I wish everyone would focus on demanding features from the browser vendors and HTML/CSS/DOM protocols instead of doubling down on bad frameworks or unnecessarily bloated HTML. 😥
long time riddle got answered today. Thanky you Kevin
For collapsing margin fix, could padding-block be used instead of padding-top and padding-botton?
Instead of using #someid use [id=someid] now you are targeting the same element but with the specificity of an attribute selector (same as classes)
Your videos are so helpful!! Thank you!
Thanks!
Thank you so much!
when someone says ancestors in css I zone out. LOL. Love the vid. I have run into may of these
It's probably a dumb question but... can't we just set * {margin: 0; box-sizing: border-box} in our css to prevent browsers from adding random default margins around to mess up woth our code? I know this is not a solution for collapsing margins, but it still takes away a lot of unnecessary complications.
Hi,
I encountered a strange behavior on Safari and Chrome in mobile sizes.
While layout works wonderfully on these browsers in desktop sizes, when you switch to mobile sizes, the html element fails to fit and/or fixed to the bottom of the viewport.
I had to use bottom: 0; for html element in case of mobile sizes.
Am I missing something here?
14:52 saying you "can't really do that with flexbox", eh? width:33% should do it. use a :where selector to avoid specificity issues when targeting the children, and you get exactly what that grid does, just with more flexibility. (like being able to add a class to override the size of certain children)
I will openly admit, I just don't like grid - it's too complex and the syntax is too difficult to remember. I love flex - it's delightfully simple and easy to remember, and I almost never run into anything I can't do with flex.
I would like to see a video on flex vs grid, showing off things only grid can do. So far, I've never been sold. The typical grid uses I've seen either would be simpler as flex, or they end up creating limitations and have to be ported to flex anyway.
To give an element its own margin territory, put an outline 1px transparent on it.
Thank you for the great video. I struggle with positioning when I want to overlay content on top of each other. The designs are never responsive. Can I overlay content with z-index using grid or flexbox ? Or is there a way to make my code responsive while using positioning without having to use a million breakpoints?
Thanks Kevin.
0:10 Link that video in the description.
Thought I had! Added it now :) - ua-cam.com/video/GWkMYvoCXyQ/v-deo.html
I follow you since years and I learn a lot in css because of you. But there is one point I fell behind and it is not about css, but html becoming so semantic and I'm a little lost about the main tag the article tag, the section tag etc... do somebody know a up to date article or video course, so I can refresh my mind. Thanks
The MDN documentation explains them well.
I've never had to deal with collapsing margins.
Same. Not once.
I think it's probably more likely that you have but didn't realise it.
It is less common nowadays though since flexbox and grid are so pervasive, pure block layouts are rarer.
When is your book coming out Kevin???
I am currently working for a customer on a azure extension, the previous team used fluent ui (microsoft) and griffel, basically styling with typescript. Which is something I never did before. Do you have a video where you try that out and test its limitations? especially griffel
I don't, sorry!
Only disagree with the last one for the reasons you stated. Also i think it would promote waste code; blocks of code that may be left behind doing nothing because it was already overridden later on and the visual need was already met. Not saying one should always use IDs as selectors but if it being annoying is what they get from that, i think it would promote better practices overall, regardless of which they decide to use.
I love when ids exist on the elements, but are not styled using them. I use a plugin to inject custom styles and fighting with whatever the devs did (or worse, whatever the whacky WordPress plugin did) is a pain while I am grumbling about nobody implementing dark mode on their modern websites.
sometimes a mistake can be a good thing, happy mistakes are cool.... in all the years ive been tinkering with css i still dont understand how to use grid properly
Ayo 12:50 that last word
Other "beginner mistakes" "pros" still make:
Using tailwind - or using class names that describe what they do/how they make something look like, not what they are for: ".color-red" is total bs, as is ".mb30".
Something like ".nav_left" will bite you when the customer wants the menu to be at the top or somewhere else. Now you have a class name that neither reflects what it does/how it looks like NOR what it is for. Sure, changing things like this is not that difficult when the project isn't that big, but as soon as you start working on bigger projects, you'd have to get rid of those habits or you will have a hard time.
Use "color-main" and whenever the customer decides to make the color a bit different (and the logo a little bit bigger), you only need to change one line in the CSS file, not hundreds of occurances in the HTML.
Also do not overdefine selectors: Using "ul li" or "ul > li" is mostly already too much, except you want to explicitely style the list items inside an unordered list. But having ".nav ul li" can be shortened to ".nav li" since you will most likely do not have two different types of lists inside the navigation. This rule especially applies to element selectors (table tr td is a big no no) but if you look at your (old) stylesheets, you will most likely find selectors that can be simplified. Which leads to the next point:
Never use !important: If you need to, you haven't understood selectors and their weight, or have used way too specific selectors somewhere else. As soon as you use one !important, you will have to use it again and again, even though regular selectors would be enough.
Style everything to a decent looking default and only use specific classes where required. For example: always style your h1-h6 using the element selectors and only add classes to those elements where the style diverges from the default. There is absolutely no need for every h1 to have a class "headline" or for h2s to have "subheadline" or whatever. And please never do something like or i will find you and I will make you create newsletter templates that need to work in Outlook.
Never just put a few (pre-defined from your framework?) breakpoints in your code and think you're done. Making something responsive while keeping the interface usable AND visually appealing isn't something that can be done in a few lines of code. And please don't just use the browser-presets for display sizes of (a few) mobile devices. Not only do an unknown amount of possible screens sizes in between those exist, you can also never be sure that someone with a 1920x1080 resolution will have their browser maximized and not have installed three toolbars that will reduce the available viewport size. Unreachable content is bad, mhkay?
7:46 What sane person would ever use position: absolute for a side by side layout? That's what the float and display properties and clear fixes were for.
Named colors are actually good, you just need suffixes. Instead of grey use grey-lt as a starting point and work to md, dk etc. Gives you more room to expand while still using a pattern that's easy to read.
Learning = (mistakes + retest) + Time
i think the only written colors i ever use in css , sometimes are white and black.
Theo (t3) has mentioned that he hates margin. But I've not heard his explanation of it.
stripe dropdown tutorial pleaseeeeee
Another CSS gotcha: using a transform and then trying to use a position of fixed or sticky, since you changed the fixed positioning containing block
Glad to see that I'm not a beginner now 😅
Well, the id styles have bitten me a couple of times. We have an old codebase where id's were used too much for css selectors.
Great!
Sometimes I mess up a lot while writing CSS,,, I get confused between modern css and old css
!! Because I learned CSS from an old book from 2018
.When I finally stipple and see that there is a more modern and short compact version of that CSS, I'm disappointed with myself.
How do I come back from this and know that the CSS I wrote already has a short and compact version?
It is not always known by online search whether there is a separate website or place for this.
You could ask ai like chatgpt, to tell you if there are more modern ways to do something. Unless you don't like using exorbitant amounts of water for every prompt.
I'm not sure if there's any other way of doing this, but you might want to watch a modern course on CSS ir read a modern book. It shouldn't take too long because you already know more than the basics
@@aqua-bery Thank You❤❤
@@toptravelingoffers7666no problem man ❤️
2018 is not old, it is a blink of eye in the css timeline, basically not much changed. Also, nothing changes really, just more is added, so everything you learned is still useful, you just have a few more new things waiting to be discovered, that is all.
You can use Tailwind CSS documentation, even when im not using tailwind their documentation is so good that i use the search to look what i want and then scroll to where the css code is. From what I have seen most of the stuff is always using the most updated css code. Plus they also provide visuals of how the things are supposed to look.
huh, i've never actually considered positioning pseudo-elements relative to something other than its direct parent :o
The coding aproach and system we are using to manipulate the DOM reminds me of a puppeteer using strings to control and move a marionette. Right now this is the only way but there has to be a better way.
I exclusively use goldenrod
outline on css is like the console.log of javascript 😆
Me every couple minutes watching this .. "Ohhhh, thats why"
😂😂😂😂
I trying to do not use px in my layouts.
Oh, apropos! Kevin, please talk about the nonsense in Facebook's and Twitter's source code. They use CSS to compress inline formatting. 🤦♂ (Twitter has even a JS-based hover… 🤦♂ 🤦♂ 🤦♂ )
😮
I am sorry. But i really love to use id's when i know that i have only one of that element. It helps my brain organize things better. I also know the thing about grid and flexbox. I learned flexbox and found it confortable and easy. I will learn also grid in the future
Still is better to just use a class instead of id even if for only one element. Keeping the specificity low so you dont need to resort in the future to keep stacking selector or using !important.
18:14 Not gonna lie, I have some nightmares with specifity and using ID‘s in CSS.
Ever seen something like
body #wrapper #main .image-text-box[data-attr-anchor="newsletter"] img.image-text-box-image {}
What are your worst declarations you‘ve ever seen?
div[style*="color:red"] {color:blue !important;}
I'm serious. I wrote that (actually it was a worse equivalent, relating to table cell styling) to override damned third-party CSS coming in from a busted framework. I hurt my soul.
@@Killyspudful That is just… messed up. 🤮
Feel the pain.
That looks like the type of thing that gets generated by things like Dreamweaver, where it automatically makes a selector based on whatever it's nested inside, and if people don't know any better, they stick with it. At least, I hope that's what it would be from :D
@@KevinPowell Interesting guess. At least, that would’ve been just a software error…
Plenty of bad WordPress themes and plugins use ridiculous selectors. The worst are ones that use the #top anchor as an overriding ID selector, then 6 or 7 ancestor classes and then a couple of utility classes just to select something and give it a style that has nothing to do with the utility classes.
One way to solve this issue - say to the client "Oh, you want to use the 'Enfold' theme, that'll be an extra $50 per hour, on top of my usual rate. Eases that soul crushing feeling you get when trying to customize that theme (or the 100 other premium themes that do stuff like that).
I always teach my juniors, to use !important for defence not for offense
TEACH Everything You Know
I hope one day there will be CSS4 without default predefined styles on elements
NEVER MAKE ANY MISTAKES
You learn by making miscakes. :)_
Please use named colors. You can look at what they look like when choosing them. Some "unexpectedness" between what you think something could be named in comparison to another color, vs what it actually looks like, does not mean that if you find a color you want you can't use it.
The more I understand about how CSS works, the more I hate it and dread needing to use it in any of my projects. If I had to choose between learning to make all of my own tools for every project I make or use CSS to the same level as front end designers, I'd choose to write every project in brainfuk on my own OS written in brainfuk using only Wingdings font.
You remind me of a friend. His parents were greek and korean
Skill issues
Mans dont make mistakes I’m precise like maths.
Omg, why are people making so long intros
You speak fast I don't understand please talk slowly 💔💔
You could use the subtitles.
You can adjust the video playback speed
[id="immaRebel"] {
}
Add a "* > "before to make it a bit more specific.
@@fabsn182 For an attribute selector that targets an id? I mean, sure, if the situation called for it, but there's not going to be more than one of those id's :).
That moment when you actually read the lorem Ipsum text 🫣💦
(the flex or grid example)