Tags: grid

112

sparkline

Sunday, August 12th, 2018

Let’s serve everyone good-looking content

A terrific piece by Hidde, about CSS grid, but also about a much bigger question:

I don’t think we owe it to any users to make it all exactly the same. Therefore we can get away with keeping fallbacks very simple. My hypothesis: users don’t mind, they’ve come for the content.

If users don’t mind, that leaves us with team members, bosses and clients. In my ideal world we should convince each other, and with that I mean visual designers, product owners, brand people, developers, that it is ok for our lay-out not to look the same everywhere. Because serving good-looking content everywhere is more important than same grids everywhere.

Tuesday, July 31st, 2018

How Do We Keep Up? What Happens if CSS Grid Changes? - YouTube

Another great video from Jen as part of her Layout Land series. This time she addresses the question of the overwhelming technology landscape for developers and where they should invest their time.

She references my most recent talk, where I’ve been drawing a distinction between “materials” (HTML, CSS, JavaScript) and “tools” (everything else).

What if CSS Grid Changes?

Friday, July 20th, 2018

Fractional. — Ethan Marcotte

Ethan’s ode to the fr unit in CSS grid.

Tuesday, July 17th, 2018

Should I try to use the IE version of Grid Layout? Revisited for 2018

Rachel follows up on my recent post about CSS grid in old IE with her thoughts.

As Jeremy notes, the usefulness of a tool like Autoprefixer is diminishing, which is a good thing. It is becoming far easier to code in a way that supports all browsers, where support means usable in an appropriate way for the technology the user has in front of them. Embrace that, and be glad for the fact that we can reduce complexity based on the increasing interoperability of CSS in our browsers.

Friday, July 13th, 2018

CSS grid in Internet Explorer 11

When I was in Boston, speaking on a lunchtime panel with Rachel at An Event Apart, we took some questions from the audience about CSS grid. Inevitably, a question about browser support came up—specifically about support in Internet Explorer 11.

(Technically, you can use CSS grid in IE11—in fact it was the first browser to ship a version of grid—but the prefixed syntax is different to the standard and certain features are missing.)

Rachel gave a great balanced response, saying that you need to look at your site’s stats to determine whether it’s worth the investment of your time trying to make a grid work in IE11.

My response was blunter. I said I just don’t consider IE11 as a browser that supports grid.

Now, that might sound harsh, but what I meant was: you’re already dividing your visitors into browsers that support grid, and browsers that don’t …and you’re giving something to those browsers that don’t support grid. So I’m suggesting that IE11 falls into that category and should receive the layout you’re giving to browsers that don’t support grid …because really, IE11 doesn’t support grid: that’s the whole reason why the syntax is namespaced by -ms.

You could jump through hoops to try to get your grid layout working in IE11, as detailed in a three-part series on CSS Tricks, but at that point, the amount of effort you’re putting in negates the time-saving benefits of using CSS grid in the first place.

Frankly, the whole point of prefixed CSS is that is not used after a reasonable amount of time (originally, the idea was that it would not be used in production, but that didn’t last long). As we’ve moved away from prefixes to flags in browsers, I’m seeing the amount of prefixed properties dropping, and that’s very, very good. I’ve stopped using autoprefixer on new projects, and I’ve been able to remove it from some existing ones—please consider doing the same.

And when it comes to IE11, I’ll continue to categorise it as a browser that doesn’t support CSS grid. That doesn’t mean I’m abandoning users of IE11—far from it. It means I’m giving them the layout that’s appropriate for the browser they’re using.

Remember, websites do not need to look exactly the same in every browser.

How to build complicated grids using CSS grid

A nice walkthrough of a CSS grid in production. I was surprised to see percentages used as units—I wonder if it would feel “cleaner” if they were converted to fr units?

Tuesday, June 26th, 2018

The Layouts of Tomorrow | Max Böck - Frontend Web Developer

A walkthrough of the process of creating a futuristic interface with CSS (grid and animation).

