This is a rather nice overview of why we should care. I admit, I’ve seen the draft specs on the w3c’s site forever, but never bothered to look because it didn’t sound useful to me - in particular, flexbox made more sense to me, perhaps because I’m an engineer and not a graphic designer.
Indeed, the grid itself is completely defined in pure CSS. This means that apart from the parent HTML element the grid is applied to, there’s no need to define any extra elements for the columns, rows, cells, or areas.
When you think of it, that’s a really interesting property. One aspect of it is that the visual order of elements on the page is decoupled from the order of elements in the markup. That’s important because on a page the source order is used for things like speech and tab navigation, so CSS Grids allow you to optimize the markup for accessibility without compromising your ability to manipulate the visual result. One other point is that the markup will be somewhat lighter and easier to understand, and therefore easier to maintain.
Flexbox does not share this property; each flex container is an HTML element. I recently saw a friend trying to do something that should have been fairly simple, producing either of two different layouts depending on screen size. I don’t have the picture handy… It was a natural idea that in an ideal world wouldn’t be almost impossible to implement, but I think really hard to describe with words alone, but I’ll try anyway. Skip the next paragraph if you want.
Flexbox couldn’t do that specific thing in the obvious way because the large-screen layout needed an extra <div> to hold the logo and navigation together in the sidebar, while the small-screen layout needed to show first the logo, then the body, then the navigation. There’s a property that can “flatten” the <div> so its contents are laid out individually, but the flexbox reordering primitives still look at the actual element structure. In the end, someone else came up with a solution that, I think, was based on having two copies of the logo and hiding the “wrong” one. A lot better than my attempt, which required statically knowing the logo height and putting padding in a few places - an approach which is fragile in several ways.
I am hopeful that we’ll start to see faster innovation in layout algorithms. The grid sounds fairly strict, but it is definitely the way any sort of news-like site thinks about things, and certainly moves things forward even though it wouldn’t make sense everywhere. Of course, historically, layout algorithm changes are very very difficult for browsers to implement, so the larger question is why this is and how it can be made easier. It’s clear that designers have a long, long wishlist.
I’d love to see wireframes of this layout to try my hand at a flexbox solution. I’ve been focused on JavaScript for a long time, but it would be nice to try flexing my CSS skills again. Pun intended. :p
I’m insufficiently in the design world, and don’t really have a wireframing tool that I know how to use. :) If you have the patience, I can put it in words…
The chunks were site logo, navigation links, copyright footer, and article body text.
On the desktop layout, logo and navigation are in a left-hand sidebar, with logo at the top and navigation stretched to fill all the remaining space. Body is in the “other column”, and footer is below both the sidebar and the body, stretching across everything. Everything is relative to the whole page, no viewport-based positioning or sizing, except probably the width of the sidebar, but don’t worry about that for the sake of the exercise.
On the mobile layout, there’s only one column. From top to bottom, the elements are logo, body, navigation, and footer. Navigation is below body because there’s a fair number of links; mobile Wikipedia does this, and it works well there.
The example was separating these cases using a media query based on something like a 400px threshold for viewport width, but that isn’t particularly essential; the point is only to try to do them with pure css.
I’m not sure whether the preferred document order for accessibility would be logo, body, navigation, footer, … the other thing that occurs to me is logo, navigation, body, footer. Feel free to pick one and try to make it happen, for bonus points.
This is a rather nice overview of why we should care. I admit, I’ve seen the draft specs on the w3c’s site forever, but never bothered to look because it didn’t sound useful to me - in particular, flexbox made more sense to me, perhaps because I’m an engineer and not a graphic designer.
Flexbox does not share this property; each flex container is an HTML element. I recently saw a friend trying to do something that should have been fairly simple, producing either of two different layouts depending on screen size. I don’t have the picture handy… It was a natural idea that in an ideal world wouldn’t be almost impossible to implement, but I think really hard to describe with words alone, but I’ll try anyway. Skip the next paragraph if you want.
Flexbox couldn’t do that specific thing in the obvious way because the large-screen layout needed an extra <div> to hold the logo and navigation together in the sidebar, while the small-screen layout needed to show first the logo, then the body, then the navigation. There’s a property that can “flatten” the <div> so its contents are laid out individually, but the flexbox reordering primitives still look at the actual element structure. In the end, someone else came up with a solution that, I think, was based on having two copies of the logo and hiding the “wrong” one. A lot better than my attempt, which required statically knowing the logo height and putting padding in a few places - an approach which is fragile in several ways.
I am hopeful that we’ll start to see faster innovation in layout algorithms. The grid sounds fairly strict, but it is definitely the way any sort of news-like site thinks about things, and certainly moves things forward even though it wouldn’t make sense everywhere. Of course, historically, layout algorithm changes are very very difficult for browsers to implement, so the larger question is why this is and how it can be made easier. It’s clear that designers have a long, long wishlist.
I’d love to see wireframes of this layout to try my hand at a flexbox solution. I’ve been focused on JavaScript for a long time, but it would be nice to try flexing my CSS skills again. Pun intended. :p
I’m insufficiently in the design world, and don’t really have a wireframing tool that I know how to use. :) If you have the patience, I can put it in words…
The chunks were site logo, navigation links, copyright footer, and article body text.
On the desktop layout, logo and navigation are in a left-hand sidebar, with logo at the top and navigation stretched to fill all the remaining space. Body is in the “other column”, and footer is below both the sidebar and the body, stretching across everything. Everything is relative to the whole page, no viewport-based positioning or sizing, except probably the width of the sidebar, but don’t worry about that for the sake of the exercise.
On the mobile layout, there’s only one column. From top to bottom, the elements are logo, body, navigation, and footer. Navigation is below body because there’s a fair number of links; mobile Wikipedia does this, and it works well there.
The example was separating these cases using a media query based on something like a 400px threshold for viewport width, but that isn’t particularly essential; the point is only to try to do them with pure css.
I’m not sure whether the preferred document order for accessibility would be logo, body, navigation, footer, … the other thing that occurs to me is logo, navigation, body, footer. Feel free to pick one and try to make it happen, for bonus points.
This is great! I have a strategy in mind for tackling it. Mind if I run a sketch or two by you to confirm I understand the layout? :-D
Feel free!
Cool! Do these match up with what you were describing?
Yes, that’s it exactly. … oh, although note that the logo of course retains its aspect ratio; you’ve drawn it much taller on the desktop version.
Ah, true. I’ll keep that in mind. This should be fun to play around with.
Feel free to share what you come up with. :)
Not sure if you’re still watching your replies in this thread, but this is what I came up with: https://github.com/joshuacc/flexbox-challenge
Would be interested in your thoughts, and whether I’m missing any additional constraints. I tried to annotate the interesting parts of the CSS.
But will it center?