CSS Grid Level 2 – subgrid is coming to Firefox | Hacker News Reader

CSS Grid Level 2 – subgrid is coming to Firefox

hacks.mozilla.org

368 pointsheadalgorithm114 comments

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.

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.

I find it mildly amusing that until advent of this cutting edge subgrid feature it wasn't possible to get simple "table-like" cards with matching "header - body - footer" of dynamic heights:

    +---+ +---+ +---+
    |1H | |4H | |7H |
    | H | |   | |   |
    +---+ +---+ +---+
    |2B | |5B | |8B |
    |   | | B | |   |
    +---+ +---+ +---+
    |3F | |6F | |9F |
    |   | |   | | F |
    +---+ +---+ +---+

To get this you had to either compromise semantics (use [1,4,7],[2,5,8],… table) or resort to JavaScript (read computed dimensions, find tallest and unify rest).

Graphic designers use this pattern very often. Finally coders will not have to worry about it anymore, soon. After 22 years of CSS.

Absolutely! This case hit very close to home with me. I remember once trying for an entire long weekend to solve it with flex/grid to no avail; only to be disappointed at having to use JS for such a 'trivial' task. This made me super happy!

To be more specific, the article doesn't say this isn't possible with CSS, but that it isn't possible with nested grids.

Which, of course, doesn't mean it's easy or even sane to implement in CSS...

For variable amount of "cards" that could eventually wrap this really is not possible to do in pure CSS without subgrid, as sibling comment confirmed. It is possible for fixed amount of cards: simple grid with named areas; it is possible for variable amount of cards when at least two of its components (e.g. header and footer) have fixed height: flex (or grid).

Once you have to match more than one variable dimension across two axis (headers/bodies/footers laid in vertical axis matching their "siblings" in horizontal axis in our example) you need either JavaScript, broken semantics or subgrid. This is -- as I understand it -- raison d'etre of CSS Grid Level 2.

Well, I'll take your word on it. There's zero chance I'm going to spend the next 4 years battling with CSS in an attempt to prove otherwise ;)

PSA: please please please test your grids on a variety of window sizes and aspect ratios. Poor grid design is now the most common issue I see on web usability reviews of greenfield projects.

To cite just a recent example from yesterday's Hacker News front page: https://nationalparktypeface.com/

Beyond just grids, any layout, explicitly responsive or not.

Fire up your browser's Responsive Design Mode and play around with the window width. The basics are generally easy to fix if you take a minute or two to spot check your layouts.

https://cssgridgarden.com/ is a fantastic site to get more intuitive understanding of `display: grid;`, can't recommend it enough.

Oh...oh...the numbering is 1 based. O_o

Grid seems so natural. Why did it take 25+ years of css standards to get to it? Is it only natural in retrospect, having slogged through all the troubles of other css layout systems? Was there some long running bias against table-like things that prevented people from seeing the way?

It took a long time for tables to be forgotten. Once that happened it was only natural they'd be reinvented in contemporary style.

Grid is nothing like tables.

The main difference being you can effortlessly rearrange the layout based on screen size which tables couldn't do.

CSS have supported tables (via display:table) since CSS 2.0. CSS grid is much more powerful than tables though.

Am I alone in thinking that the way we're doing brochures as layering multiple complicated ad-hoc layout constraint languages on top of a markup language that itself hasn't much changed in 20 years is absurd? What is really gained by such a powerful, yet highly idiosyncratic construct that not only can insert and/or delete content elements, but also rearrange the order in which they were specified in the input document in the first place, weighed against the complexity this brings to authors and implementers? Is the HTML+CSS stack victim of self-imposed, arbitrary principles of separation of structure and presentation? I can see the practical use of grids and subgrids etc., but who really authors an HTML document with the expectation that it should render as a traditional hierarchical and flow-based layout, and a grid-based layout at the same time? Translated to the domain of programming languages, CSS is to HTML what eg. ten times the amount of LOCs of annotations are to regular Java code. Why not just use a responsive table layout based on revised HTML tables when, clearly, the author's intent is to layout page elements in a tabular fashion?

We often have a different order in desktop and mobile 'versions' of the responsive HTML site.