While this is just one interpretation of what’s possible, I’m sure there are countless other innovative ideas that could be realized using the tools we have today.

Saturday, June 23rd, 2018

New tools for art direction on the web

I’m in Boston right now, getting ready to speak at An Event Apart. This will be my second (and last) Event Apart of the year—the other time was in Seattle back in April. After that event, I wrote about how inspired I was:

It was interesting to see repeating, overlapping themes. From a purely technical perspective, three technologies that were front and centre were:

  • CSS grid,
  • variable fonts, and
  • service workers.

From listening to other attendees, the overwhelming message received was “These technologies are here—they’ve arrived.”

I was itching to combine those technologies on a project. Coincidentally, it was around that time that I started planning to publish The Gęsiówka Story. I figured I could use that as an opportunity to tinker with those front-end technologies that I was so excited about.

But I was cautious. I didn’t want to use the latest exciting technology just for the sake of it. I was very aware of the gravity of the material I was dealing with. Documenting the story of Gęsiówka was what mattered. Any front-end technologies I used had to be in support of that.

First of all, there was the typesetting. I don’t know about you, but I find choosing the right typefaces to be overwhelming. Despite all the great tips and techniques out there for choosing and pairing typefaces, I still find myself agonising over the choice—what if there’s a better choice that I’m missing?

In this case, because I wanted to use a variable font, I had a constraint that helped reduce the possibility space. I started to comb through v-fonts.com to find a suitable typeface—I was fairly sure I wanted a serious serif.

I had one other constraint. The font file had to include English, Polish, and German glyphs. That pretty much sealed the deal for Source Serif. That only has one variable axis—weight—but I decided that this could also be an interesting constraint: how much could I wrangle out of a single typeface just using various weights?

I ended up using font weights of 75, 250, 315, 325, 340, 350, 400, and 525. Most of them were for headings or one-off uses, with a font-weight of 315 for the body copy.

(And can I just say once again how impressed I am that the founding fathers of CSS were far-sighted enough to keep those font weight ranges free for future use?)

Getting the typography right posed an interesting challenge. This was a fairly long piece of writing, so it really needed to be readable without getting tiring. But at the same time, I didn’t want it to be exactly pleasant to read—that wouldn’t do the subject matter justice. I wanted the reader to feel the seriousness of the story they were reading, without being fatigued by its weight.

Colour and type went a long way to communicating that feeling. The grid sealed the deal.

The Gęsiówka Story is mostly one single column of text, so on the face of it, there isn’t much opportunity to go crazy with CSS Grid. But I realised I could use a grid to create a winding effect for the text. I had to be careful though: I didn’t want it to become uncomfortable to read. I wanted to create a slightly unsettling effect.

Every section element is turned into a seven-column grid container:

section {
    display: grid;
    grid-column-gap: 2em;
    grid-template-columns: 2em repeat(5, 1fr) 2em;
}

The first and last columns are the same width as the gutters (2em), effectively creating “outer” gutters for the grid. Each paragraph within the section takes up six of the seven columns. I use nth-of-type to alternate which six columns are used (the first six or the last six). That creates the staggered indendation:

section > p {
    grid-column: 1/7;
}
section > p:nth-of-type(even) {
    grid-column: 2/8;
}

Staggered grid.

That might seem like overkill just to indent every second paragraph by 4em, but I then used the same grid dimensions to layout figure elements with images and captions.

section > figure {
    display: grid;
    grid-column-gap: 2em;
    grid-template-columns: 2em repeat(5, 1fr) 2em;
}

Then I can lay out differently proportioned images across different ranges of the grid:

section > figure.landscape > img {
    grid-column: 1/5;
}
section > figure.landscape > figcaption {
    grid-column: 5/8;
}
section > figure.portrait > img {
    grid-column: 1/4;
}
section > figure.portrait > figcaption {
    grid-column: 4/8;
}

