Hacker News Reader

Comment by theklr | Hacker News Reader

Once you wrap your head around how grid works (especially with fr) it's a godsend. I'm glad css is maturing in a way that actually meets the layout needs of a device.

View on HN

I keep dipping my toes in grid but not long enough to commit and I run back to flexbox.

I feel like flexbox was such a savior already that I'm still comfortable there.

Yes flex is cool because you don't need a new type of element just add the property "display: flex" to anything.

I think Grid is a bit more complicated, more to learn. CSS is getting better but at the same time it's getting more complex in total.

It makes sense.

Flex was finally FOR (I think it was for) layout, from the start. It's simple, works for a lot of use cases.

Grid is for layout, but serious layout.

It's good to have both.... well anything really considering the history.

Grid doesn’t really use a new type of element either.

I’m just happy to be able to layout things 2D in a way that isn’t totally bonkers and do weird contrived calculations to make everything fit in the viewport. My only wish remaining is a unit that is like fr for grid layout but can be the same value for both row and grid (so an equivalent to vmin for viewport)

I actually think grid is simpler. The flex properties are confusing and make common cases complicated. Grid fits my mental model of what I am trying to achieve pretty much 1:1.

Oh man if you like flexbox, I'd definitely take the time to really get in there on grid. Learning to mix the two together has been amazing.

Yep. I was able to pull off a UI pattern that never would have been possible in legacy css. It's pretty rad.

I’ll bite. In my experience, almost every case where CSS Grid has been touted as enabling something new was actually already possible with flexbox alone. Care to share your UI pattern that I gather uses Grid and Flexbox, and I’ll see if I can reasonably reproduce it without Grid?

I don't know what he's done, but I think an obvious use case is this grid list: https://codepen.io/anon/pen/xNNXBR

Basically, a list of items arranged in a grid where the number of columns is dynamic depending on the width, items are wrapped dynamically from left to right, each column consumes the maximum amount of space, there's a fixed gap between columns, and the last row is aligned left, not stretched. I had to build one recently, and it was a perfect fit for grid.

Cannot this be done with just floats or inline-blocks and percentage width? Unlike grid, it would work in a larger number of browsers.

Also, I think that tutorials for things like flexbox or grid should include fallbacks for older browsers. Because generally frontend devs simply copy the code from tutorial so if you don't include the fallback, they won't implement it.

The support for grid is very good for the vast majority of modern applications[1], given its power and the things it can simplify that often require JS solutions otherwise

1. https://caniuse.com/#search=Grid

Not if you want the columns to stretch to fill the remaining space, and you also want the number of columns to be dynamic.

> Also, I think that tutorials for things like flexbox or grid should include fallbacks for older browsers.

Well, a sensible fallback for that grid list example would be to inline-blocks with a fixed number of columns.

You make a number of columns dynamic by setting different percentage widths on different page sizes.

But then it's responsive to the page size, not the container size. That's a small, but important difference.

For instance, I recently made a component to be included on other pages at work. It had to look good no matter the size the page gave it. So they might put it into a 400px wide container, on a 1600px wide page. If I used vw or media queries to draw it based on page size, it would behave wrong.

I was thinking about that problem earlier. Is there not a CSS unit for container size? If not, that seems like a very useful addition. Like a more embedded version of vw/vh.

Percent can be based on container depending on how the container size is set.

Ah, of course you're right. Good point thank you.

> Cannot this be done with just floats

Every time a float is used a Servo dev gets another grey hair.

Jokes aside, floats are Ok, but they make parallel layout from very hard to optimize, to no better than just using a single thread.

Similarly to tables, floats were not created for layout and shouldn't be used for layout anymore.

Unless of course you're talking about laying out an image alongside text.

That's not page layout as we're talking about. That is one of the proper uses of float.

It absolutely could, but yikes... it's not necessary to put yourself through that these days.

AFAIK every browser but IE11 supports the modern basic grid syntax. Edge has supported the new syntax since Edge 16 which is old enough to be widely deployed in enterprise now. So as far as I'm concerned that's the "Vast majority of browsers" and for static grids I just use the old syntax as a fallback for IE11

https://caniuse.com/#feat=css-grid

A horizontal list, where each item has variable width based on its content. Inside each item there is additional hidden content, which should factor also into the item width. The hidden content should display behind the primary content.

When hovered, the hidden content will appear via an animated dropdown. The height of the content varies as well.

Hopefully that makes sense.

You can reproduce a fair bit of Grid using just Flexbox (and we did that for quite a while before Grid came along)—but it's going to be far more verbose, both your HTML and CSS, and probably more brittle and complicated to change.

