Graduating to Grid

@rachelandrew Core ideas that help CSS layout make sense . It’s the same with CSS, you can know some syntax, know how to look up things and put them in a stylesheet, but without an understanding of some core underpinnings of the language your attempts will never ﬂow, and you might sometimes end up with some of that weird heat treated milk in your co ﬀ ee.

So what are those core things today. What concepts should we know in order to really take advantage of all the new stu ﬀ coming to CSS, to be able to elegantly enhance layouts that still work well for our users who are stuck with older browsers, perform well for people with limited bandwidth.

And you may ﬁnd you kind of understand these things already but didn’t have a name for them, I’m using the names they are given in the spec as you’ll ﬁnd that my knowing what these things are and what they are called, specs will be much easier to read so you can go right to the source.

@rachelandrew ﬂ ex-direction: row Main axis Cross axis ﬂ ex-direction: column Cross axis Main
axis Flex Layout in Horizontal Writing Mode Flex layout is a little more complex in this regard because of the fact that we can have a ﬂex-direction of row or column. In ﬂexbox it makes more sense to refer to the main and cross axis.

The main axis is the one dictated by the ﬂex-direction. By default this goes along the row (and therefore the inline axis)

The cross axis runs across down the columns (the block axis).

The reasons we don’t say top to bottom and left to right are hopefully obvious in terms of how I introduced this subject. The inline axis only runs left to right if we are working in a language that runs left to right. The Block axis top to bottom only when we are in a horizontal writing mode.

@rachelandrew .col { margin-bottom: 1em; margin-left: 2.093333%; width: 6.20%; float: left; } .row::after { content: ""; display: block; clear: both; } .col.span2 { width: calc((6.20%*2) + 2.093333%); } .col.span3 { width: calc((6.20%*3) + (2.093333%*2)); } .col.span4 { width: calc((6.20%*4) + (2.093333%*3)); } https://codepen.io/rachelandrew/pen/ZXMwdB Fun math! Clearing! Percentages! We are working out the sizes of the columns plus any gutter and sticking that percentage into the CSS. As long as our percentages don’t exceed 100%, and we have wrappers around our rows to stop things in the next row popping up onto this row, we get something that looks like a grid.

Looks like a grid being the key thing, it only looks like a grid because we have carefully worked out these sizes, as long as we keep doing that on each row the things line up.

@rachelandrew Percentages • Ugly • Easy to understand • If they total more than 100% bad things happen. • Can be converted from an ideal pixel size using a straightforward calculation. And percentages, while they look horrible in our CSS, and aren’t exactly fun to calculate are understandable. We can work out what percentage value we need to pop in, based on an ideal pixel size using the method Ethan Marcotte taught us in his seminal piece on responsive design.

We understand that if we have more than 100% bad things will happen to our layout.

By doing the work to ﬁgure this stu ﬀ out, either with a calculator on our desk or allowing some tool or framework to have ﬁgured it out for us, we are in control.

One of the nice features of new layout, of ﬂexbox and grid is that they can take away a lot of the pain of calculating this stu ﬀ , but in doing so we start to run into the under the hood sizing constructs that they are built upon, and they seem confusing when compared to good old percentages, and the temptation is to return to our familiar methods.

@rachelandrew CSS Intrinsic and Extrinsic Sizing https://drafts.csswg.org/css-sizing-3/

However this new world brings new challenges and sizing that suddenly starts to seem more complex than the ugly but understandable percentage.

So let’s look at our new world of sizing. Let’s have a look at the impossible to say on stage speciﬁcation - CSS Intrinsic and Extrinsic sizing. This is the speciﬁcation that details exactly how big that thing is.

It deals with the Intrinsic size of things, which is the size their content would have them ignoring any external inﬂuences, such as a parent item restricting their width.

It deals with the** Extrinsic** size of things, which is the size they are based on external inﬂuences such as a parent element having a width and constraining it.

@rachelandrew https://codepen.io/rachelandrew/pen/KXGbQo/ Items start by trying to display at max-content size. Space is reduced according to the ﬂ ex- basis. In this case the size of the content. However if we added more content to one item then the smaller items start to collapse and end up at min-content size.

How does ﬂexbox work this out?

It starts from the max-content size which is what you can see from the ﬁrst image. We have enough room and then some for our items so they display at max-content.

Once we add all of our content, then there isn’t enough space for all the items to display at max-content and so ﬂexbox starts to remove space from all of the items, and it does so in proportion according to their ﬂex basis, which by default is auto which means in this case it looks at the content size. Therefore our item with the longest text loses less space than the smaller items. However they will never shrink smaller than min-content size.

