Ever been given mockups where the mobile design moves stuff all around into a different order? That has traditionally been extremely difficult to handle with CSS given identical, unchanging markup.

With CSS Grid you just give each of your components a `grid-area` name, and then you just tell the grid where those areas go at different breakpoints.

So on mobile you might have 4 components laid out in a single column:

    grid-template-areas:
      'breadcrumbs'
      'filters'
      'sort'
      'products';

    grid-template-areas:
      'breadcrumbs breadcrumbs  sort'
      'categories  products products'
      'filters     products products'
      '.           products products';

Now all the subcomponents need to do is define their `grid-area`, they don't need to adjust their own layout at the different breakpoints.

Any recommendations from either of you on material on grid-template-areas? It sounds like it would be great for getting away from the hack of having a mobile menu and a desktop menu on our existing site (with the one for that format rendering and the other hidden), which I've hated as it is a pretty clear indicator I couldn't find something more appropriate.

https://youtu.be/7kVeCqQCxlk?t=1039

Watch on for the 'crazy response design' part.

I am still amazed.

This is incredibly compelling stuff though. First thing in a while I’ve seen that has left me floored.

At first I was thinking it was inferring first HTML element seen (head) relates to first area element written (also head), second HTML element seen (nav) and second distinct area element written (also nav), and third HTML element (footer) with third distinct area element written (foot). Then I see the pretty obvious grid-area within the CSS handling that linking and I must say, that's beautiful stuff.

Looks like Chrome does autoplay, so does Firefox.

I'm kinda liking how Safari handles privacy, tracker blocking, and autoplay blocking.

>"I love it because not only is the above a list of the subcomponents that make up this component, but it's also a visual indicator of how they'll be laid out."

Yes! Love it.

Tangent: This reminds me of some native iOS layout thing from maybe 6 or 7 years ago but I can't recall much about it-- scratch that, googled and, yeah, "VFL": > "The Auto Layout Visual Format Language (VFL) allows you to define constraints by using an ASCII-art formatted string."

IOW, ASCII art for layout implementation.

The fundamental problem with CSS Grid is that it is two dimensional. This makes CSS Grid great for two dimensional uses, like aligning content both horizontally and vertically, but it begins to fail when I need to align content with the user's hand. Instead I need real three dimensional layout, which is why I need CSS Matrix. Fundamentally Matrix is 3D.

https://news.ycombinator.com/item?id=16307116

You heard it here first.

I see this said a lot but in my experience (a) all the cases where I use flexbox eventually get replaced with grid with about the same verbosity but more flexibility and (b) I've noticed subtle bugs when using flexbox with grid that manifest only on some platforms (e.g. On iOS but not on Android, only on some versions, etc).

They have different use cases, it's just that (at least with regards to (a)) everyone's switching because they wanted something like grid in the first place and only had/knew about flexbox. It got you halfway there (we've used multiple flexbox rows that don't wrap to simulate grid, for example), and now they're just going all the way.

  const $ = (selector) => document.querySelector(selector)
  const $$ = (selector) => document.querySelectorAll(selector)
  const on = (elem, type, listener) => elem.addEventListener(type,listener)

  const $ = document.querySelector
  const $$ = document.querySelectorAll

```` $ = document.querySelector.bind(document) ````

https://youtu.be/BIeJNFDXyMI

Two+ decades spent on kludges to have things line up in columns.

That's why laying things out vertically with CSS is often more challenging than laying things out horizontally. The assumption was that content starts at the top and flows downwards on an infinite canvas until it is finished, with the length of the document defined by the content. Contrast that with the width, where it has a finite size defined by the viewport and is wrapped.

This processing model makes perfect sense for documents, less so for application interfaces.

But please! CSS was a web technology from the start. I routinely committed the deadly sin of table layouts from the mid nineties all the way up into the new millenium, because that was the only way to do it. It is utterly beyond me how CSS - glib explanations or not - could blithely ignore this very real need all through 1.0, 2.0, and well into 3.0.

But I must say, Grid was almost worth the twenty years wait, and it does bring on a sweet nostalgic rush once again having to shake a fist at various MS browsers.

Sure, of course it was. But the web was almost entirely a collection of documents back then.

By some felicitous fluke I still have the very first html I ever coded, anno 1995, complete with background sound and animated gif - but cut me a bit of slack: It was purely a personal excercise. The thing was done purely from what I'd learned studying source of available websites. The point being: My God, it's full of tables. They were a real thing by that time.

Applications are not based off documents but rather the raw data (which the machine natively understands).

The transition of web from documents to a dumb platform for application software delivery is why the web is no longer the web. It is just application delivery infrastructure now. Each application lives in a walled garden and is no longer a "web" at all.

https://web.archive.org/web/19961022174810/http://www.altavi...

