Posts in the Design Category

Headings and Labels

Published 8 months, 3 days ago

Following on my last two posts about accessibility improvements to meyerweb, I’ve made two more adjustments: better heading levels and added ARIA labels.

For the heading levels, the problem I face is one familiar to many authors: what makes sense as an <h1> in some situations needs to be an <h2> in others.  The most common example is the titles of blog posts like this one.  On its permalink page, the title of the page is the title of the post.  There, it should be an <h1>.  On archive pages, including the home page of meyerweb, there are a number of posts shown one after the other.  In those situations, each post title should be an <h2>.

Part of the redesign’s changes were to write a single PHP routine that generated posts and their markup, which I could then simply call from wherever.  So I added an optional function parameter that allowed me to indicate the context in which a post was being placed.  It goes something like this:

<?php blogpostMarkup("archive"); ?>
function blogpostMarkup($type = "standalone") {
    if ($type == "archive") $titletag = "h2"; else $titletag = "h1";
    // …markup is all generated here…
    echo $output;
}

Or code to that effect.  (I did not go copy-paste from my actual code base.)

So now, heading levels are what they should be, at least on most pages (I may have missed updating some of my old static HTML pages; feel free to point them out in the comments if you find one).  As a part of that effort, I removed the <h1> from the masthead except on the home page, being the one place it makes sense to be an <h1>.

As for ARIA labels, that came about due to a comment from Phil Kragnes on my last post, where he observed that pages often have multiple elements with a role of navigation.  In order to make things more clear to ARIA users, I took Phil’s suggestion to add aria-label attributes with clarifying values.  So for the page-top skiplinks, I have:

<nav role="navigation" aria-label="page" id="skiplinks">

Similarly, for the site-navigation bar, I have:

<nav role="navigation" aria-label="site" id="navigate">

The idea is that screen readers will say “Page navigation region” and “Site navigation region” rather than just repeating “Navigation region” over and over.

Other than cleaning up individual pages’ heading levels and the occasional custom layout fix (e.g., the Color Equivalents Table needed a local widening of the content column’s maximum size), I think the redesign has settled into the “occasional tinkering” phase.  I may do something to spruce up my old Web Review articles (like the very first, written when HTML tags were still uppercase!) and I’m thinking about adding subnavigation in certain sections, but otherwise I think this is about it.  Unless I decide to go really over the top and model my Tools page after Simon St. Laurent’s lovely new Grid design, that is…

Of course, if you see something I overlooked, don’t hesitate to let me know!  I can’t guarantee fast response, but I can always guarantee careful consideration.


Increasing Accessibility

Published 8 months, 1 week ago

Thanks to the fantastic comments on my previous post, I’ve made some accessibility improvements.  Chief among them: adding WAI-ARIA role values to various parts of the structure.  These include:

  • role="banner" for the site’s masthead
  • role="navigation" added to the navigation links, including subnavigation links like previous/next posts
  • role="main" for the main portion of a page
  • role="complementary" for sidebars in the blog archives
  • role="article" for any blog post, whether there are several on a page or just one

In addition, I restored skip links to the masthead of most pages (the rest will get them soon).  The links are revealed on keyboard focus, which I’m not sure I like.  I feel like these aren’t quite where they need to be.  A big limitation is the lack of :matches() (or similar) support in browsers, since I’d love to have any keyboard focus in the masthead or navigation links bring up the skip links, which requires some sort of parent selection.  I may end up using a tiny bit of enhancing Javascript to make the links’ UX more robust in JS situations, but still obviously available if JS fails.  And I may replicate them in the footer, as a way to quickly jump back up the page, especially to the navigation.

Speaking of the navigation links, they’ve been moved in the source order to match their place in the visual layout.  My instincts with regard to source order and layout placement were confirmed to be woefully out of date: the best advice now is to put the markup where the layout calls for the content to be.  If you’re putting navigation links just under the masthead, then put their markup right after the masthead’s markup.  So I did that.