@rachelandrew https://codepen.io/rachelandrew/pen/KXGbQo/ Items can grow and shrink so stretch to ﬁ ll the container. With no extra space, items shrink as before. flex: 1 1 auto; The answer to controlling this behaviour is to use the ﬂex-grow ﬂex-shrink and ﬂex-basis properties. And now you know something about sizing they make more sense.

For example, if you want the items to ﬁll the container when there is extra space available. You could use a ﬂex grow of 1, ﬂex shrink of 1 and a ﬂex basis of auto. In the ﬁrst case where we have extra space, and the items are pretty much the same size, we get what appears to be 4 equal size items.

The second case hasn’t changed - because there is no extra space, we’re still reducing space from auto just like before.

@rachelandrew https://codepen.io/rachelandrew/pen/jGRzzv/ Min 50px   Max auto This who layout is in a single grid. The two columns on the right are spanning the 5 rows of the explicit grid and use multicol inside the wider 3fr grid column.

The second row has a minimum size of 50 pixels. However the content in the second column, second row is taller than 50 pixels so it expands.

And it is worth remembering that in a two dimensional model this expansion is going to happen right across the row.

There is a gap between our 2nd and third image. Thats a minimum of 50 pixels, plus the grid gap. If we added text in between the two images it would expand due to auto.

However the row will also expand if the multicol section becomes taller. It spans across all of the rows of the grid so additional space needs to be added to tracks to cope with that.

@rachelandrew More capability & ﬂ exibility means   more to learn Sadly it is a fact of life that if something is made more ﬂexible and capable, there will be more of it to learn.

There are a whole bunch of properties deﬁned in the grid speciﬁcation, add to those all the things that are part of sizing or Box Alignment and I can see why it all looks overwhelming.

However it is worth remembering that you don’t need to learn all of it, and in fact many features of grid are just di ﬀ erent ways to achieve the same end result. In order that they can ﬁt into di ﬀ erent workﬂows.

Yet once you have switched your mind set to a grid way of thinking, to an understanding that we deﬁne things on the container rather than pushing items around to make it look like a grid it all becomes a lot clearer.

And even with the apparent multitude of ways to position items there is something pretty key to understand.

@rachelandrew @mixin gridded($type: grid, $col: 20em, $gap: 20px ) { @if ($type == 'flex') { display: flex; flex-wrap: wrap; margin-left: -#{$gap} ; > * { flex: 1 1 $col; margin: 0 0 $gap $gap; } } @if ($type == 'grid') { display: grid; grid-template-columns: repeat(auto-fill, minmax($col,1fr)); grid-gap: $gap; } @if ($type == 'multicol') { column-gap: $gap; column-width: $col; }
} https://codepen.io/rachelandrew/pen/dVEojr/ And here it is. It night look a little obscure especially if you don’t use Sass, but what we have is a Sass Mixin called “gridded”.

I pass it a type of layout - grid, ﬂex or multicol plus some information about the size I’m aiming for, for the tracks, ﬂex items or columns plus the gaps between them. It then creates my CSS. The ﬂex output is the most complicated as I need to deal with the current lack of the column-gap property in ﬂexbox, plus create a rule for the ﬂex items rather than doing everything on the parent as I do for grid and multicol.

@rachelandrew Working with less capable browsers. These may not always be old browsers . Now, I need to come to the issue of browser support because if I don’t talk about it here now, you are going to come and talk to me about it later.

In 2006, Yahoo - who at the time had many of the leading minds on the web working for them published chart and a blog post written by Nate Koechley detailed something they called Graded Browser Support. This was a companion to the YUI - Yahoo User Interface library - which had been made available and was a way to explain the browser support choices being made.

Graded Browser Support categorised browsers into up to date modern browsers - the ones that should get all of the features included in YUI, ancient browsers which should receive a simpler experience and experimental or unknown browsers. The GBS was updated quarterly, with browsers being removed from class A as they became older.

How GBS was actually implemented at Yahoo changed over the years, however the fact that this approach was backed with all the data that Yahoo had was really important.

@rachelandrew Create complex layouts for browsers that support them with a few lines of CSS . And because our new layout methods are elegant, work with feature queries and are designed to overwrite older layout methods, adding that support adds just a few lines of CSS which isn’t going to have a huge impact on a browser that doesn’t get the grid layout version.

By using your skills in layout, you can start out by creating simpler experiences for mobile browsers, for more limited browsers and devices and then with a few lines of CSS turn on a fancy grid layout for those browsers with support.

Those few lines of code will not cause a problem to those limited devices. What will cause them a problem is if you then attempt to load in a who heap of JavaScript to give them the fancy layout.

Being able to do cool new stu ﬀ is great, being able to save developer time is great.