11–20 of 32 posts
tl;dr: no CSS Grid is a two-dimensional layout mechanism. CSS Flexbox only handles a single dimension.
>it's not impossible to make multi-dimensional layouts in just Flexbox
Both are 2D layout mechanisms. You can make Grid act like Flexbox and vice-versa but they have different strengths, and are best used in tandem.
As a systems guy who only occasionally pokes his head into this web stuff: have we now completed the circle? For well over a decade I've seen generations of web hackers rail on about the evils of tables for layout. And now I look at this thing, and... it's a table. For layout. Oh sure, it's a table defined externally to the components. So your screen-reader enumeration of the document structure is unpolluted by the p…
Yes, that's very good.
You don't have source order independence with either.
.mytable{display:table}
.myrow{display:table-row}
.mycell{display:table-cell;vertical-align:middle;}
I still use: .mytable{display:table} .myrow{display:table-row} .mycell{display:table-cell;vertical-align:middle;} Simply because it's been the fastest and easiest way for me to vertically align stuff. Plus very backwards compatible. But I think I'm in the minority by not using the flexbox, etc.
Honestly, I almost just want simple tables back... It really feels like we've been working very hard to create more complex layouts with flex/grid systems, and while I can see the need in some cases... I can't help but feel a lot of the more trivial things would be better with simple table.
But for those of us building sites with complex layouts (and situations where we can't be entirely sure of the contents, e.g. using a CMS or static site generator), it's really amazing to finally have tools in CSS to actually do page layout.
Honestly, I almost just want simple tables back... It really feels like we've been working very hard to create more complex layouts with flex/grid systems, and while I can see the need in some cases... I can't help but feel a lot of the more trivial things would be better with simple table.
You can still use tables and CSS display:table (you should use the latter if the content is not actually tabular data so as not to make life annoying for people using screen readers). But for those of us building sites with complex layouts (and situations where we can't be entirely sure of the contents, e.g. using a CMS or static site generator), it's really amazing to finally have tools in CSS to actually do page la…
As a systems guy who only occasionally pokes his head into this web stuff: have we now completed the circle? For well over a decade I've seen generations of web hackers rail on about the evils of tables for layout. And now I look at this thing, and... it's a table. For layout. Oh sure, it's a table defined externally to the components. So your screen-reader enumeration of the document structure is unpolluted by the p…
The major advantage is its flexibility and ease in creating responsive layouts that look good at every screen size. One example is the minmax property: I want all these products in a grid, large enough to fit all their names. If you have the space, make the bestsellers larger and include the description. Oh, and they should really line up vertically and horizontally.
There's nothing that was completely impossible before, but there are a million hacks that we can finally discard, like all the shenanigans I've had to play with negative margins over the years.
As a systems guy who only occasionally pokes his head into this web stuff: have we now completed the circle? For well over a decade I've seen generations of web hackers rail on about the evils of tables for layout. And now I look at this thing, and... it's a table. For layout. Oh sure, it's a table defined externally to the components. So your screen-reader enumeration of the document structure is unpolluted by the p…
As a systems guy who only occasionally pokes his head into this web stuff: have we now completed the circle? For well over a decade I've seen generations of web hackers rail on about the evils of tables for layout. And now I look at this thing, and... it's a table. For layout. Oh sure, it's a table defined externally to the components. So your screen-reader enumeration of the document structure is unpolluted by the p…
>So your screen-reader enumeration of the document structure is unpolluted by the physical layout which is stored in a separate data structure in a separate language. And that's... good, I guess? Yes, that's very good. You don't have source order independence with either.
I'm seeing a worrying trend in front-end dev towards things that are "nicer" to "read" but more difficult to actually reason about. I don't understand what benefit we're gaining for removing the relationship between the order of the source code and the order things are rendered. All I see is a negative (it's more difficult to find the place to make an edit later on).
As the other guy said: "Meanwhile I see that native app development continues, as it has for like 30 years now, to shamelessly put UI components directly into hierarchies based on physical layout. And they still haven't tripped over the paradigm."