The one thing I didn’t change is heading levels, which suffer all the usual problems.  Right now, the masthead’s “meyerweb.com” is always an <h1> and the page title (or blog post titles) are all <h2>.  If I demoted the masthead content to, say, a plain old <div>, and promoted the post headings, then on pages like the home page, there’d be a whole bunch of <h1>s.  I’ve been told that’s a no-no.  If I’m wrong about that, let me know!

There’s still more to do, but I was able to put these into place with no more than a few minutes’ work, and going by what commenters told me, these will help quite a bit.  My thanks to everyone who contributed their insights and expertise!


The Newwwyear Design

Published 8 months, 2 weeks ago

Well, here it is—the first new design for meyerweb since February 2005 (yes, almost 13 years).  It isn’t 100% complete, since I still want to tweak the navigation and pieces of the footer, but it’s well past the minimum-viable threshold.

My core goal was to make the site, particularly blog posts, more readable and inviting.  I think I achieved that, and I hope you agree.  The design should be more responsive-friendly than before, and I think all my flex and grid uses are progressively enhanced.  I do still need to better optimize my use of images, something I hope to start working on this week.

Things I particularly like about the design, in no particular order:

  • The viewport-height-scaled masthead, using a minimum height of 20vh.  Makes it beautifully responsive, always allowing at least 80% of the viewport’s height to be given over to content, without requiring media queries.
  • The “CSS” and “HTML” side labels I added to properly classed pre elements.  (For an example, see this recent post.)
  • The fading horizontal separators I created with sized linear gradients, to stand in for horizontal rules.  See, for example, between post content and metadata, or underneath the navlinks up top of the page.  I first did this over at An Event Apart last year, and liked them a lot.  I may start decorating them further, which multiple backgrounds make easy, but for now I’m sticking with the simple separators.
  • Using string-based grid-template-areas values to rearrange the footer at mobile sizes, and also to make the rare sidebar-bearing pages (such as those relating to S5) more robust.

There are (many) other touches throughout, but those are some high points.

As promised, I did livestream most of the process, and archived copies of those streams are available as a YouTube playlist for those who might be interested.  I absolutely acknowledge that for most people, nine hours of screencasting overlaid with rambling monologue would be very much like watching paint dry in a hothouse, but as Abraham Lincoln once said: for those who like this sort of thing, this is the sort of thing they like.

I was surprised to discover how darned easy it is to livestream.  I know we live in an age of digital wonders, but I had somehow gotten it into my head that streaming required dedicated hardware and gigabit upstream connections.  Nope: my five megabit upstream was sufficient to stream my desktop in HD (or close to it) and all I needed to broadcast was encoding software (I used OBS) and a private key from YouTube, which was trivial to obtain.  The only hardware I needed was the laptop itself.  Having a Røde Podcaster for a microphone was certainly helpful, but I could’ve managed without it.

(I did have a bit of weirdness where OBS stopped recognizing my laptop’s camera after my initial tests, but before I went live, so I wasn’t able to put up a window showing me while I typed.  Not exactly a big loss there.  Otherwise, everything seemed to go just fine.)

My thanks to everyone who hung out in the chat room as I livestreamed.  I loved all the questions and suggestions—some of which made their way into the final design.  And extra thanks to Jen Simmons, who lit the fire that got me moving on this.  I enjoyed the whole process, and it felt like a great way to close the books on 2017.


A Meyerweb Makeover

Published 8 months, 4 weeks ago

This coming week, I’m going to redesign meyerweb.com—which will be its first redesign in twelve and a half years.

I’m doing this as part of Jen Simmons’ #newwwyear initiative.  As Jen put it:

Ok, here’s the deal. Tweet your personal website plan with the hashtag #newwwyear (thanks @jamiemchale!): 1) When will you start? 2) What will you try to accomplish? 3) When is your deadline? Improve an existing site. Start a new one. Burn one down & start over. It’s up to you.

