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

Adding Backgrounds to Directly Loaded SVGs

My primary SVG viewer is Firefox.  This is partly because it’s always running, so the startup time is essentially zero.  It also allows me to directly inspect and modify elements of the SVG element through the Web Inspector, which can be handy.

But I’ve run into a problem more than once, which is that if I load an SVG file in Firefox, the browser window’s background defaults to white, and a lot of times I’m trying to view images that are partially or entirely white.  I started thinking that if there were a way to make the window background medium gray, that would solve the problem with rare downsides, since I can’t remember trying to view an all-medium-gray SVG.

After a question on Twitter and some ideas from Tibor Martini, I realized I could use Stylish to give the SVG files a background through CSS.  I didn’t want to select all SVGs, only those I was loading directly, so I tried this:

svg:root {background: gray;}

And it worked!  So I decided to make it more robust by doing a multicolor gradient, and grayscaling it on hover.  I couldn’t use filter because that would grayscale the whole image, rather than just the background, but that was easy to work around.  I ended up with this:

svg:root {background: linear-gradient(135deg, hsl(0,50%,60%), hsl(180,50%,40%));}
svg:root:hover {background: linear-gradient(135deg, hsl(0,0%,60%), hsl(180,0%,40%));}

Which works great!  Except that I discovered Firefox applies it to all SVGs, even those loaded into HTML documents via img.  SVGs apparently define their own roots, which I hadn’t expected, but I can see how it might make sense.  So I poked around in MDN until I came up with this:

