Doesn’t matter how many years I work with CSS, I will always confuse flex things like align-content and align-items, like inserting a USB cable wrongly, every single time. Oh and align vs justify.
CSS grid is incredible too. I can’t believe how spoiled we are now with amazing layout options.
I've been writing HTML since the mid-90s and have been a professional web developer for a decade. I frequently reference the flexbox[0] and grid guides[1] from CSS Tricks. I have both of the summary sheets printed out and sitting on my desk. They are invaluable resources.
It's so tempting to want to label them horizontal and vertical etc, but I have to work with Arabic which is all reversed, and then I'm setting up a test localization in Traditional Mongolian, and you realize why these things are named the way they are:
CSS actually already accounts for that with it's "inline" and "block" axes. Where inline is the axis along which text flows first (horizontal by default for latin text - although this can be overiden with the writing-mode property), and block is the other axis. Flexbox's main axis controlled by flex-direction is an extra abstraction on top of that.
I think they were trying to be generic over “flex-direction”, meaning that attributes like flex-align depends on the “direction” of the parent. It’s very rare that you change the direction and really benefit from that.
I don’t know if that’s the only reason, so I’m not gonna say it was a bad choice. But at least to me, I’m exactly like you in the sense that I can’t remember which one is which. I would have preferred either better naming that references the axis, or simply have the attributes be independent of the parent. Until then, I have to use a cheat sheet.
its multiple directions at play, since the "cardinal directions" of the parent aren't defined by flex-direction alone. If the writing-mode of a parent block formatting context is set to a vertical mode, then flexbox' "row" will run vertically - which is why flexbox directions are "row" and "column", and can only thought of as "vertical/horizontal" in "horizontal-tb" writing mode.
Further, there's no "bottom to top" mode for horizontal scripts, but vertical modes can have a block axis running either ltr or rtl, affecting the direction of the flex cross axis. Which likely leads to the necessity to also abstract "row-reverse" and "column-reverse" directions for the ordering of items.
now as for distribution of items on either axis (whichever direction it may have), referring rows/columns when might become misleading, and also having to address individual rows (align-content) complicates things. Finding another set of terms for flexbox alone might start to become messy, since display:grid and multicolumn layouts will also require these settings.
I don't know the actual origin of align & justify either, but I have the feeling coming up with better terms might not be that easy
For me it's the flex-basis, -grow, -shrink that I can never get my head around. But I don't need to worry about that very often (which I guess is why it never really sticks in my head).
The way to remember justify is that in flex-row, justify is along the horizontal axis. And, in word processors like msword, you can set the text to "justify" which gives you clean edges on each side. I don't know the history of the word `justify` in flexbox but I would imagine it came from here. So since you know how it works in flex-row, then you know it's primary axis in both.
For items vs content: You always have items no matter what. But you don't need to do anything to the entire content besides justify/align until you have multiple rows with flex-wrap. There's simply no effect that align-content could possibly have here. So items is for individual children, and content is for entire rows.
So tldr: Justify is like the "justify" option in word processors, and align is the opposite one; you always have items, but aligning the content won't change anything until you have 2 rows/cols.
Remember these 2 things and you probably won't forget which is which ever again.
(That said, I do often forget if flex starts out row or column, but that's relatively unimportant to know, because the way I get around this is by always adding the direction when I say "display:flex".)
As an aside, I've learned so many things via games like this. Including vim (via https://vim-adventures.com/), which I now basically can't live without.
Games seem to be a great way to learn CSS. I'm guessing because it has very natural learning path were you can solve increasingly hard problems that all seem easy because of what you've already learned.
I think you need to learn by heart what each of the 5 position values means. After that, the tricky part is understanding what the width/height/top/bottom/left/right values are relative to i.e. the containing block and how that works: https://developer.mozilla.org/en-US/docs/Web/CSS/Containing_...
This is very useful. I always end up Googling vertical align for flexbox.
In a rush, what would help me refresh flexbox knowledge is being able to drag and drop the frog, snapped to a 3x3 grid, and get the flexbox CSS code as output.
Still a very thoughtful tutorial.
(EDIT: The reason I said the above is I've personally given up on keeping up with new CSS stuff. Having written CSS off and on since IE7 days, basically I have no energy to keep css tricks in memory, having lived through hand coding vendor prefix flags and whatever the new Chrome Canary is thrusting down the pipe)
No tricks anymore, not much to keep up, flexbox and grid are the end-game. And for most UI cases flexbox is all you need, it's basically stack/group (or vbox/hbox), so you can arrange items vertically or horizontally. Learn flexbox, it's the most useful thing for layouts that's come to css, and it's really simple, there are options for spacing (gap), justify and align, that's pretty much 99% of cases right there.
tbh I'm glad, not sure about patching in an extra magic keyword with it's own set of new properties to achieve one specific layout pattern popularized by a jQuery lib in css grid module.
It would have been much cleaner to add "auto-span" utility to grid-column and grid-row that allow to define "overflow snapping" if items are larger than template definitions, with an option for grid-auto-flow to affect packing logic
This draft feels like it's solving a single use case by stacking presets over the grid api instead of exposing tools to achieve that use case
Nesting of flexboxes can be tricky though – especially when you have elements that fill “the rest of the width/height”.
I’ve found that grids are a little easier to maintain a flat hierarchy and avoid complexity, but the downside is it also doesn’t modularize that well – you need to compose all the cells together, some of which probably should belong in a child “component”.
Today I learned about the order attribute, which would have come in handy this year.
Due to the magic of working primarily with perfectly functional but older projects, I only recently got the chance to start using flexbox. I immediately loved it far more than the float/clearfix headache I was used to.
The only thing that trips me up is the difference in naming with justify-content and align-items. I feel should both be (justify|align)-(THE SAME THING).
edit: Just got to 21. Looks like my confusion is common enough that there's a level about it.
- Start with Flexbox. Flexboxes of flexboxes will solve almost everything that’s common, and be easier to reason through and maintain imo.
- If you’re doing something that appears tabular, use Grid. Flexbox will appear as though it’ll get you there, but the moment you start having cell contents that are highly variable in size your columns will start to get out of sync.
- The above is esp the case if you’re trying to do repeating sets of rows. Eg Row type A, row type B, A, B, etc. That’s a Grid problem.
But of course, the only way to get good mental models is by trying both approaches and seeing what the drawbacks are. Maybe try the Grid games that folks have linked in other comments?
- You can align things in 2D space, not just along a single axis (like flex). Great for the top level layout of a site/UI.
- You can have white space. I often create white space (empty grid cell) in my UI so I can add UI elements there if needed later on. Works well with elements that are conditionally rendered, as these will change flex layouts but elements assigned to a grid cell will not move.
Flexbox for most stuff, resort to grid only if flexbox can't solve your layout.
The way I see it, if there is horizontal or vertical stacking, it's flexbox. And since you can nest, it covers a wide ranged of typical layout patterns (boxes within boxes). One caveat, since flexbox only arranges vertically or horizontally, you have to insert container flex elements, which means it affects the markup, so you are a bit constrained if you want to make it really responsive and rearrange everything based on viewport size. Grid is more complex, and useful for fixed layouts when things have to align more. With sub-grid support it will be even more powerful.
I tend to default to grid, especially for the top level page layout. I did it easier to reason about how it's going to look by just configuring the container. Less styling has to be specified for the child elements, especially when defining named areas.
The yellow froggies end up separated by wrapping. Then it's just a matter of aligning them. The align-self and order attributes mentioned seem to be red herrings.
It’s fashionable to crap on tailwind in some css circles but nothing else has improved my CSS knowledge so quickly - it’s specifically when used with the tailwind plugin in vscode, it shows the underlying css in popups and it’s addictive to guess what the underlying css will be for a given utility class and then quickly check.
That said, flexbox froggy and the other grid garden game were fun. Also find myself regularly going for the css tricks reference page for both of these.
I actually frequently use the Tailwind docs (https://tailwindcss.com/docs/) to lookup CSS property names and what they do, especially with flexbox and grid, since I mostly learned them through Tailwind. It’s just a nicely organized quick reference with lots of examples.
Not using Tailwind as much these days (more inclined to CSS-in-JS solutions like Stitches, which unfortunately has been abandoned by the developers), but for prototyping it’s still amazing.
I've started my journey with CSS when Bootstrap was pretty much the only relevant CSS framework; and can confirm. There was no VS Code (Notepad++, anyone?), but Chrome Dev Tools were very useful when trying to understand what's actually going on and that + trying to "Inspect Element" random websites actually taught me CSS.
Fun fact: border-radius wasn't supported well until one year (2010) before Bootstrap (2011) was first released. You had to do rounded corners with some annoying background-image hacks.
In all my years I’ve never seen such a polarising technology as tailwind. It’s really weird the lengths people will go through to defend their method of outputting key/value pairs to move things around on a webpage.
https://cssgridgarden.com/ (basically Froggy for Grid)
https://cssbattle.dev/ (a platform for doing various challenges, huge community)
https://flukeout.github.io/ (learn about CSS selectors)
https://css-animations.io/ (practice CSS animations)