Many of us feel bad about our personal websites. Me included. We keep meaning to make one, improve what’s there, or burn it down and start over. We are busy. Afraid. Overwhelmed. Well, let’s do it. Maybe over the holidays. Maybe after, in the New Year. #newwwyear

On Friday, I announced my plan:

  1. I’ll start Wednesday, December 27th.
  2. I’ll redesign http://meyerweb.com  for the first time in a dozen years, and I’ll do it live on the production site.
  3. My deadline is Wednesday, January 3rd, so I’ll have a week.

I won’t be redesigning all day every day—I still have paying work to do, after all—but I’ll do my best to put in a couple of hours each weekday.

When say I’ll do it live, I mean I’ll be making all my changes here on the production site, with minimal or no testing beforehand—literally opening the style sheet(s) into BBEdit via Transmit, and saving changes up to the server to see what happens.  Stuff will break, and then I’ll fix it, live in the public eye.  It’s possible I’ll try out new ideas and then junk them before moving on to others.  I’m hoping that accidents spark inspiration, as they often do.

(There will be a local copy of the site in case things go so badly that I need to reset to the starting point.  I’m not completely insane, after all.)

I have a vague plan with all this, which is: realign the site’s appearance to be more inviting, more readable, and more visually engaging.  I do have a few past experiments that I’ll fold in, like using relative times (e.g., “Two months ago”) on posts, but a lot of this will be me doing free-association design.  And hopefully a little markup cleanup and enhancement as well.

I’m sticking with WordPress to drive the blog, given that it contains close to two decades of posts and makes it easy to allow comments, a feature I still value; and my hand-built old-school-standards-punk mostly-static templating system for the rest of the site, which let the site be static(ish) way before static was cool.  (No, I will not consider migrating to other CMSes or template systems: with a week set aside for this, I won’t have the time.)

So, that’s the plan: a week for a meyerweb makeover.  I don’t know if I’ll keep up a running commentary on Twitter while I do, or if I’ll take breaks and blog short entries chronicling my progress, or what.  If someone sets up a #newwwyear Slack team, I’ll probably join in.  If the #newwwyear idea excites you, I hope you’ll join in too!


Gridded Headings v. Justified Headings

Published 1 year, 4 months ago

Amongst the reactions to Gridded Headings, Benjamin de Cock pointed out there’s another way to arrive at the same place I did.  Instead of this:

grid-template-columns:
    minmax(1em,1fr)
    minmax(min-content,max-content)
    minmax(1em,1fr);

…Benjamin pointed out one could instead do this:

justify-content: center;

That’s right: without explicitly specifying any grid columns, but just setting the grid items themselves to be centered, the same behaviors emerge.  Clever!

What’s interesting is that the behaviors are not precisely the same.  While mostly identical behaviors occur with either approach, there are a few subtle differences and a much different possibility space.  I’ll consider each in turn.

First, the differences.  First of all, the small gutters defined by the first and third grid column tracks—the ones defined to be minmax(1em,1fr)—aren’t present in the justify-content version.  This means the headings will jam right up against the edge of the grid container if things get narrow enough.

Side separation versus side smashing.  Grid on the left, justify-content on the right.

So we either need to re-establish them with grid-template-columns, which would seem to put us right back where we were, or else apply side margins to the heading and subheading.  Something like this:

div h2, div h3 {margin-right: 1rem; margin-left: 1rem;}

Either way, that side separation has to be defined (assuming you want it there).  Having to set those separations as margins feels a little clumsy to me, though not hugely so.  Doing all the sizing and separation in a single grid-template-columns declaration feels cleaner to me, though I admit that may be partly due to my current Gridfatuation.

There is another difference worth exploring.  If the content gets wider than the space available, the grid-template-columns approach means the content will overflow to the right (in LTR writing modes).  If it falls offscreen, it can be scrolled to read.  With justify-content: center, the content stays centered within the box, overflowing to both sides.  The content to the left may not be accessible via scrollbar.