If you're setting precise sizes in flexbox, or very specific flex values, you're probably in Grid territory. Ideally, flexbox is best when you want things to stretch/shrink to fit and you want the items to determine their own sizes. Grid is best when you have a specific layout/sizes in mind, and you want to impose that layout onto the items.

I can recommend "The New CSS Layout" for getting up to speed on CSS Grid (among other modern and legacy layout techniques): https://abookapart.com/products/the-new-css-layout

It does mention subgrid too.

Looks like the author of that is also the author of this post.

You will find her name quite often when you research CSS grids - she's something of a layout and grid expert. If you'd like to read more, check out some of her fantastic posts at Smashing Magazine, where she's chief editor: https://www.smashingmagazine.com/author/rachel-andrew/

Though both are used for laying out your content, but Grid and Flexbox serve different purposes though. We can probably still use Flexbox for majority of the cases, but Grid was designed to help with some specific CSS layout problems that only it could resolve.

I would suggest finding a single use for grid that flexbox doesn't really do well, and use only a couple properties. Then you will really understand the benefit of grid without having to invest a lot of time.

An example I dealt with recently: I needed a header with logo / external link / social icons/ content / phone link. All to layout perfectly, and be mobile friendly.

With grid, I used this: (this is rough code to demonstrate the simplicity, I made a codepen demonstrating it properly. [0])

  header {
   display: grid;
   grid-template-areas: 
     "logo content link social"
     "logo content phone phone";
  }

For each of the logo, content, etc... areas you use this to attach it to the specific location in the grid.

  .logo {
    grid-area: logo;
  }

  .content {
    grid-area: content;
  }

  etc...

You end up with exactly what you would expect:

  +------+---------+-------+--------+
  |      |         | link  | social |
  + logo + content +-------+--------+
  |      |         |     phone      |
  +------+---------+-------+--------+

For mobile, I wanted this:

  +---------------+
  |     Logo      |
  +---------------+
  |    Content    |
  +------+--------+
  | Link | Social |
  +------+--------+
  |    Phone      |
  +---------------+

Here's the only CSS needed for mobile. (or reverse this if you are doing mobile first layout)

  @media (mobile) {
   header {
    grid-template-areas: 
      "logo    logo"
      "content content"
      "link    social"
      "phone   phone";
   }
  }

Here's the html:

  <header>
    <div class="logo"   ></div>
    <div class="content"></div>
    <div class="link"   ></div>
    <div class="social" ></div>
    <div class="phone"  ></div>
  </header>

The power to move content around with such simple and clean code like this is amazing.

With flexbox you can use the "order" property to move stuff around a little, but not control the exact layout so cleanly and simply. There are tweaks for adjusting the widths of columns and heights of rows, but this is generally all that is needed to get the layout with grid.

There is also grid-gap [1], something not possible in flexbox yet. (though Firefox supports grid-gap with flexbox)

[1] https://codepen.io/Vanderson/pen/yWWVVZ

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/gap

https://caniuse.com/#feat=css-grid (92% of users)

The trap is CSS grid in IE which is counted as partially supported is a much older spec of css grid which works quite different to the final spec.

Still 90% even without IE, though.

If you _have_ to support IE, I would just add conditional comments, and make all grid stuff one column and not worry about fancy stuff. IE users just can't expect the internet to pander to an outdated and unsupported browser. If it was supported by MS, I might consider a little more care though.

Unfortunately the website I work on has more users on IE than any other browser. I wish I could use grid but there is just no point when the fallback would be the main way to see the website.

That is a rare circumstance, and I agree with your assessment, no point in making life hard for yourself.

Since IE is no longer supported (or even considered a browser by MS, but a compatibility layer) what kind of site do you work on that is so heavily trafficked by primarily IE?

Its a project management web app. For some reason every IT department seems to have locked all the computers they manage to only running IE, and then they customize the shit out the settings on IE which make the site break in insane ways that we can't test.

That's incredible, I am sure all the webdevs that read your comment feel your pain.

That’s awesome. That’s a very common problem even for non layouts. Many of the complex UI elements I work on daily all need basic mobile support where I could see applications for this.

It seems to be about a mix of grids with flux instead of either/or.

I've found grid to be helpful even with just rows of data, no columns, using grid-gap to make space between rows, like in a standardized form.

But you are right, something like a gallery of images (unknown number of items that need to flow), flex seems more useful.

Thanks man that is awesome.

You are right that I just haven't NEEDED it and without that I don't tend to grock things.

np, glad I could help. I avoided grid for a long time until I read way too many good comments about it not to dig in a bit until I was convinced as well.