I learned the fundamentals of graphic design through print design, as that is a medium that designers have worked with for much longer than the computer screen. A lot of designers approach print design by starting with a grid that describes how their content will be laid out, and proceed from there. Of course, you can find exceptions to this (although in many cases they will be an example of a designer breaking the rules because they know them so well), but most design students will be familiar with that approach.

"Grid Systems in Graphic Design" (1981) is one of the reference texts on this subject, if you're interested in getting deeper.

The other commenters say, in reply to your question, that it was just for formatting HTML, and for web documents rather than applications. That is just completely missing the point - print documents are documents too, not applications. The main argument that the web is so different from print because the canvas is infinite doesn't make much sense either - even if the canvas is conceptually infinite, it still renders on a finite surface (your screen), and one can design modular grid systems that easily accommodate that (as well as the other related concerns, like the user not having the right font installed, or different pixel densities/aspect ratios, etc.).

In the end, the best explanation seems to be that the CSS spec was never led by actual designers who could envision the sort of problems that one would face when designing documents for the web. The CSS spec committee is full of very hard working, smart people, but they have the concerns of engineers first - browser compatibility, rendering complexity, etc. - rather than designers.

The fact that the "holy grail of web design"[0] is a thing is absolutely mind blowing to me. This is the kind of design any first semester design student would execute, and any styling language that does not let you implement it in 10 lines is a styling language resolutely not designed by (or for) designers.

[0] https://en.wikipedia.org/wiki/Holy_grail_(web_design)

I get that that is CSS, not the game's rules, so not arguing why the game handles that way, I'm just curious what the motivation is for the CSS rule.

* By people, I mean designers (used to bootstrap-style grids), coders (used to arrays) and everyone else (used to spreadsheets).

Actually, wait. Thought on your line numbers a bit and I'm thinking that points to each vertical line as a number (so in this garden's case, 6 per row). I just plugged it in as that and it follows. Just feels foreign to me as I'd do start/end 1 for just first cell, start 1 end 2 first two cells, etc. I'll get accustomed to it though. I wonder if there are other scenarios that followed the same logic in CSS that I just didn't attempt to really grok. Thanks for pointing it out.

Here's a great resource covering the hows and whys: https://rachelandrew.co.uk/archives/2016/11/26/should-i-try-...

And here's a simplified example I threw together recently to demonstrate it in action: https://codepen.io/shahab/pen/ypWmZG

Basically, you lose auto-placement, named grid areas, and simple grid gaps, so you have to manually place items in the specific row/column for IE. But, I've found that it's still easier than the alternative in many cases.

If you limit yourself to only using the parts of CSS Grid that IE11 supports, then you can write the standard equivalent to that subset and Autoprefixer will translate it for you, but you can't "just write standard grid layout", because that includes things there is no IE11 equivalent for.

    a {
        display: flex;
    }

    a {
       display: -webkit-box;
       display: -webkit-flex;
       display: -ms-flexbox;
       display: flex;
    }

I personally stopped using Bootstrap years ago when I gained a good understanding of CSS. The most common features that Bootstrap provides (components and layouts) are not hard to implement yourself. And you'll avoid littering your markup with brittle combinations of class names and nested <div>s.

I can tell my client's IT guy "just put a div with a class of .card and then a div with class .card-body in your WYSIWYG and you will have the correct display".

That the framework use floats or flex or css grid is irrelevant to the end poweruser.

I pass the template I make along to the next project, and improve the template as I go. By using frameworks you're hand-balling the task of "making it better" to someone else. As for css grid, not using it yet due to my wanting to support older browsers, but I am now enjoying flexbox for page structure after ignoring it for a long time. Flexbox is a great set of tricks.

You sound a bit ambivalent about whether this is a good thing or not.

I would guess most hand-rolled alternatives don't have a long list of well documented browser bugs they couldn't work around and don't have half the workarounds for things they could handle. Instead they'll just silently break since they don't have the QA exposure across obscure platforms that Bootstrap does as a massively popular open source project:

https://getbootstrap.com/docs/4.0/browser-bugs/

I would guess Grid has just as many issues, and would guess that Bootstrap will adopt it at roughly the time it becomes supported by a wide range of browsers, and will have implemented and tested workarounds for any lingering issues with it.

Bootstrap seems to tickle the same "I could write Dropbox over a weekend" response that Hacker News commenters are famous for, just from those with a slightly different technical skill set.

That said, I see the value of a CSS "library" for a large team that has to agree on both a template and terminology.

Float: in sections where there could be a variable number of columns, and the columns could have variable possible widths, using floats can be simpler than grids.

This is because you have to maintain many different grids (and their media queries) for the parent display:grid elements, and with floats you're only styling child elements.

Did you mean HTML table based layouts? Because yes, it's good those days are behind us...