How track sizing and content justification handle overspill.  Grid on the left, justify-content on the right.

So if you have a large headline containing a lengthy unhyphenated word, like “Kazakhstan” or “emoluments”, you might prefer one result over the other.

Beyond that, the further possibilities are a lot richer with Grid than with content justification.  Center-justifying the content means exactly that: the element boxes are centered.  So if you were interested in taking the heading and subheading, acting as an apparent unit, and shift them toward one side or another, this would be much easier to accomplish with Grid.

Suppose we want there to be three times as much space to one side of the headings’ column as the other.  Here’s what that would look like:

grid-template-columns:
    minmax(1em,1fr)
    minmax(min-content,max-content)
    minmax(1em,3fr);

That’s it.  One number changed, and the whole setup is offset from the center without losing the coherence of the original demo.

The same thing could likely be approximated with justify-content using side margins on the heading elements, but it wouldn’t be precisely the same, even with percentages.  fr is a very special beast, and permits very unique results.

The other major difference in possibilities is that with Grid, we can rearrange elements visually without ever touching the source.  Suppose we wanted to put the subhead above the heading in some layouts, but not others.  (Whether those different designs live on different pages or at different breakpoints, it really doesn’t matter.)  With Grid, that’s as simple as rewriting the grid template in a line or three of CSS.  The h2 remains ahead of h3 in the HTML.

With justify-content, you’d still have to write that same grid template, or else switch to flexbox and use flex-direction: column-reverse or some such.  That would work if you want to just switch the display order of two headings in a single column.  It tends to fall down for anything more demanding than that.

This is not to say Benjamin came up with a bad alternative!  I like it quite a bit, precisely because it has similar outcomes to my original idea, thus shedding light on creative ways Grid and content alignment can be combined.  But I like it even more for its differences, which shed even more light on how the two things operate.

In that combination of similarity and difference, I can sense an incredible range of capability, chock full of nuance and brimming with possibility.  There are going to be ways to put these things together that nobody has figured out yet.  I know I keep saying this, but there’s a vast landscape opening, so vast that I don’t think we can even guess how far it extends yet, let alone have mapped its terrain.


Gridded Headings

Published 1 year, 4 months ago

In my ongoing experiments with both a realignment of meyerweb’s design and CSS Grid, I came up with an interesting heading-and-subheading technique I’d like to share.  It allows two elements to be centered as a block, while letting them text-align with respect to each other, while still line-wrapping if necessary.

Here’s a little demobox.

These Are Grid Headings

A useful technique

Boxes and Alignment

It’s the new hotness

Cool

This is pretty darned easy to implement

Gridded Headings

Wednesday, 19 May 2017

Each heading-subheading pair is composed of two heading elements wrapped in another element.  The wrapping element is the grid container for the headings, each of which become grid items.  This is the markup I used:

<div>
    <h2>These Are Grid Headings</h2>
    <h3>A useful technique</h3>
</div>

If you resize your browser window, or select the “Narrow” option, you should see that the boxes surrounding the headings stays as wide as the wider of the two headings.  It “shrink-wraps” them, visually speaking.  In addition, those boxes stay centered within the grid container.

Furthermore, given the demo’s defaults, the two headings are left-aligned with respect to each other.  You can change this: for example, if you choose to “Center-align headings”, the h2s will center when they’re shorter than the subheadings (the h3s).  On the other hand, if you select “Right-align subheads”, then the subheads will right-align themselves with respect to the headings whenever the subhead is shorter in length.

That was actually a bit misleading: if the headings are centered, they’re centered whether or not they’re shorter than the subhead.  It’s just that, if they’re longer, you can’t see that they’re centered, because left-, center-, and right-aligning them has the same effect.  Ditto for right-aligning the subheads: if they’re longer, they sit in the same place regardless of their text alignment.