It reads much cleaner for sure than flexbox.

In my experience the prime example of something that works better using grid then flexbox is with description lists `<dl>`:

    dl {
      align-items: baseline;
      display: grid;
      grid-gap: 1.5ex 1.5em;
      grid-template-columns: fit-content(12ch) 1fr;
    }
    
    dl dt {
      font-weight: 600;
      grid-column: 1;
    }

    dl dd {
      grid-column: 2;
    }

This will put all your terms in the first column and all your descriptions in the second. All aligned nicely and creates a new row even if you have two `<dt>`s or `<dd>`s in a row. A flex solution would quickly fail once the terms get irregular.

https://codepen.io/anon/pen/gJJmzM?&editable=true

That's clever. I think it's easy to make complicated solutions, and this is pretty clean. I like the solution for irregular content/tags getting displayed correctly.

But here’s the thing: Grid’s regular handling of long terms is typically not actually ideal anyway. Here are four ways of formatting such lists:

① Something that can be achieved with float, fancy margins or a couple of other related techniques (with caveats, inside this markup structure, such as needing both dd and dt to be inline, since `display: run-in` died):

  Key:     Value, even on
           multiple lines
  A long key: Value, even
           on multiple
           lines

② A flex approach:

  Key:     Value, even on
           multiple lines
  A long key: Value, even
              on multiple
              lines

③ A grid approach, avoiding wrapping keys:

  Key:        Value, even
              on multiple
              lines
  A long key: Value, even
              on multiple
              lines

④ A grid approach, wrapping keys (and you’d better hope the key is wrappable):

  Key:     Value, even on
           multiple lines
  A long   Value, even on
  key:     multiple lines

Now as it stands, your fit-content approach lands part-way between ③ and ④, wrapping the terms where possible, but extending the column’s width if necessary (e.g. if you use a long, unbreakable word, which experience tells me will be a URL and thus insanely long). Yet I would argue that in most cases of unknown content, ① or ② are better, most commonly ①. Wrapping terms is generally a bad idea (especially if there is no border in the grid), and if arbitrary content can end up in the term you’re likely to get pathological cases, like URLs in the term.

(I say all this as one who switched his known-content-that-doesn’t-trigger-these-cases <dl>s to `display: grid` over a year ago. But for arbitrary user content, I’d be more likely to go back to approximating ①, probably with markup other than <dl> now as well, to avoid problems related to it.)

This approach to handling outliers (break out of a rigid grid, wrap, extend all, &c.) is worth thinking more about. In the article this thread is about, I am actually not convinced that having the card internal elements lining up is a good thing. Here’s the problem: the depiction of its appearance when they don’t line up is deceptive, and not how you would realistically implement it. Without subgrid, you’d be using `display: flex; flex-direction: column` on the cards, and that’s what’s depicted; but what the depiction lacks is `flex: 1` on the content, so that the header and footer take the least space possible, rather than themselves flexing as well. If you fix that, the not-lining-up case no longer looks terrible; I’d say that at that size then it’s six of one, half a dozen of the other; and for larger grids or more pathological cases, it’ll very arguably be nicer.

But here’s the thing: Grid’s regular handling of long terms is typically not actually ideal anyway.

Grid is just the layout (columns/rows), not entirely how text is handled. 3 & 4 are no different with grid, only word-break/word-wrap with forced/limited widths.

And 1 & 2 seem disjointed and hard to read (ie, break long held rules for readability), I don't see the value arbitrary space after the key. 1 & 2 would easily be better suited to this:

  Key:
  Value, even on
  multiple lines

  A long key: 
  Value, even
  on multiple
  lines

Or this:

  Key: Value, even on
  multiple lines
  
  A long key: Value, even
  on multiple lines

Wow this is incredible. Thank you for the example; much easier to understand the value right away

It took me probably a day of testing to convince myself because I really didn't find a simple example. I have simple atomic classes that create a set of columns I use frequently that solve problems that just a few years ago were always an annoying mess.

Grid requires no/fewer wrapping elements, solid outcomes (ie, code matches result more often than other layout methods from the start) and lots of minor properties for edge use cases. And this is just a summary of the benefits.

Wonderful comment, bravo!

I think back to the early days (circa 2000 or so), before CSS positioning and float hacks were even a thing, working as the lead webdev at Upromise, meticulously hand-crafting complex layouts with nested HTML tables... you could nest them 5 or 6 levels deep before running into noticeable render performance issues in what must have been, what, IE4 and NN4? It really has been a couple decades, hasn't it. Kinda wish every FE dev had to follow the path the industry took to get where we are now...

/ramble