Because they’re positioned on the same grid as the paragraphs, everything lines up nicely (and yes, if subgrid existed, I wouldn’t have to redeclare the grid dimensions for the figures).

Finally, I wanted to make sure that the whole thing could be read offline. After all, once you’ve visited the URL once, there’s really no reason to make any more requests to the server. Static documents—and books—are the perfect candidates for an “offline first” approach: always look in the cache, and only go to the network as a last resort.

In this case I used a variation of my minimal viable service worker script, and the result is a very short set of instructions. There’s a little bit of pre-caching going on: I grab the variable font and the HTML page itself (which includes the CSS inlined).

So there you have it: variable fonts, CSS grid, and service workers: three exciting front-end technologies, all of which can be applied as progressive enhancements on top of the core content.

Once again, I find that it’s personal projects that offer the most opportunities to try out new or interesting techniques. And The Gęsiówka Story is a very personal project indeed.

Wednesday, June 13th, 2018

Your Brain on Front-End Development | CSS-Tricks

I find this soooo relatable:

I know when I look at a design (heck, even if I know I’m not going to be building it), my front-end brain starts triggering all sorts of things I know will be related to the task.

Difference is, Chris comes up with some very, very clever techniques.

Tuesday, June 12th, 2018

Resilient, Declarative, Contextual

This is really good breakdown of what’s different about CSS (compared to other languages).

These differences may feel foreign, but it’s these differences that make CSS so powerful. And it’s my suspicion that developers who embrace these things, and have fully internalized them, tend to be far more proficient in CSS.

Tuesday, May 29th, 2018

CSS Grid — Responsive layouts and components – Deemaze Writing Wall – Medium

Rafaela Ferro has written a good case study on Ev’s blog of using CSS grid to build some practical image-based responsive components.

Getting Started With CSS Layout — Smashing Magazine

Rachel gives a terrific explanation of CSS layout from first principles, starting with the default normal flow within writing systems, moving on to floats, then positioning—relative, absolute, fixed, and sticky—then flexbox, and finally grid (with a coda on alignment). This is a great primer to keep bookmarked; I think I’ll find myself returning to this more than once.

Saturday, May 19th, 2018

Super-powered layouts with CSS Variables + CSS Grid by Michelle Barker on CodePen

This article is about using custom properties and CSS grid together, but I think my favourite part is this description of how custom properties differ from the kind of variables you get from a preprocessor:

If you’re familiar with Javascript, I like to think of the difference between preprocessor variables and CSS Variables as similar to the difference between const and let - they both serve different purposes.

Sunday, May 6th, 2018

CSS Grid: More flexibility with minmax() by Michelle Barker on CodePen

A good use case for using minmax with CSS grid to dispense with a media query.

Thursday, May 3rd, 2018

Good griddance

I’m not great at estimation, but I still try to do it on any project I’m working, even if it’s just for my own benefit. I break down different bits of the work, and ask myself two questions:

  1. How important is this?
  2. How long will it take?

If I were smart, I’d plot the answers on a graph. I start doing the important stuff, beginning with whatever won’t take too long. Then I’ve got a choice: either do the stuff that’s not all that important, but won’t take long—or do the stuff that will take quite a while, but is quite important. Finally, there’s stuff that’s not important and will take quite a while to do. I leave that to the end. If it never ends up getting done, it’s not the end of the world.

I guess it’s not really about estimation; it’s more about prioritisation.

Anyway, I’m working on a fun little project right now—the website for one of Clearleft’s many excellent events. There was one particular part of the design that I had estimated would take quite a while to do, so I didn’t get around to it until today. It was a layout that I figured would take maybe half a day of wrangling CSS.

I used CSS grid and I was done in five minutes. That’s not an exaggeration. It was literally five minutes.

I thought to myself, “Well, I want these elements to be arranged in two rows of three columns, but I want that particular one to always be in the last column of the top row.”