The alignments hold even when line-wrapping kicks in.  Try narrowing things down to the point that the text starts wrapping.  If you’re having trouble visualizing the two elements, turn on “Separate backgrounds” to given the heads and subheads visually distinct background colors.

So: a centered box as wide as the longest of the two elements, inside which they can align themselves with respect to each other.  Here’s the CSS that makes this possible:

display: grid;
grid-template-columns:
    minmax(1em,1fr)
    minmax(min-content,max-content)
    minmax(1em,1fr);

That’s pretty much it.  The first and third grid tracks are set to be a minimum of 1em, and a maximum of 1fr.  Given the second track (which I’ll get to in a moment), this means the two tracks will split any free space within the grid container, down to a minimum of 1em.  That’s how the centering of the box work; or, if you turn off “Boxes”, how the unbounded text sticks together in the center of the layout area.

That second track, minmax(min-content,max-content), is what makes all the unusual aspects of this possible.  What that says is: “make this grid track no narrower than the narrowest of the grid items in the track, and no wider than the widest grid item”.  In practice, it’ll most likely be as wide as its widest element.

But if I just said max-content (without having the minmax() and min-content parts) for that track width, the track would always be as wide as the widest element at its widest possible layout, which in this case means without line-wrapping the contents.  That would force particularly long headings to run outside of the track, and possibly out of the grid container altogether.  You can see this by enabling “Remove minmax” and narrowing things until text lines should wrap.

It’s the minmax(min-content,max-content) that avoids this fate, because that means that while the grid track (the column the head and subhead share) can’t get any wider than the widest element it contains, it’s allowed to get narrower.  Thus, if the grid container gets too narrow to fit all the grid items’ maximum widths, the contents of the grid items are able to line-wrap, thus avoiding overspill.  In fact, the grid items can keep getting more narrow until they reach min-content, which is to say, the narrowest the track can get without having content of any grid item stick out of the track.  Then it will stop shrinking.

And finally, if you want to see how the options you’ve selected will look in a Gridless browser, select “Remove grids” and see what happens.  Some combinations may not be palatable without Grid, but remember: you can always use @supports(display: grid) to quarantine any styles that are particularly egregious in older UAs.

So there you have it.  While I’m not certain the Grid drop quotes I wrote about last month will be used in the final version of my styles—I’m still looking to see if they’ll fit with more than 17 years of vaguely ad-hoc markup patterns—it’s pretty close to certain I will use these headings, minus the boxes.  I think they’re a neat effect for blog post titles and dates.

Addendum: As of May 2017, WebKit browsers (e.g. Safari) require vendor prefixes for the min-content and max-content keywords.


Grid Drop Quotes, Revisited

Published 1 year, 5 months ago

In last week’s Grid-Powered Drop Quotes, I overlooked a potential problem with the styles I created.  Fortunately, Philippe Wittenbergh caught it and pointed it out, and we both hit on the same solution.

The problem-in-waiting is that the big drop quote will force a gap between the first child element of the blockquote and the second, if the first child is short.  You can see this in the demo below (external version also available), where I made the first paragraph only a few words long.  If you select the “Borders” option, you can see the problem more clearly.

Besides, Grid was coming.

In the run-up to Grid support being released to the public, I was focused on learning and teaching Grid, creating test cases, and using it to build figures for publication.  And then, March 7th, 2017, it shipped to the public in Firefox 52.  I tweeted and posted an article and demo I’d put together the night before, and sat back in wonderment that the day had finally come to pass.  After 20+ years of CSS, finally, a real layout system, a set of properties and values designed from the outset for that purpose.

And then I decided, more or less in that moment, to convert my personal site to use Grid for its main-level layout.  It took me less than five minutes…

The solution is to have the drop quote span multiple rows.  The original CSS went something like this, simplified for the sake of clarity:

blockquote::before {
    grid-column: 1;
    content: "“";
    font-size: 5em;
}

That suffices to drop the drop quote into column 1 (explicitly) and row one (implicitly).  The row is as tall as the tallest of the grid items it contains, so in this case, the quote controls the row height.

