In my opinion, flexbox is simple and makes a lot of sense. The problem is that its properties and values were named by a committee, so they aren't intuitive to anyone who wasn't involved in the long proceedings that led up to the spec being written. You try to remember which one is justify-content, which one is align-items, and so forth, and just give up and try everything until something seems to work.
My issue with flexbox is that I can't seem to memorize all the settings I need to get boxes within boxes and content to either fill a box or the box to surround the content.
This is particular important on an SPA where I want the boxes to fill the screen but never overflow it. I manage eventually. I need to put the totally intuitive (sarcasm) min-width: 0, here and there, and a few other things here and there and eventually I get it.
I feel like I should be able to make a few css classes to cover all of this but I have yet to figure it out for every case.
And then arguably every flexbox item ought to have min-width (and/or min-height) set to 0 because flexbox has a "min content sized" automatic minimum size built-in, which is rarely what you want. But if the content isn't overflowing or can be compressed in some way then you can get away without this.
One trick is if you open the chrome css inspector, you can click an icon next to the display: flex rule and see iconographic representation of the various flex box properties, and click them to set them. Every page essentially becomes a playground
There's a reason "naming things" is one of the great hard problems of programming. Especially when you have to name hundreds of things while developing i.e. a framework. Unless it's a solo pedantic developer creating the entire thing, inconsistencies will crop up, some names won't age well, some names don't quite capture the thing they are naming, etc.
I've deeply internalised that with flexbox, when using rows or columns that I need to visualise a row that holds multiple columns. And for a column, it's got multiple rows inside it. I literally have to visualise this in my head to remember the correct property.
Yes- justify-content: center will center items along the flex direction. For example, if your flex-direction is "row" then it will center your items in the middle of the row horizontally. align-items: center will center your items in the middle of the row vertically.
For example, justify-content: center and flex-direction: row centers items the same as align-items: center and flex-direction: column
One thing I don't like about flexbox is that align-items and justify-content switch what they do depending on the flex-direction.
justify-content: center; with flex-direction: row; makes the element horizontally centered. But justify-content: center with flex-direction: column; makes the element vertically centered.
There are myriad “how to flexbox” but never seen good “how to grid” in my experience - I despise grid and have never intuitively gotten the hang of it and 95% of the time flexbox will work better and is easier anyway
actually, that was the point of my comment a few parent generations up from linked: by hanging the train under the rail, you get perfect banking for basically free. Fair, entry and exit of turns has to be handled smoothly, but you get passive pendulum-based perfect bank angle at any speed from 0 to the maximum allowed for that radius.
And while it's certainly not cheap to be forced to build the track as "technically a bridge", the lack of serious span makes the cost not actually that bad relative to train track in locations where the curve radius and speeds tend to actually be used (valleys narrow enough to need quite tight radii, as well as near existing infrastructure: if you're already bridging, it's easy to design the pillar point foundations to not conflict with existing usage).
Oh, and about the coffee you mentioned: just like bus and subway, (open) drinks and food are not allowed anyways. In any case, the only substantial forces would be increased gravity, and whatever traction limited acceleration along the direction of travel (this would be with deliberate jerk minimization, though, as people would otherwise loose their footing, where the currently active limits for subways come from).
I've reached the other opinion. I learned flexbox better than most, but it never felt "intuitive" and it was hard to reason about complex flexbox layouts, especially responsive ones with multiple variations. Flexbox in general seems so hard to reason about that there are a million "helper" libraries for it, each with their own mini-DSLs on top of the flexbox DSL. Every junior developer's usage of flexbox starts to look like Tailwind, covered in these DSLs for DSLs, increasingly spread out across the elements of the DOM.
Whereas the "ASCII diagrams" of grid-template-areas, especially, I think is one of the most intuitive things in recent CSS. The majority of Grid CSS styles are generally centralized to your top-most containers outside `grid-area: some-area-name;` container classes (which may also have an align or justify) and the rare `display: contents;` (if you count that as Grid CSS) or `display: subgrid;`. Responsive layouts in CSS Grid is just changing the templates in your central containers based on your breakpoints.
I've gotten about to the point that even for 1D layouts I'm about to "forbid" junior developers from using flexbox to avoid its seemingly inevitable decline (in so many large apps I've seen) to inline-style soup via (usually ad hoc) Tailwind-like DSLs, because CSS Grid is easy enough and clean enough to use everywhere.
Grid is originally based on WPF XAML grid system, as it was the former IE team that contributed the original design, and I still can't grasp it fully, even though I spent 4 years doing WPF development.
wtf is an fr anyways? is a question I've never been able to retain the answer. there are many times where i've attempted to use grid layout, and then ultimately just switched back to neanderthal mode and used a table.
right, but if I want a simple 2 column row with the first field being narrow and the second field stretching to fill the width "1fr auto" doesn't work nor does "1fr 2fr"
If you want the second column to stretch, then the `fr` part is assigned to the second column. Mixing `fr` and `auto` doesn't really make sense. You can do it like this. https://codepen.io/tomtheisen/pen/emOeqPy
I also have issue of letting go and fully accepting the way of the flex. Instead of feeling comfortable just throwing elements inside the grid element, by brain needs each row to have a wrapper element like a tr and nested td instead of just tossing td elements in tbody (sticking to the table mentality). It took a minute for me to get that to click in my head for whatever reason
the any ratio I want is the point of the exercise. i don't know how many or what size. i want the first column to be just wide enough, and the second column to fill the space. what you suggested does not do that, but thanks for playing
Now that you've explained the rest of your requirements, I can see that `fr` is not suitable for the purpose. In the meantime you've gotten a better answer for the updated requirements, in particular min-content and max-content.