@-moz-document url-prefix(file:) {
    svg:root {background: linear-gradient(135deg, hsl(0,50%,60%), hsl(180,50%,40%));}
    svg:root:hover {background: linear-gradient(135deg, hsl(0,0%,60%), hsl(180,0%,40%));}

And that’s exactly what I wanted.  If it’s useful to you, have at it.  Just paste that into a new Stylish rule in Firefox, and you should be good to go.

If you’re on Chrome, you can import the above into Stylish and create a new rule, but it hasn’t worked for me, and I’m not sure why not.  Removing :root didn’t fix it when I tried, and that shouldn’t matter anyway: I can see in Chrome’s user styles that svg:root is used and applied.  And my Stylish toolbar icon shows the rule is being applied.  It just doesn’t do anything I can see.  If anyone can figure out how to make it work, or explain why it can’t work, I’d love to know in the comments!

CSS: The Definitive Guide, 4th Edition

On Monday, July 3rd, as I sat in the living room of a house just a bit north of New York City, I pushed the last writing and editing changes to CSS: The Definitive Guide, Fourth Edition and notified the production department at O’Reilly that it was ready.

All twenty chapters, three appendices, and associated front matter are now in their hands.

It’s been a long and difficult journey to get here.  Back in 2011-2012, I started updating chapters and releasing them as standalone books, for those who wanted to grab specific topics early.  In mid-2013, I had to stop all work on the book, and wasn’t really able to get back into it until mid-2015.  At that point, I realized that several new chapters had to be added—for example, when I started out on this edition, Flexbox and Grid were pie-in-the-sky ideas that might or might not come to pass.  Feature queries weren’t a thing, back then.  Filters and masks and blend modes were single-browser at best, when I started out.  And forget about really complex list counters.

Now all those topics (and more!) have chapters, or at least major sections.  Had I not been delayed two years, those topics might not have made it into the fourth edition.  Instead, they’re in there, and this edition may well end up twice as long as the previous edition.

I also might not have brought on a co-author, the inestimable Estelle Weyl.  If not for her contribution in new material and her close, expert review of the chapters I’d already written, this book might have been another year in the making.  The Guide was always my baby, but I couldn’t be happier that I decided to share it with Estelle, nor prouder that her name will be on the cover with mine.

Speaking of major changes, I probably wouldn’t have learned AsciiDoc, nor adopted Atom as an authoring environment (I still use BBEdit for heavy-lift text processing, as well as most of my coding).  O’Reilly used to be a “give us your Word docs!” shop like everyone else, but that toolchain doesn’t really exist any more, from what I can tell.  In fact, the first few chapters I’d given them were in Word.  When I finally returned to writing, they had to give me those chapters back as AsciiDoc exports, so I could make updates and push them to O’Reilly’s internal repository.  The files I created to create figures in the book went into their own public repository, which I’ll get to reorganizing once the text is all settled and the figure numbers are locked in.  (Primary to do: create chapter lists of figures, linked to the specific files that were used to create those figures.  Secondary to do: clean up the cruft.)

As of this moment, the table of contents is:

  • Preface
  1. CSS and Documents
  2. Selectors
  3. Specificity and the Cascade
  4. Values, Units, and Colors
  5. Fonts
  6. Text Properties
  7. Basic Visual Formatting
  8. Padding, Borders, Outlines, and Margins
  9. Colors, Backgrounds, and Gradients
  10. Floating and Shapes
  11. Positioning
  12. Flexible Box Layout
  13. Grid Layout
  14. Table Layout in CSS
  15. Lists and Generated Content
  16. Transforms
  17. Transitions
  18. Animation
  19. Filters, Blending, Clipping, and Masking
  20. Media-Dependent Styling
  • Appendix A: Animatable Properties
  • Appendix B: Basic Property Reference
  • Appendix C: Color Equivalence Table

Disclaimer: the ordering and titles could potentially change, though I have no expectation of either.

I don’t have a specific timeline for release as yet, but as soon as I get one, I’ll let everyone know in a post here, as well as the usual channels.  I expect it to be relatively speedy, like the next couple of months.  Once production does their thing, we’ll get it through the QC process—checking to make sure the figures are in the right places and sizes, making sure no syntax formatting got borked, that kind of thing—and then it’ll be a matter of getting it out the door.

And just in case anyone saw there was news about O’Reilly’s change in distribution and is wondering what that means: you can still buy the paper book or the e-book from your favorite retailer, whether that’s Amazon or someone else.  You just won’t be able to buy direct from O’Reilly any more, except in the sense that subscribing to their Safari service gives you access to the e-book.  That does mean a tiny bit less in royalties for me and Estelle, since direct paper sales were always the highest earners.  Then again, hardly anyone ever bought their paper copies direct from O’Reilly, so honestly, the difference will be negligible.  I might’ve been able to buy an extra cup of coffee or two, if I drank coffee.

It feels…well, honestly, it feels weird to have finally reached this point, after such a long time.  I wish I’d gotten here sooner for a whole host of reasons, but this is where we are, and regardless of anything else, I’m proud of what Estelle and I have created.  I’m really looking forward to getting into your hands.

Help Insurance

This is my daughter Rebecca in 2013.  She was 5¼ years old when I took this picture.  Less than three days later, she almost died on an ER bed.

She’d been completely fine when we set out for vacation that year, and just seemed to come down with a virus or something just after we arrived.  She got checked out at an urgent care center, where they diagnosed strep throat.  But antibiotics didn’t help.  She slowly got more and more sick.  We finally took her to be checked out at a nearby hospital, who were just as stumped as we were.  They were looking for a room to put her in when she seized and flatlined.

Just like that.  She’d been ill, but not severely so.  All of sudden, she was on the edge of death.  The ER staff barely stabilized her, by intubating her and administering drugs to induce a coma.

There was a large tumor in the center of her brain.  Our five-year-old girl, who so far as we knew was completely fine just days before, had aggressive brain cancer.

After a midnight life flight nobody was sure she would survive, she arrived in Philadelphia and had several cranial surgeries, spent more than a week in the pediatric intensive care unit, and then was transferred down a few levels to spend another two weeks on the recovery floor, slowly rebuilding the muscle strength she’d lost from more than a week of immobility.

Later, there were weeks on weeks of radiation and chemotherapy in Philadelphia.  After the initial treatment was done, we came home to Cleveland for more chemotherapy.

This is her, hauling her baby brother Joshua up the slide in our backyard, and hauling her mom through the crowd at the local garlic festival.  At a CureSearch walk with her siblings and dozens of friends and family.  Just barely tolerating my terrible dad jokes, doing her utmost not to encourage me by laughing.

We did everything we could, sometimes through tears and sickening horror, but the treatments didn’t work.  Rebecca died at home, surrounded by friends and family one final time, less than ten months after her cancer was discovered, in the early evening hours of June 7th, 2014, her sixth birthday.

In those ten months, the total retail cost of her procedures and treatments was $1,691,627.45.  Nearly one point seven million US dollars.

We had health insurance—really good insurance, thanks to COSE’s group plans and my wife’s and my combined incomes.  The insurance company’s negotiated rates meant they paid $991,537.29, or about 58% of the retail price.

We paid very little, comparatively speaking, until you counted the monthly premiums.  All of it together, co-pays and premiums, was still in the low five figures.  Which we were, fortunately, able to pay.

Without insurance, even if we’d been able to get the insurer’s rate, we’d have gone bankrupt.  All our investments, our house, everything gone.  If pre-existing conditions had prevented us from being covered, or if we’d been less fortunate and unable to afford premiums—bankrupted.

In which case, Rebecca’s brother and sister would have suffered her death, and the loss of their home and what precious little remained normal in their lives.

How many families live through that double hell?  How many go completely broke trying to save their child?  How many could have saved their children, with coverage that paid for life-saving treatments?  How many never had any chance of saving their child, but ran out of money before treatment was complete and now believe their lack of insurance and money was what killed their child?

How many more will have to live with those unthinkable situations, if the House and Senate bills go forward?

The point, the essential point, is this: every family should have the chance to fight as hard as possible for their loved one’s life without going bankrupt in the process.  And for those who cannot be saved, no family should be denied the knowledge that they didn’t have a chance.  Because knowing that does provide some (small) measure of comfort.

The Affordable Care Act wasn’t perfect, and it was severely and willfully undercut after it launched, but it was a huge step in the right direction.  The bill currently before Congress would be an enormous step back.  I doubt that I’ll benefit from the tax cuts that are part of the bill, but if I do, I’ll commit every cent I get from them and more to unseat anyone who votes yes on this bill.  I have let my senators know this.

I would spare every family the pain we endured, if I could, but nobody has that power.  We do, together, have the power to help every family that must endure that pain, to give them access to the simple safety net they need, to concentrate everything they can on the struggle to heal.

I miss her every day, but I know that we did everything that could be done, including being able to afford the hospice care that kept her as comfortable as possible in her final hours, preventing the seizures and pain and fear that would have made her last moments a hell beyond endurance.  Allowing her a peaceful end.  Every family should have access to that.

Please think about what it means to take that ability away.  Please think about what it means to take away the ability to avoid having to make those choices.


Eulogy, Completed

Three years ago, almost exactly to the minute as I publish this, I delivered the eulogy at my daughter’s funeral.  A few months after that, reading it again, I discovered that when I wrote it, I didn’t really finish it.  I understand why: I wrote it in the days after her death, and was not really able to think it through.  It was only in hindsight that I realized what was missing.

So today, I’m publishing the eulogy as I would have written it, had I been of clearer mind.  The final two sentences below are what I left off.

Rebecca was fierce.  She beat adults in staring contests when she was two weeks old.  Rebecca was joyful.  Her laugh could fill a room and bring a smile to anyone who heard it.  Rebecca was stubborn.  She would often refuse to give in, even when it cost her something she wanted.  Rebecca was kind, and loving, and mischievous, and oh so very ticklish.

She vibrated with energy.  Her philosophy was essentially: never walk when you can skip, never skip when you can run, never run when you can dance, and never dance when you can hide yourself around the next corner and then laughingly yell “BOO!” when everyone else finally catches up with you.

She loved to steal our phones and wallets and keys from our pockets, not to hide them away or do anything mean or malicious, but to wave them in front of us and laugh her way through an affectionate, singsong tease.  If there’s a world beyond this one, I hope whoever’s in charge has secured all the valuables.  Not to prevent her from swiping them, which would be an impossible goal, but because she would be disappointed and bored if they were too easy to swipe.

Rebecca is not an angel, nor would she wish to be.  If anything, Rebecca is now a poltergeist.  On her sixth birthday, we had planned to go to Cedar Point that day and the next.  Instead, that was the day she died… and on that day, a water main break closed Cedar Point for the entire weekend, because if she couldn’t go, then nobody gets to go.  And in brief conversation this morning, I was literally about to say the words “lose electricity” when the power went out in our house.

The little stinker.

One of the hardest things for us in the last few weeks of her life was seeing how the tumor slowly and inexorably took all that sass and spice away from her.  The loss of energy and emotion was horrible.  We had fought so long and hard to keep her quality of life normal, and we had succeeded.  It was only at the very end, just the last few days, that she moved beyond our ability to preserve it.

Underneath it all, she was still Rebecca.  She got mad at her sister and brother because they would get to stay with us and she wouldn’t, and then she forgave them because she understood it wasn’t their fault and she loved them so much.  She gave us disdainful looks when she thought our attempts to tease her were lame.  She asked, wordlessly but clearly, to hear her favorite stories.  She told us she didn’t love us because she wanted to push us away, to lessen our pain.  But when we explained to her that the joy of loving her was worth any pain, and that we could never stop loving her regardless, she relented and admitted the truth that we had never doubted.  The last words and gestures that passed between us were of love.

In her last hours, she was surrounded by love, her room filled with people who loved her as she loved them, never leaving her alone for a second.  We held and snuggled her all the way to the end, all of us together.  And the people in that room were surrounded by the love of those who loved them, and they by those who loved them.  All of that love focused on Rebecca.  She deserved it.  But then, so does every child.

Now she is gone, and we who remain are devastated.  It is only together that we will move forward.  Community has sustained us the past months, and made it possible for us to do everything we could for Rebecca and Carolyn and Joshua.  Community will help us get through this.  Our hearts have been broken into uncountable pieces, but we will help pick up those pieces together.  I am beyond heartbroken that she is gone, but I will never, not for an instant, ever regret that she came into our home and our lives.

What matters in this life is not what we do but what we do for others, the legacy we leave and the imprint we make.  Her time may have been short, but her spark illuminated so much in that time, touched and warmed so many people, and for the rest of our days we will all be changed for the better.  That is what Rebecca did for all of us.  And any of us would be beyond fortunate to have lived our lives with half as much meaning, or a tenth as much joy, as she lived hers.

Half Life

Three years ago, Rebecca took her last breaths.

She’s been gone for half her life.  Half the time she had with us, elapsed in absence.

It’s still hard to comprehend.  The old adage that you don’t get over it, but you get used to it, holds true.  I’m used to her absence.  I still think of her daily, usually multiple times a day, reminded one way or another.  The reminders can spring from moments of joy that I suddenly realize she isn’t there to share, or from moments of profound sorrow over the state of everything, or just from spotting an unexpected flash of purple.

In the initial grieving, each moment of remembrance was like an enormous jagged spike driven violently through my chest, impaling me in an anguish I could not actually feel, even as I experienced it.  My breath would hitch to a stop as I remembered the hitch in hers, as her body finally relaxed and the space between each breath got longer and longer, even as each breath was a fractional bit fainter than the one before.

My grief has similarly faded, these last three years.  That terrible, transfixing pain has its own slope of decay, if you let it decay, dropping into a long tail of quiescence.  If you’ve ever suffered a major injury, then you know what I mean.  The initial pain is overwhelming, filling your entire awareness and leaving room for nothing else.  That fades into a massive suffering as the injury is addressed.  After the initial recovery, you come to live with a constant pain that is manageable, if utterly draining to endure.  After a longer while, that becomes an ongoing ache, easily aggravated but also somewhat possible to ignore for short periods.  And so on and so on, until months or years later, it’s a twinge you get every now and then, maybe a dull ache when the weather changes or you shift your weight the wrong way.  Something you can live with, but also something you can never fully forget.

I can still sometimes feel the spikes that were driven into me, but distantly, around the edges where the scar tissue grew to fill the latticework of grief.  As you might feel the shadows of the pins that put your leg back together, or the echo of the holes drilled into your skull to seat the halo brace.

We went to visit her grave this afternoon.  It was our first time back since last year’s memorial visit.  I’d thought of going from time to time in the intervening year, and resisted.  I’m not entirely certain why, but it felt like the right decision.  Not the decision I wanted to make, but the right one.

We were astonished to find that the artificial flowers and rainbow spinner placed there last year were still in place, faded and worn.  The groundskeepers had carefully mowed around them.  Perhaps that’s why the small Rainbow Dash toy was still there, still nestled against the top edge of the marker.  It, too, was faded from the year of sun and rain and ice, but still had the same jaunty pose and smiling face.

It reminded me of Rebecca, and I smiled a little.

I noticed dirt had settled into some of the letters, and resolved to return another day to clean them out.  Maybe polish the granite face a bit, to see if I could restore some of its initial luster.  Nothing I could do would preserve that forever; the slow decay of time and weather never pauses, not even in deference to the memory of a little girl who lived too short a life, no matter how fully she lived it.

In the long run, the marker will be worn smooth, settling through a long period of becoming harder and harder to read until eventually, it fades completely from understanding.  That can’t be avoided, but it can be postponed a little bit.  As long as I’m here and able, I can put in a little periodic effort to undo some of the damage done.  Put things partly right.  It might seem futile, but sometimes small acts in the face of futility is the best you can do.

You don’t get over it.  But you get used to it.

Gridded Headings v. Justified Headings

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:


…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:


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

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.

Grid Drop Quotes, Revisited

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!

(If you care, there's even an archive of previous thoughts...)

Identity Archipelago

Projects Elsewhere

Blog Advisory System Alert Level: Guarded

The excuse of the day is

General Protection Faults