The fix:

blockquote::before {
    grid-row: 1 / span 10;
    grid-column: 1;
    content: "“";
    font-size: 5em;
}

You can see that effect by enabling the “Row span” option.  I recommend trying it first with borders turned on, just to see how the element boxes change.

But wait!  Why span 10?  There aren’t that many rows in the blockquote, because there aren’t that many child elements!  That’s okay: the extra rows will be auto-created, but because they contain no content, the rows are of no height.  This means that in cases where there’s a blockquote with a lot of short child elements—think a passage of snappy dialogue—the pseudo-element will have more than enough spannability.  I could’ve gone with span 5 or similar, to echo the font sizing of the drop quote, but no sense risking having too little spannability.  (Which is a word I made up, then discovered it seems to have a meaning in mathematics, so I hope I’m not implying some sort of topological set unity of something.)

Auto-row generation may seem like dark magic, but you’re already soaking in it: remember how none of the blockquote’s child elements are explicitly given a row number, nor did I define rows with the grid-template-rows property?  That means they’re all auto-created rows.  This means if you do something like specify grid-auto-rows: 1em, then all the rows will be one em tall, with the contents spilling out and overlapping with each other.  For extra fun, try setting your auto row height to 0px instead!  (Warning: do not attempt where prohibited by law.)

The other thing Philippe pointed out was that in cases where the blockquote has only a single child element that’s one or two lines tall, the drop quote will not only set the height of the row, but the entire grid.  You can create this situation by selecting the “Short quote” option; again, I recommend leaving “Borders” enabled so you can see what’s happening.

Philippe’s proposal was to bring the line-height of the drop quote to nothing or almost nothing, and add some top margin to make up the difference.  For example:

blockquote::before {
    grid-column: 1;
    content: "“";
    font-size: 5em;
    line-height: 1px;
    margin-top: 0.33em;
}

This certainly works, as you can see by selecting the “Line height” option.  My concern is that having a great big drop quote next to a single-line blockquote is…not optimal.  I’d be more inclined to add a class for short blockquotes, and then restrict the drop quote effect to blockquotes without that class.  For example:

blockquote:not(.short)::before {
    grid-column: 1;
    content: "“";
    font-size: 5em;
}

That removes the need to fiddle with line heights and top margins, in exchange for remembering to class appropriately.  That’s a fair trade as far as I’m concerned.  Your preference may vary, of course.

Many thanks to Philippe for pointing out the error and proposing solutions!


Grid-Powered Drop Quotes

Published 1 year, 5 months ago

I’ve been experimenting with CSS Grid for various layout treatments—not high-level, whole-page layouts, but focused bits of design.  I’d like to share one of them for a few reasons.  Partly it’s because I like what I came up with.  More importantly, though, I think it illustrates a few principles and uses of CSS Grid that might not be immediately intuitively obvious.

First, here’s an interactive demo of the thing I’m going to be talking about.  You can use the checkboxes to alter aspects of the example, whether singly or in combination.  Feel free to fiddle with them before reading the rest of the article, or but you’ll probably want to come back to the demonstration as you read.  There’s also an external version of the demo as a standalone file, if you prefer opening it in a new tab and flipping back and forth.

So that’s how things have been laid out since the middle of 2005, more or less. I fiddled with a flexbox layout at one point as an experiment, but never shipped it, because it felt clumsy to be using a one-dimensional layout tool to manage a two-dimensional layout. I probably should have converted the navigation bar to flexbox, but I got distracted by something else and never returned to the effort.

Besides, Grid was coming. In the run-up to Grid support being released to the public, I was focused on learning and teaching Grid, creating test cases, and using it to build figures for publication.  And then, March 7th, 2017, it shipped to the public in Firefox 52.  I tweeted and posted an article and demo I’d put together the night before, and sat back in wonderment that the day had finally come to pass.  After 20+ years of CSS, finally, a real layout system, a set of properties and values designed from the outset for that purpose.