ha, ah the memories. On my first web job (late 90s) my boss interviewed a guy who was bragging about one pixel borders around an element that were all background colored table cells. (each had to have an image in them to force the cell size, remember doing that?) I knew how to do this, but I said it just wasn't worth doing.

I think this is how web tech works best, when you see the best way coming down the pipe, don't waste time on hacks. But I admit, floating was the only way to make columns for far to long.

I know grid is taking a long time to take root. I primarily only use grid-template-columns, grid-gap and areas or really only needed for major/complicated layout.

Float?

Why not table with inline width=95%/align=center

Of course back in the day we all used tables, but there was a shift where "tables=bad" for layout, but we didn't have a good replacement yet... so it was floats.

float, with "faux columns" that I copied from a-list-apart for every new page I made.

Used to draw round corners [the biggest design trend request circa 2002] using tables with cells of one pixel, painting every cell mimicking a perfect anti-aliased curve in a photoshop rectangle, a mere 32 cell table per corner, lol.

That takes the cake. The worst I did was 9 cells, with images in each corner. How did you maintain your sanity when one cell went bonkers on it's dimensions for no good reason?

Your comment made me remember that every cell had a blank gif so the dimensions would be exact! Even found a wiki about it https://en.wikipedia.org/wiki/Spacer_GIF

Yep, an image was the only way to "guarantee" the cell displayed at a specific width/height. These are the kinds of things that taught me most hacks aren't worth doing.

There was a time when the only way to get nice 1px borders was to place your table inside the other table, set the outer table's cell to the color you wanted for your background and then set cellspacing on the inner table to 1px.

Flexbox can't fully replace grid, or vice versa. In particular, this very feature, subgrids, can't be reproduced with flexbox.

flexbox works beautifully with grid

They solve different problems however. They are complementary, not substitutes.

Mixing the two is very useful. I typically make headers and footers with flex, build home page grids with grid, and then use flex to space out content in the cells.

No more floats, no more percent widths, no more weird nth child tweaks for positioning.

Add rems to the mix and responsive design has never been simpler. For grids you can just change from say a 3 column grid to a single column on mobile for most cases.

And the best part, no bootstrap.

Sadly the article with examples doesn't provide a fallback for older browsers and as frontnend devs usually just copy the code from tutorials without much thinking, it means that we are going to see a lot of new sites breaking in just 2 or 3 years old browsers. The usual sad state of web development is going to become even sadder.

Articles about flexbox have the same problem by the way.

I've stopped caring about people on ie or some super outdated browser version.

None of my projects have an audience that includes 90 years olds using ie6 on windows xp. I assume my users are on some chrome derivative that is fairly up to date.

I'm not going to use this until it's well supported, but I'll have no qualms going so.

I certainly am not worried about anything I've used flex or grid for... they've been out for quite awhile now.

I'm not sure why we are all trained to think that anything we build has to be compatible with old browsers that essentially no one is using.

For most projects, I don't see a point unless you have some really specific requirements.

> anything we build has to be compatible with old browsers that essentially no one is using

I think similarly, with the caveat that anything that might be useful to me at work (current or future day jobs) needs to consider IE11 because there are a lot of people out there stuck using that (we work with banks a lot, while it is increasingly common for recent-ish Chrome to be available too it is not close enough to ubiquity for comfort). This includes anything that I might want to log into myself from a client's site, where I might not be able to use my own device, not just that I might expect/want them to use.

> I assume my users are on some chrome derivative that is fairly up to date

Be careful just testing in Chrom{e|ium}. We are in danger of heading into what is effectively another period of browser mono-culture, especially now MS have thrown in the towel. I'd at least support "recent Chrome/Chrome-ish and recent Firefox". While chants of "the next IE6" are a bit hyperbolic, if a mono-culture, or something close to one, forms it will create future issues no matter how good are the intentions of the controller of the "winner".

I'd like to support Safari too but unless Apple provides a way of running that locally without having to buy their hardware or buy their OS then fight to get it running in a VM that isn't going to happen outside of commercial projects where someone else is paying for the resources to allow it to happen.

I was not talking about "outdated" versions of IE (although IE9 supports HTML5 and CSS3 to some degree so it is not so outdated as one might think). Also, it is a built-in browser.

I meant Webkit-based browsers and Firefoxes that are over 3-5 years old. What about Android phones with firmware without updates? What about smart TVs?

> I'm not sure why we are all trained to think that anything we build has to be compatible with old browsers

Because compatibility was one of the ideas behind HTML. Because there are less developers than users so it is easier to solve compatibility problems at their side.

Reply on news.ycombinator.com