Yes, I know that, and am doing it, too, on my sites. Still, squeezing everything into a single HTML page, then applying CSS (and JS) fu to arbitrarily rearrange, add and drop content doesn't seem rational when website design processes draw upfront desktop, mobile, etc. breakpoints and sketches. Rather, CSS complexity seems a manifestation of organizational boundaries (eg. W3C specifying CSS and WHATWG specifying HTML) to me. Or even a post facto rationalization of the road not taken with HTML. Eg. almost all responsive designs used today can be achieved much more easily using adaptive techniques where there is a device/breakpoint-specific page layout for desktop, mobile, and maybe tablet, resp., with the page template documents pulling in content wherever it fits. It's just that HTML lacks mechanisms for page composition such as SGML's and XML's entity references. Arguably, responsive grids are not only more complex than needed, they're also inefficient wrt. network utilization, as every device has to receive every bit of content, just to hide it away when it doesn't fit the layout. Of course, large sites use JavaScript and visibility events to pull content on-demand anyway.

I'm not pissing on W3C's (fantasai et al) work here. CSS is very much a work in progress as we all discover new UI idioms for digital media, and I'm a sucker for it. I just think CSS grids and flexbox is bordering on intellectual brain wankery, when the solution could be achieved much, much simpler, and in a way that doesn't send newbies into a world of cluelessness, doesn't question our ability to consume our own digital media in the future due to over-complexity, and retains the qualities of the web as a medium for simple self-publishing even for a layman.

If you want to embed styling/layout information directly in the HTML you can do that using the "style"-attribute.

The main idea, I think is still to keep the data and representation separate, which is advantageous for accessibility, computer representability and alternate representations (text mode browsers). We're kind of halfway there but there is still a lot of layout going on in the HTML "because we can"

Arguments like this are basically a huge "fuck you" to anybody with internationalisation and accessibility needs.

Yes, if all you care about are able-bodied Western users consuming content on standard devices, then you can get away with just baking your style / layout into the markup like your someone hacking away back in the 90s. The moment you need to move beyond that, you'll start to introduce methods for abstracting style and layout that, eventually, will lead you to reinventing something pretty similar to CSS.

Why do you think a different way would be less accessible or couldn't be made accessible by engines that parse the new markup?

Even if you acknowledge a separation of content/structure and presentation, the layering of new ad-hoc languages (CSS) eg. a different syntactic construct, onto markup does not follow from that premise at all. Markup attributes were introduced exactly for the purpose of holding rendering properties, eg. everything that isn't directly presented to the viewer. The ideal of "semantic markup" was only proposed once CSS was established, as a way to rationalize this ad-hoc separation after the fact. Now with CSS we have a million DSLs without type checking, huge cognitive deficits, and every single problem imaginable when a new language is bolted on top of another. All because HTML had to be backward-compatible, and evolution of HTML as a markup language was held back due to unrelated organizational problems. This is not a good outcome when SGML has all the power you want for rigorously developing document formats on a very long timescale.

Edit: Look at the comments in this thread. They're mostly about "how flexbox works" and how to apply particular CSS grid features. Nobody actually authors content with the intent of structure/presentation separation.

Context: Tables were used for static content, then came transparent 1px gif, then JavaScript to create a hover effect for buttons.

Enter CSS.

Today's content is very different. Today complex applications that were 20 years ago bound to the desktop are (re-) created using Web technology.

This seems overkill for some apps like landingpages, however complex apps benefit from CSS that reacts to its context. Otherwise you would be very JavaScript heavy on those layout things and that is pretty much the essence: CSS3/4 pretty much did what JavaScript layout tools did but native.

Ok, but you still need tons of JavaScript for webapps, and the trend has been to generate inline styles using JavaScript, JSX/React etc. anyway. Not sure introducing the complexity for webapps, with the content-oriented web as collateral damage, was worth it.

> Am I alone in thinking that the way we're doing brochures as layering multiple complicated ad-hoc layout constraint languages on top of a markup language that itself hasn't much changed in 20 years is absurd?

Probably you are not alone, but I'm sure you've just haven't spent enough time building complex or niche things in the browser. For simple brochure sites, CSS3's full feature set is an overkill. Use cases on the other hand are near infinite and there are thousands of developers out there needing unique combination of CSS solutions that you can't think of.