Normally my next step would be to figure out how to translate those wishes into floats and clears, or maybe flexbox. But this time, there was almost no translation. I could more or less write the CSS like I would write English.

I want these elements to be arranged in rows of three columns.

display: grid;
grid-template-columns: 1fr 1fr fr

I want that particular one to always be in the last column of the top row.

grid-row: 1;
grid-column: 3;

That was it. I was done.

I think I may need to recalibrate the estimation part of my brain to account for just how powerful CSS grid is.

Wednesday, April 25th, 2018

Grid to Flex

Una has put together this handy one-pager of flexbox fallbacks for some common grid layouts.

Wednesday, April 18th, 2018

Best Practices With CSS Grid Layout — Smashing Magazine

A great set of answers from Rachel to frequently asked questions about CSS grid. She addresses the evergreen question of when to use flexbox and when to use grid:

I tend to use Flexbox for components where I want the natural size of items to strongly control their layout, essentially pushing the other items around.

A sign that perhaps Flexbox isn’t the layout method I should choose is when I start adding percentage widths to flex items and setting flex-grow to 0. The reason to add percentage widths to flex items is often because I’m trying to line them up in two dimensions (lining things up in two dimensions is exactly what Grid is for).

Friday, April 6th, 2018

Understandable excitement

An Event Apart Seattle just wrapped. It was a three-day special edition and it was really rather good. Lots of the speakers (myself included) were unveiling brand new talks, so there was a real frisson of excitement.

It was interesting to see repeating, overlapping themes. From a purely technical perspective, three technologies that were front and centre were:

  • CSS grid,
  • variable fonts, and
  • service workers.

From listening to other attendees, the overwhelming message received was “These technologies are here—they’ve arrived.” Now, depending on your mindset, that understanding can be expressed as “Oh shit! These technologies are here!” or “Yay! Finally! These technologies are here!”

My reaction is very firmly the latter. That in itself is an interesting data-point, because (as discussed in my talk) my reaction towards new technological advances isn’t always one of excitement—quite often it’s one of apprehension, even fear.

I’ve been trying to self-analyse to figure out which kinds of technologies trigger which kind of reaction. I don’t have any firm answers yet, but it’s interesting to note that the three technologies mentioned above (CSS grid, variable fonts, and service workers) are all additions to the core languages of the web—the materials we use to build the web. Frameworks, libraries, build tools, and other such technologies are more like tools than materials. I tend to get less excited about advances in those areas. Sometimes advances in those areas not only fail to trigger excitement, they make me feel overwhelmed and worried about falling behind.

Since figuring out this split between materials and tools, it has helped me come to terms with my gut emotional reaction to the latest technological advances on the web. I think it’s okay that I don’t get excited about everything. And given the choice, I think maybe it’s healthier to be more excited about advances in the materials—HTML, CSS, and JavaScript APIs—than advances in tooling …although, it is, of course, perfectly possible to get equally excited about both (that’s just not something I seem to be able to do).

Another split I’ve noticed is between technologies that directly benefit users, and technologies that directly benefit developers. I think there was a bit of a meta-thread running through the talks at An Event Apart about CSS grid, variable fonts, and service workers: all of those advances allow us developers to accomplish more with less. They’re good for performance, in other words. I get much more nervous about CSS frameworks and JavaScript libraries that allow us to accomplish more, but require the user to download the framework or library first. It feels different when something is baked into browsers—support for CSS features, or JavaScript APIs. Then it feels like much more of a win-win situation for users and developers. If anything, the onus is on developers to take the time and do the work and get to grips with these browser-native technologies. I’m okay with that.

Anyway, all of this helps me understand my feelings at the end of An Event Apart Seattle. I’m fired up and eager to make something with CSS grid, variable fonts, and—of course—service workers.

Tuesday, April 3rd, 2018

Everything You Know About Web Design Just Changed by Jen Simmons

Alright! It’s time for the final talk of the day at An Event Apart Seattle (Special Edition). Jen is wrapping up a CSStastic afternoon with her talk Everything You Know About Web Design Just Changed. These are my notes…

