I was watching Rachel Andrew talk about CSS Grid Layout yesterday at An Event Apart. Grid is amazing and the day will soon come where it’s a dominant web layout tool of choice. That day isn’t here yet though, as no stable browser is shipping the latest version of the spec (it’s behind a flag at best).
The good news is that, as of just a few days ago, the spec is really stable and has entered “Candidate Recommendation” status. Since all browsers have been developing against the spec, it’s likely that widespread non-prefixed ready-to-go support will drop in all stable browsers fairly soon.
The bad news is that it will probably do-so without subgrid support, a point that Rachel underscored well in her talk.
Here’s some typical “page layout” HTML:
<body>
<header class="site-header"></header>
<main class="main-content"></main>
<aside class="sidebar"></aside>
<footer class="site-footer"></footer>
</body>All those major elements are a direct child of <body>, so <body> can be the grid and the four major elements are laid out on that grid. That’s kind like one of Rachel’s examples at GridByExample:
But…
… let’s say we wanted to build a grid from elements that weren’t necessarily at a completely flat HTML structure like we just saw.
<body>
<header class="site-header">
<h1>I want to use the grid.</h1>
<nav>Me too!</nav>
</header>
<main class="main-content">
<ul class="schedule">
<li>Me three!</li>
<li>Me four!</li>
</ul>
</main>
...
</body>We can nest grids, just like we can nest flexbox within a grid cell or flexbox within flexbox, but in the example above we cannot make those child elements participate on the same grid together.
You can see some of this at work in Jen Simmons Jazz Poster example. There are some elements you can see in the DOM there that it would be nice if they could all be positioned on the same grid, but are instead placed on different grids.
Subgridding might get a little tedious, since it’s kinda “subgrids all the way down”. To make even my little example above work it would be like…
body {
display: grid;
}
.site-header {
/* current spec way... */
display: subgrid;
/* old way... */
display: grid;
grid: subgrid;
}
.main-content {
display: subgrid;
}
.main-content > ul {
display: subgrid;
}And that’s without defining how the grid actually works.
Eric Meyer has also emphasized this need for subgrids:
Without subgrids, you’d either have to make every element you want to lay out a child of the body element (or whatever you used to create the page grid), or you’d have to recreate segments of the page grid in each nested grid, and give up any hope of columns that can flex with the contents of multiple page sections. Neither solution is appealing.
He used <form> markup as an example, where <label>/<input> pairs are necessarily grouped within container elements, meaning they can’t participate on the same grid together.
He called for grid to not even be shipped until this can be handled:
subgrids are a major component of grid layout, and should be a part of any grid layout implementation when it emerges from developer-preview status. If that means delaying the emergence of grids, I think it’s worth it.
That ship has likely sailed …
… on having full subgrid support the day CSS Grid “ships”. But it’s probably worth making some noise (like writing this blog post) to indicate this is fairly important and should be worked on and released as quickly as possible after the first round of CSS Grid goes out. That’s not my thinking, that’s what Jen Simmons said she’ll be pushing for at Mozilla.
And even bigger danger is that subgrid is considered “at-risk” and “may be dropped during the CR period”.
And by “browser-maker folks”, as an interesting aside, it’s not always employees of browser companies that do this work, but often outside committers. Here’s a blog post about all this from one of those outside committers.
The risk…
… is that we love grid layout so much, that we’ll malform our HTML to make it work. We’ll make our HTML less accessible to make our grid idea work. We’ll ignore semantics and flatten our HTML.
Or maybe nobody will do that. But hey it would be nice to have to tools so it’s not even an issue.
I want know how i can develop a configurator in Realtime-3D like this: http://viscircle.de/3d-konfiguratoren/?lang=en
The most important question is the question. How I can implement the configurator in the website? That ist the question!
I don’t know, why You chose this blog entry for your question, but I happen to know the technology used on the linked site. They use Blend4Web (https://www.blend4web.com/en/), a Blender-based (https://www.blender.org/) web library. I guess, You can go with other options as well.
I’m hoping that we’ll get support for
display: contents;by the time Grid fully ships. If that works as advertised we’ll be able to “remove” elements from the display context, allowing children of children to rise up a level and behave like children. In other words we can have a top-level grid container, tell its children not to act like grid children withdisplay: contents;and allow grand-children elements to behave like grid-children as though the middle generation doesn’t exist.Whoops, forgot the link to Rachel’s post about
display: contents;– https://rachelandrew.co.uk/archives/2016/01/29/vanishing-boxes-with-display-contents/Hey, thanks for writing this! I think the example of how subgridding works is out of date, if I’m not mistaken. According to the current spec, all you need to make a subgrid is
display: subgrid;rather than settingdisplayand a separategridproperty. Not a huge difference, but it does make the CSS a little more palatable.Definitely agree that
subgridsupport is essential. We could limp along by re-creating the parent’s grid within the child elements, but ultimately we’d face the same challenges we have with floats…elements that are ignorant of their surroundings, and/or layouts that are not tailor-made for their contents.Best use of “me too, me three” joke ever…
Great read! I am a big fan of Susy and flexbox,It even helped me in a specific case to reproduce some legacy grid that needed to be ported to the new world app to avoid having to port the entire framework or rewrite the entire HTML.
I need more information on grids. What is this doing for the basic website? Everything displayed in the article is doable now with flexbox and regular block level elements. And considering most of the web is moving mobile, almost everything is simply blocks.
What am I missing with grids? It reminds me a bit of some early websites made by print designers that just made every page a huge image to make layout perfect. Is grids a print designers concept for the web? If so, I am not sure it is really needed.
So, what am I missing on grids? What’s the magic here that isn’t obvious to a non-print designer?
http://lmgtfy.com/?q=css+grid
You can do everything flexbox can do with position absolute, float, tables etc but doesn’t make it a good idea… Flexbox isn’t really intended for page layout, its more for components (as its impossible to do things like match flex-item heights across multiple rows). Grid should do a much better job of handling the bigger picture layout and structures.
Grid columns/rows can be automatically sized (sized based on their contents) but still aligned. Alignment and automatic sizing are key. If you have a group of floats or flex-boxes for columns, each with a group for rows inside of it, they won’t line up unless you manually size them.
Thanks for the notes, I did some research and it looks like some layout stuff with Grid could be easier. But sub-grids? This seems like the biggest complaint of this post, and everything everyone is saying is that flexbox is for content, which seems is the same as a sub-grid. Seems like a logical conflict. (or maybe some people just don’t like flexbox?)
Grid Spec is pretty nice for the same reason flexbox was/is nice: less markup, less styles, less bloat, a few neat features like source ordering.
You have always been able to do these things with
position: absolute;and such, but they were messy and required a ton of work to “get right”. Grid Spec makes this kind of stuff easy.The subgrid argument is because most tools benefit from having the ability to recursive. If Grid Spec helps at a shallow depth, why wouldn’t it help when nested?
I agree with pretty much everyone on this matter… just wait for subgrids.
I would think that the risk is low on that particular point. I’m on the side that I’d rather not start using Grid until sub-grid is available. This means that rather than change my markup temporarily to get it working with Grid and then again once sub-grid has support that I’ll continue on my merry way with floats and flexbox until the full solution is available.
I’m not interested in competing with Grid Spec (as I don’t have access to the same variables they do and I feel like Grid Spec will free me of my obsession), but I recently built a PostCSS plugin that could keep the masses at bay if the spec authors want to hold off for subgrid support (they should).
The plugin was developed without knowing anything about Grid Spec, but ended up with a lot of similar concepts in it.
It doesn’t share the same API, but I don’t think that’s a bad thing (since it might cause confusion when the spec actually lands). However, the API is very composable, lightweight, and offers things like combining fixed CSS lengths (e.g.
100px) and real fractions (1/4instead offr (flex-grow)units). It also provides a way to fill remaining space, and I’m currently working on a way to generate columns and rows — very similar to spec, but not perfect (at the time of this writing it will only generate columns).Most interesting, the sizes it generates are pluckable so you can use them anywhere you want without having to fool around with casting an entire grid.
I’ve tried spamming this a few places, but it never picks up steam. I suppose everyone is at this place in their mind where they’ve replaced grids with flexbox and don’t want to “go back”. I get that, but flexbox was never a replacement to grid systems (seriously it’s bad in that respect) — and the plugin I created doesn’t compete with flexbox. Feel free to sprinkle flexbox where you need it.
This plugin acts as the step between traditional CSS grids and Grid Spec — while offering some cool stuff like easy ratio-sizing (http://alistapart.com/article/content-out-layout) that Grid Spec just doesn’t offer by itself (I’ll port that functionality when the spec lands). And it works seamlessly in IE9 so you don’t have to ignore all the people stuck on old/underfunded browsers.
I’m in the process of refactoring it right now. I’ll be done and the API will be locked in a few days. I wouldn’t suggest building any sites with it right this second, but dropping a Star and checking back next week probably isn’t a bad idea.
Feel free to use it anywhere you’re not allowed to use Grid Spec (at least several percent of users even with evergreen browsers), and in the interim while the spec authors figure out if they’re going to support subgrids.
Or not.
Chris, you once wrote a post called “Don’t Overthink It Grids”. I didn’t read that (I did). postcss-ant is the result.
A two minute read on using display: contents to solve this problem.
https://medium.com/@ollie_w/whats-so-great-about-display-contents-ce5628ebce86#.z9whk9f3c