Rearranging content for example is a great way to reduce server rendering logic: just generate a bunch of <article> elements and the client will know how to display it. Even the user can make choices based on zoom levels what layout they prefer.

Even with JavaScript support it's nice to offload rendering logic to be handled by the browser which renders it directly on the GPU. If you do layout with JS, then there will be a function call doing expensive calculation every 16ms, that not ideal and CSS3 solved it for us in many cases.

'display: contents' works nicely for the first noddy example, with the subsequent 'cards' example that is where the magic of subgrid needs to be understood and used.

Could be a while though, what is the bet that Safari will be last to get subgrid?

Safari is the last to get anything most of the time. Apple really needs to step up their game, especially if they want to shove people into PWAs.

They're in no hurry to encourage PWAs, it takes people away from the App Store which is how they get a substantial amount of money.

Safari got grid support within 3 weeks of Chrome, so there’s reason to be optimistic.

Blink!

I think that since Google forked Webkit things have only made it into Chrome to then appear later in the other browsers. But you never know.

`display: content` still wrongly removes the content from the accessibility tree in all browsers except firefox. This is a serious bug but it doesn’t look like the other browser vendors are too keen on fixing it. But until it is fixed in the rest of the major browsers, one cannot actually use this feature for anything except prototyping.

https://caniuse.com/#feat=css-display-contents

I know flexbox and more or less grid but I feel like old good display inline-block and positioning is still 50x faster for prototyping and often development. Especially flex made simple things really complicated, like you have two quite long and totally unrelated properties for aligning items horizontally and vertically. And the fun really begins when you inherit codebase after someone else - even making item 100% wide is sometimes incredibly hard with flex (width: 100% does not work!). And from my experience grid is even bigger hell to maintain. Especially if many devs work with it and some of them are not really CSS wizards.

If you name your grid areas—I find grid quite elegant and easy to maintain.

Also I often find that the number one reason for hard to style scenarios, is overly complected markup with deep div soups and other non-semantic container elements.

Am i the only one who still uses good old floats and position?

Supported everywhere, keeps markup to the bare minimum and doesn't smell like 1992 <table> based layouts.

I still use them plenty, but more for specific situations rather than major layout decisions. Both have their warts however.

Float can have undesirable behaviour regarding document flow and clearing afterwards. I try to use it just for floating things inside of text.

Position is just a bit illogical, really. Especially when playing with absolute. It puts you at the mercy of any parent element that just happens to be position:relative. I try to stay in the document flow whenever possible.

I like flexbox a lot. My biggest complaint is simply that it has a ton of rules and have to frequently look them up. It's a lot nicer to work in for 1D interfaces though. Especially in the age of responsive design.

I haven't had a chance to really dive into grid yet, but from what I've read it looks really useful for 2D layouts. It means not having to rely on the various column-based CSS frameworks for more complex sites. This will probably be my go-to in the future for main site layouts.

Nope, you are doing good. I did floats and positioning for over 10 years and still like it.

In my opinion however Flexbox and Grid have a decent advantage when it comes to responsive/fluid layouts. Grid and Flexbox scale by design while floats and position feel static.

> and doesn't smell like 1992 <table> based layouts.

Word of advice: don't even think about viewing the source on this very page. :P

I'm at the point where I don't want to hear about anything that involves (or implies) a vendor prefix.

Vendor prefixes are no longer being used for new features - flags and preview releases are the new way browsers release draft features like this.

CSS grid level 2 is a W3C draft design which, if accepted, will make its way into all browsers.

You know what I mean, it's why I included "implies."

I feel like flexbox works better for how I think about building apps in that I'm usually working on one feature at a time, not "laying out" an entire 2d page at once.

Use what you think is right for the job, I have found many uses for grid in the last year that make web development a lot less migraine inducing.

Flexbox is easier, but I think grid produces better results

Flexbox is 1 dimensional vs grid which is 2. Use both. I just implement a Kanban type of UI at work. The main layout uses grid and the cards itself uses flexbox

Should we really leave such complex logic to CSS? What if you need level 3, 4..?

"Level 2" doesn't mean you can only nest them 2 deep. It's just a newer version of the specification

Reply on news.ycombinator.com