Ready for another hour of layout in CSS? Well, Jen will be showing no code in this talk. She’s actually nervous about this particular talk. Is she really planning to say “Everything about web design just changed”? That sounds so clickbaity! But she really believes we’re at an inflection point. This may be the sixth such point in the history of the web. One of those points where everything changes and we swap out our techniques.

For the last few years, we’ve been saying that everything changed when mobile came along. But actually, the real fight has been going on for longer than that. It’s the battle between wanting art and dealing with how the web works.

There’s a seminal book called Creating Killer Websites by David Siegel from 1996. In it, he describes the first time he saw the same site in two different browsers. His reaction was panic. The web gave control to the user. David Siegel wanted more control. And that’s how we got spacer gifs and tables for layout.

What are the five major changes in the history of web design?

  1. Simple HTML. There was only one kind of layout: flow layout. There’s no CSS, but the browser is still thinking of everything has having a box. Text takes up as much space as it needs. Images take up as much space as their size. This is flow. There wasn’t much you could do until tables came along. They were created for tabular content but abused for layouts. The “We need art!” crowd used what was available to them at the time. Lots of slicing and dicing.
  2. Flash. It was hard to get HTML tables to work in multiple browsers. Flash seemed like an amazing chance to start over. And we could do things that were previously only possible in CD-ROMs. As a designer, you take an element and place it where you want to go on the stage (the UI tradition that goes all the way back to Xerox PARC). We made some crazy sites, explored a lot of possibilities, and got a lot of control. But the downside was the lack of accessibility. We went back to getting to grips with the web as its own medium. Jeffrey’s book, Designing With Web Standards, was a rallying cry to allow HTML to return to doing what it was meant to.
  3. Fluid Layouts. This was a return to the way the web always behaved—content takes up as much room as it needs to. But this time there’s a certain amount of control over how things are laid out. Still, we pretended that nobody has screens smaller than 640 pixels or bigger than 1024 pixels. We still live with the idea of fluid columns today.
  4. Fixed-Width Layouts. The “We need art!” crowd wanted more control than fluid layouts offered. We pretended that everyone’s screen was at least 640 pixels, or later 800 pixels, or later 1024 pixels.
  5. Responsive Web Design. Unveiled by Ethan at An Event Apart Seattle in 2011: flexible grid; flexible images; media queries. It’s a return to fluid layouts, but the addition of media queries gives us more control. The idea of fluid image was a bit radical. Up until that point, we thought of images as always being their intrinsic size. But something Ethan said that day was “It’s not just about layout.” And it’s true. For the last eight years, it’s been about more than layout. You set out to redesign your website and end up redesigning your whole business. Responsive web design is, frankly, what the web is now.

But let’s talk about layout. What’s next? Intrinsic Web Design.

Why a new name? Why bother? Well, it was helpful to debate fluid vs. fixed, or table-based layouts: having words really helps. Over the past few years, Jen has needed a term for “responsive web design +”.

Responsive web design has flexible images. Intrinsic web design has flexible images …or fixed images. Whichever you want.

Responsive web design has a fluid columns. Intrinsic web design has fluid columns and rows.

Responsive web design uses media queries. Intrinsic web design doesn’t necessarily need them.

The name comes from words that have been floating in the ether. In Rachel’s talk, the words “sizing” and “intrinsic” came up a lot. This is about the nature of the web.

Let’s look at images specifically. Before responsive web design, images overflow their container if they are bigger than the container. Fluid images (as used in responsive web design) shrink and grow depending on the size of their container. You can also make images fluid in a vertical direction. If we make the image fluid vertically and horizontally, the image looks distorted. But now if we use object-fit: cover we can specify how we want the image to react.

Fixed or fluid? With grid layout, you can mix fixed and fluid. You can make a layout fluid until it hits a minimum size, at which point it stays fixed.