And then I decided, more or less in that moment, to convert my personal site to use Grid for its main-level layout.  It took me less than five minutes…

Let’s dig in!  The core concept here is a Grid-powered version of the big drop-quote on the left side, there, which is a relatively common treatment for blockquotes.  To make this happen, I’ve applied display: grid to the blockquote element itself, and added the opening quote using generated content, like so:

blockquote {
   display: grid;
   grid-template-columns: -webkit-min-content 1fr;
   grid-template-columns: min-content 1fr;
}
blockquote::before {
   grid-column: 1;
   content: "“";
   font-size: 5em;
   font-weight: bold;
}

There’s more to the actual styles of both rules, but that’s the central thesis: set up a two-column grid, and generate a great big opening quote.

The first thing to note here is that generated content also generates a pseudo-element that can be styled.  You may already realize this, since it’s known we can style generated content separately from the main content of the element.  But given that, if a grid is applied to the element, then any generated content’s pseudo-element, whether ::before or ::after, will become a grid item.  You can then place it in the grid.

I first came across this concept in the comments on my ALA article “Practical CSS Grid”, where Šime proposed using generated elements as a hack to get around the inability to directly style grid cells.  Here, I’m just using one to push a quote over to the side.

Why do this, when we can already use floats or relative/absolute positioning approaches to do the same?  Because it’s not quite the same: with Grid, the column containing the drop-quote responds to any changes to the quotation symbol.  Change the font, change its size, have the preferred font fail and fall back to an unexpected face, or replace the character with an SVG image, and the first column will resize thanks to the min-content track sizing, and the actual main content of the blockquote will adjust its placement to accommodate.  That didn’t happen with earlier techniques.

And yes, there is a vendor prefix in there.  Safari’s 10.1 Grid support came with -webkit- prefixed versions of min-content, max-content, and fit-content.  So I did the old pattern of prefixed first, unprefixed second.  This should be necessary only until the next release; Safari has already dropped the prefixes in its latest Technology Preview builds.  The change apparently just didn’t quite make the cut for 10.1.  It’s sad, but it’s also temporary.

In the meantime, this does mean that if you want to restrict your Grid styles only to implementations that don’t require prefixes, use that in your feature queries:

@supports (grid-template-columns: min-content) {…}

That, as well as a number of close variants like using grid-template-rows or max-content, will keep your Grid styles away from Safari until they update their Grid support in the public release channel.

That’s all nice, but there’s a great deal more to learn!  If you use the “Border” checkbox in the demo, you’ll see a dotted red border around the drop quote’s pseudo-element.  Notice that it matches the height of the opening paragraph, not the entire height of the blockquote.  That’s because the pseudo-element and the first paragraph share a row track.  The following paragraphs are in their own row tracks.

This brings up two things to consider.  First, all the child elements of the blockquote are now grid items.  That means the drop quote’s pseudo-element, but also all the paragraphs contained by the blockquote.  The same would happen to any child elements.  We could get around that by wrapping all the contents of the blockquote in a div or something like that, but I’d rather not.  So, this grid has four grid items: the pseudo-element, and three paragraphs.

This leads us to the second consideration: without placing the paragraphs into the same column, they’ll auto-flow into whatever grid cells are available.  You can see this by selecting the “Auto placement” option.  The first column will contain the quote and the second paragraph, as narrow as they both can be due to min-content.  The second column will contain the first and third paragraphs.

How I get around this in the working version is to explicitly put all the paragraphs—really, all child elements of the blockquote, which just happen in the case to be paragraphs—into the second column, like this:

blockquote > * {grid-column: 2;}

Okay, but how do they end up stacked vertically?  After all, I didn’t assign each of those child elements to a row, did I?

Wait a minute.  What rows?

If you go back and look at the CSS I showed, there is nothing about rows.  The property grid-template-rows exists, but I didn’t use it.  All I did was define columns.

