Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Gridded Headings

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


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:

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

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;

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.

14 Responses»

    • #1
    • Comment
    • Fri 19 May 2017
    • 1545
    Jon Humphrey wrote in to say...

    Eric, these look amazing! Loving the grid more and more! Thanks for the heads up, maybe we should call the container element an “hgroup” or something?!? 🤔😏😎🤣

    • #2
    • Comment
    • Fri 19 May 2017
    • 1610
    Eric Meyer wrote in to say...

    Jon: I miss the HTML document outlining algorithm. I really do.

    • #3
    • Comment
    • Fri 19 May 2017
    • 1626
    Alan Hogan wrote in to say...

    RIP, <hgroup>. (I miss it too.)

    • #4
    • Comment
    • Fri 19 May 2017
    • 2013
    Philippe wrote in to say...

    Slightly (ahem) OT — I was viewing this earlier on my iPad (portrait mode), the font-size of the page is a wee little bit too large (understatement for today: too large as in “yuuge”). Really. From the stylesheet: body { font-size: 2em; }. Just saying. That gave all kind of interesting effects on the demo… Try to view the page in Firefox responsive design view if you don’t have an iOS device at hand.

    (setting aside that Safari currently does not support minmax(min-content,max-content), you‘d need to prefix it)

    • #5
    • Comment
    • Fri 19 May 2017
    • 2024
    Eric Meyer wrote in to say...

    Whoops! Thanks for reporting that, Philippe. I cranked it down to a more reasonable level. Now I just have to remind Mobile Safari to act like a handheld device, not a tiny desktop computer.

    • #6
    • Comment
    • Tue 23 May 2017
    • 0148
    Šime Vidas wrote in to say...

    Note that the HTML spec recommends against using heading elements for subheadings. See

    • #7
    • Comment
    • Tue 23 May 2017
    • 0429
    Ben wrote in to say...

    I was very confused as to why it wasn’t working quite right in Safari until I read the aside in your comment, Philippe!

    Eric, perhaps you could clarify that in the post?

    • #8
    • Comment
    • Thu 25 May 2017
    • 0757
    Lee Kowalkowski wrote in to say...

    Those examples given feel more like <h2>heading<sub>subheading</sub></h2> to me.

    I mean, they don’t feel like separate headings, it would not make sense to insert a paragraph or two between a headings and its subheading, so semantically, it feels like one heading element, not two.

    • #9
    • Comment
    • Thu 25 May 2017
    • 0948
    Eric Meyer wrote in to say...

    True, Šime. I see the pattern I used a lot in the field, so I was going off of a pattern I hoped would be familiar to readers, but I probably should have kept that in mind.

    Lee, sub is a subscript element, so it doesn’t feel right here either. I think the pattern Šime pointed to makes a bit more sense, although I dislike it as well. At least in cases where it’s title-date pattern, we could use time for the “subhead”!

    • #10
    • Comment
    • Thu 25 May 2017
    • 0954
    Eric Meyer wrote in to say...

    Good idea, Ben. Addendum appended. Thanks for the nudge!

    • #11
    • Pingback
    • Thu 25 May 2017
    • 2208
    • #12
    • Pingback
    • Fri 9 Jun 2017
    • 1240
    Received from Bruce Lawson’s personal site  : Reading List

    […] Gridded Headings – by Eric Meyer […]

    • #13
    • Comment
    • Sun 10 Sep 2017
    • 1429
    Tim wrote in to say...

    At some browser widths I see the boxes much wider than the headings, in both Chrome and Firefox. Not what is intended?

    Here is a screengrab of what I see:

    • #14
    • Comment
    • Mon 11 Sep 2017
    • 1507
    Eric Meyer wrote in to say...

    Hey, Tim! That actually is what’s expected, given the combination of styles in play there. You’d see the same kind of sizing if the headings were normal flow instead of grid items, except without the shrink-to-fit or alignment behaviors at wider displays.

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...

May 2017
April June