There are four stages of squishiness:

  1. fixed
  2. fr units (fluid)
  3. minmax()(fluid until fixed)
  4. auto (a return to flow)

That’s a powerful set of tools that may take us years to explore.

We can do truly two-dimensional layouts: rows and columns. Every one of those four stages of squishiness works for rows as well as columns. This means we can create intentional white space. Jen made a video about this and got the response that this was always possible, but it’s different now: it’s more intentional. You can set heights and widths.

We can have nested contexts now:

  1. Flow
  2. Flexbox (formatting context)
  3. Grid (formatting context)
  4. Multicolumn (formatting context)

Floats never created a new formatting context, which is why used clearfix. Now we don’t need hacks. You can mix and match, choosing the best layout tool for the job at hand. You can have a grid layout that has flexbox items within it. The Firefox dev tools allow you to inspect each layout type separately. You can use the nightly build to get the latest tools.

Then we’ve got ways to contract and expand content. We have more options now. For a while, we’ve had the option to squish and grow (e.g. with fluid images). Another is wrapping and reflowing (like we can do with text). Another option now is to add and remove whitespace. Maybe the content size doesn’t need to change; the whitespace shrinks and grows instead. An even more radical option now is to have things slide behind one another and overlap deliberately.

Sometimes you don’t even need to use media queries (meaning we’ve effectively got container queries). But we can still use media queries, as needed, to tweak the details.

So intrinsic web design is:

  1. Fluid and fixed
  2. Stages of squishiness
  3. Truly two-dimensional layouts
  4. Nested contexts
  5. Expand and contract content
  6. Media queries, as needed

We have a whole new sandbox that we can play in. You can find examples at labs.jensimmons.com.

See also:

Monday, April 2nd, 2018

Fit For Purpose: Making Sense of the New CSS by Eric Meyer

Time for even more CSS goodness at An Event Apart Seattle (Special Edition). Eric’s talk is called Fit For Purpose: Making Sense of the New CSS. Here are my notes…

Eric isn’t going to dive quite as deeply as Rachel, but he is going to share some patterns he has used.

Feature queries

First up: feature queries! Or @supports, if you prefer. You can ask a browser “do you support this feature?” If you haven’t used feature queries, you might be wondering why you have to say the property and the value. Well, think about it. If you asked a browser “do you support display?”, it’s not very useful. So you have to say “do you support display: grid?”

Here’s a nice pattern from Lea Verou for detecting support for custom properties:

@supports (--css: variables)

Here’s a gotcha:

@supports (clip-path: polygon())

That won’t work because polygon() is invalid. This will work:

@supports (clip-path: polygon(0 0))

So to use feature queries, you need to understand valid values for properties.

You can chain feature queries together, or just pick the least-supported thing you’re testing for and test just for that.

Here’s a pattern Eric used when he only wanted to make text sideways, but only if grid is supported:

@supports (display: grid) {
    ...
    @supports (writing-mode: sideways-lr) {
        ...
    }
}

That’s functionally equivalent to:

@supports (display: grid) {
    ...
}
@supports (display:grid) and (writing-mode: sideways-lr) {
    ...
}

Choose whichever pattern makes sense to you. More to the point, choose the pattern that makes sense to your future self when you revisit your code.

Feature queries need to work together with media queries. Sometimes there are effects that you only want to apply on larger viewports. Do you put your feature queries inside your media queries? Or do you put your media queries inside your feature queries?

  • MOSS: Media Outside Support Statements
  • MISO: Media Inside Supports Object

Use MOSS when you have more media switches than support blocks. Use MISO when you only have a few breakpoints but lots of feature queries.

That’s one idea that Eric has. It’ll be interesting to see how this develops.

And remember, CSS is still CSS. Sometimes you don’t need a feature query at all. You could just use hanging-punctuation without testing for it. Browsers that don’t understand it will just ignore it. CSS has implicit feature queries built in. You don’t have to put your grid layout in a feature query, but you might want to put grid-specific margins and widths inside a feature query for display: grid.