Each child element goes into a row of its own anyway, because Grid has the ability to automatically create columns or rows when needed.  Suppose you define a three-by-three grid, and then assign a grid item to the fifth column of the fourth row.  What should happen?  The browser should auto-create as many columns and rows as needed.  Any auto-created tracks will have zero width or height if they don’t contain any grid items, unless you size them using grid-auto-columns or grid-auto-rows, but we’re not going there today.  The point is, here I’ve said all of the blockquote’s child elements should go into column 2.  Given that, they’ll auto-fill rows as available and auto-create rows as needed, filling them in once they’re created.

So the blockquote in the demo above has two columns because I explicitly defined them, and three rows because that’s what it needed to create to handle the three child elements.  If I’d added two more paragraphs and an unordered list, the grid would have had two columns and six rows (because six chid elements).

There are a lot of possible extensions to this technique.  A close quote could be created using ::after and placed in the last row of the grid, thanks to the ability to use negative track values to count back from the end of the grid.  Thus:

blockquote::after {
   grid-column: 3;
   grid-row: -1;
   content: "”";
   font-size: 5em;
   font-weight: bold;   
}

That places the close-quote in the third column, so to the right of the quoted text, and in the last row, regardless of how many rows were auto-created.  Of course, there is no third column…or there wasn’t, until assigning something to the third column.  At the point, the browser created it.

The danger there is that the auto-generated column is essentially tacked on to the trailing edge of the grid, without real consideration for what might be in the way—up to and including the edge of the viewport. Rather than auto-generate the column, we could define a third column like so:

grid-template-columns: min-content 1fr min-content;

This sets up a column on each side of the grid, one for each of the big quotes.  The second column, the one that gets all the actual child elements of the blockquote, receives all the space left over after those outer columns are sized, thanks to its 1fr value.

There’s one more drawback here, albeit one that’s easily overcome.  Grid items’ margins do not collapse.  You can see this effect by checking the “Default margins” option in the demo.  That shows what happens if default paragraph margins are allowed to remain.  We end up with two ems of space between the paragraphs, because each has top and bottom margins of 1em.

In the normal flow, margins collapse to the largest of the adjacent margins, which is why we’re used to 1em of space between adjacent paragraphs.  With grid items, what we see instead is the full element box, margins and all, placed inside the grid cell(s) they occupy.  That means any margin will create space between the edge of the grid cell and the border-edge of the element.  The fix here is straightforward: add a style to reduce margins between elements.  For example, something like:

blockquote > * {
   grid-column: 2;
   margin: 0.5em 0;
}

With a half-em margin above and below each element, any two adjacent elements will have the common 1em separation.  The demo actually has less than that because I wanted to use the print convention of paragraphs with the first lines indented, and a minor separation between paragraphs.  So the actual demo styles are more like this:

blockquote > * {
   grid-column: 2;
   margin: 0.125em 0;
   text-indent: 2.5em;
}
blockquote > *:first-child {
   text-indent: 0;
}

So there you have it: a Grid-powered drop quote.  I should note that all this by itself isn’t quite sufficient: if Grid isn’t supported, it will degrade poorly, as you can verify with the “Disable grid” option.

This is where using @supports() to encapsulate the Grid styling comes in handy.  You can put all of the quote-generation styles into the @supports() block, so that downlevel browsers just don’t get the drop quotes; or, you can set up the drop quotes with floats or positioning and then override those with @supports()-protected Grid styles.  Either one works.

Fortunately, we do have that capability, so it’s fairly easy to progressively enhance your designs with little touches like this one, even if you’re not ready for a full-on Grid plunge.  I’m looking forward to deploying this pattern here on meyerweb, as part of a site design overhaul I’ve been working on for the past couple of weeks.  That’s right: I’m working on my first redesign in a dozen years.  If that doesn’t give you some sense of the power of Grid, well, I just don’t know what will.


There is a followup to this article that explains and corrects an oversight in this article.