reviewing flexbox with flexbox froggy

A coworker mentioned flexboxfroggy.com - it's a fun little review of flexbox's ordering and alignment, but maybe it's a bit limited: like, you don't see the underlying DOM the frogs represent, and really the power of flexbox is dealing gracefully for times when things need to jump to another line, the toy only offers a fixed-size pond. (Good to remember how flex-flow =  flex-direction + flex-wrap e.g. "row wrap" or "column-reverse nowrap")

Overall I think I get better results just going to CSS-tricks' guide to flexbox (not coincidentally the first google hit for flexbox) which has a lot of visual examples, usually that guides me to the property I'm looking for.

Grid Garden is similar to Flexbox Froggy but for grids.

It's easy for an old caveman ui guy to scoff a bit as I see CSS in browsers finally catching up to what was trivial to do in the Bad Old Tables For Layout Days. Though obviously it's an old and settled issue, still Eric Meyer put it pretty well in 2009:

All this is why the old “only use tables for layout” argument keeps coming up over and over: strip away the overheated rhetoric and obvious link-baiting, and you find the core of a real need. Because as powerful as CSS can be, table cells do certain things very easily that CSS makes very, very hard. Cells stretch vertically, keeping equal heights as a matter of their intrinsic nature. They stay out of each others’ way, while still being allowed to sit next to each other and use any sizing dimensions. They tie their layout to their parent elements, and vice versa.

Flexbox and Grid finally get back to some of that, but neither either completely, and you still gotta think of browser support and what not.

I always thought my lack of concern about using tables when expedient reflected by engineer side. A designer might think, this HTML Dom is the pure, canonical representation of information!  For developers used to working at layers lower than that front end, though - that's hardly ever the case, there's always a database and so the form of the DOM can be thought of as more transient. On the other hand, in a world ruled by Google scrapers and what not, in some ways the DOM is a bit canonical, in terms of it being the primary representation of your information that the outer world has access to (not to mention accessibility things like screenreaders, but doing a perfect or even completely adequate job there is beyond what most developers will put into it.)