Feature queries really help us get from now to the future.

Flexbox

Let’s move on to flexbox. Flexbox is great for things in a line.

On the An Event Apart site, the profile pictures have social media icons lined up at the bottom. Sometimes there are just a few. Sometimes there are a lot more. This is using flexbox. Why? Because it’s cool. Also, because it’s flexbox, you can create rules about how the icons should behave if one of the icons is taller than the others. (It’s gotten to the point that Eric has forgotten that vertically-centring things in CSS is supposed to be hard. The jokes aren’t funny any more.) Also, what if there’s no photo? Using flexbox, you can say “if there’s no photo, change the direction of the icons to be vertical.” Once again, it’s all about writing less CSS.

Also, note that the profile picture is being floated. That’s the right tool for the job. It feels almost transgressive to use float for exactly the purpose for which it was intended.

On the An Event Apart site, the header is currently using absolute positioning to pull the navigation from the bottom of the page source to the top of the viewport. But now you get overlap at some screen sizes. Flexbox would make it much more robust. (Eric uses the flexbox inspector in Firefox Nightly to demonstrate.)

With flexbox, what works horizontally works vertically. Flexbox allows you to align things, as long as you’re aligning in one direction. Flexbox makes things springy. Everything’s related and pushing against each other in a way that makes sense for this medium. It’s intuitive, even though it takes a bit of getting used to …because we’ve picked up some bad habits. To quote Yoda, “You must unlearn what you have learned.” A lot of the barrier is getting over what we’ve internalised. Eric envies the people starting out now. They get to start fresh. It’s like when people who never had to table layouts see code from that time period: it (quite rightly) doesn’t make any sense. That’s what it’s going to be like when people starting out today see the float-based layouts from Bootstrap and the like.

Grid

That’s going to happen with grid too. We must unlearn what we have learned from twenty years of floats and positioning. What makes it worth is:

  1. Flexbox and grid are pretty easy to get used to, and
  2. It’s amazing what you can do!

Eric quotes from an article called How We adopted CSS Grid at Scale:

…we agreed to use CSS Grid at the layout level and Flexbox at the component level (arranging child items of components). Although there’s some overlap and in some cases both could be used interchangeably, abiding by this rule helped us avoid any confusion in gray areas.

Don’t be afraid to set these kind of arbitrary limits that aren’t technological, but are necessary for the team to work well together.

Eric hacked his Wordpress admin interface to use grid instead of floats for an activity component (a list of dates and titles). He initially turned each list item into a separate grid. The overall list didn’t look right. What Eric really needed was a subgrid capability, so that the mini grids (the list items) would relate to one another within the larger grid (the list). But subgrid doesn’t exist yet.

In this case, there’s a way to fake it using display: contents. Eric made the list a grid and used display: contents on the list items. It’s as though you’re saying that the contents of the li are really the contents of the ul. That works in this particular case.

The feature queries for that looked like:

@supports (display: grid) {
    ...
    @supports (display: contents) {
        ...
    }
}

Eric is also using the grid “ASCII art” (named areas) technique on his personal site. This works independent of source order. For that reason, make sure your source order makes sense.

Using media queries, Eric defines entirely different layouts simply by using different ASCII art. He’s switching templates.

For a proposed redesign of the An Event Apart site, Eric used CSS grid as a prototyping tool. He took a PDF, sliced it up, exported JPGs, and then used grid to lay out those images in a flexible grid. Rapid prototyping! The Firefox grid inspector really helps here. In less than an hour, he had a working layout. He could test whether the layout was sensible and robust. Then he swapped out the sliced images for real content. That took maybe another hour (mostly because it was faster to re-type the text than try to copy and paste from a PDF). CSS makes it that damn easy now!

So even if you’re not going to put things like grid into production, they can still be enormously useful as design tools (and you’re getting to grips with this new stuff).

See also: