I toyed with the idea of nesting elements with borders and some negative margins to pull one border on top of another, or nesting a border inside an outline and then using negative margins to keep from throwing off the layout. But none of that felt satisfying.
It turns out there are a number of tricks to create the effect of stacking one border atop another by combining a border with some other CSS effects, or even without actually requiring the use of any borders at all. Let’s explore, shall we?
That’s from the introduction to my article “Stacked ‘Borders’”, which marks the first time I’ve ever been published at the venerable upstart CSS-Tricks. (I’m old, so I can call things both venerable and an upstart. You kids today!) In it, I explore ways to simulate the effect of stacking multiple element borders atop on another, including combining box shadows and outlines, borders and backgrounds, and even using border images, which have a much wider support base than you might have realized.
Just over an hour before I started writing this post, I handed off CSS Pocket Reference, 5th Edition to the Production department at O’Reilly. What that means, practically speaking, is that barring any changes that the editors find need to be made, I’m done.
Besides all the new-new-NEW properties included in this edition (flexbox and grid being just two of the most obvious examples), we put a lot into improving the formatting for this edition. Previous editions used a more sprawling format that led to the 4th edition getting up to 238 pages, which cast serious shade on the word “Pocket” there in the title. After all, not all of us live in climates or cultures where 24/7 cargo pants are a viable option.
So with a few ideas from me and several more from the production team, we managed to add in all the new properties and still bring the page count down below 200. My guess is the final copy will come in about 190 pages, but much will depend on how crazy the indexer gets, and how much the formatting gets changed in the final massaging.
We don’t have a firm release date yet; I’m pulling for April, but it’s really not up to me. I’ll make announcements via all the usual channels when pre-order is available, and of course when publication day arrives.
For now, for the first time in many years, I don’t have a book project on my to-do list. I don’t even have a book proposal on my to-do list. It’s a slightly weird feeling, but not an unwelcome one. I’ll be putting the extra time into my content for An Event Apart: I’m giving a talk this year on using the new CSS tools to make our jobs easier, and doing Day Aparts in Boston and San Francisco where I spend six hours diving deep into guts of stuff like flexbox Grid, writing modes, features queries, and a whole lot more.
So my time will continue to be fully spoken for, is what I’m saying. It’ll all be fun stuff, though, and it’s hard to ask for more out of my work.
My wife Kat and I tell ourselves we’d love another child for who they are, not for who they replace. We even believe it. But we can’t be sure of it—and that keeps us from shutting our eyes, jumping back into the adoption process, and hoping it will turn out okay. We know all too horribly well that sometimes, it doesn’t.
That’s the opening of my essay “The Second Third Child”, included in the new book from Modern Loss titled Modern Loss: Candid Conversation About Grief. Beginners Welcome, published this week.
I’m deeply honored to be one of the 40+ contributors to the book, some of whom you may know—Dresden Dolls co-founder Amanda Palmer, CNN’s Brian Stelter, author Lucy Kalanithi, Dear Evan Hansen director Michael Greif, Stacy London of What Not To Wear—and many of whom you may not, as I will be unknown to the vast majority of the book’s readers. I’ve written articles for Modern Loss in the past, but to be entrusted with a part of their first book was humbling.
Several of the essays in the book are intentionally funny, but mine is not one of them. It’s quiet, reflective, and elegiac in more than one way, but never anything but honest. It appears in the first section of the book, titled “Collateral Damage”.
As Stephen Colbert put it: “Talking about loss can feel scary. This book isn’t. It’s about grieving deeply over the long term, and the reassurance that you’re far from broken because of it.” I hope my essay, and the book as a whole, helps readers to come to terms with their own grief, by seeing that they are not alone, and that they did the best they could even if it doesn’t feel that way at all.
Yesterday afternoon, CSS: The Definitive Guide, 4th Edition went to the printers. Eighteen years after the First Edition hit shelves, eleven years after its predecessor came out, five years after I first started working on this edition, and thanks in no small part to Estelle Weyl and a parade of long-suffering editors at O’Reilly, the last changes were entered, the pages were locked, and the repository closed.
It comes in at 1,088 pages: almost exactly twice the length of the Third Edition, with six new chapters and a lot of overhauling of old chapters. Flexbox, Grid, filtering, blending, clipping and masking, float shapes, animations and transitions, transforms, image borders, counting systems, custom properties (a.k.a. CSS variables), media and feature queries—they’re all in there, and a whole lot more besides. Gradients got a major new section in what used to be called just “Colors and Backgrounds” and is now “Colors, Backgrounds, and Gradients”. And all the new background properties! So many new background properties.
We didn’t skimp on the visuals, either. The book has, if I counted correctly, a total of 778 figures. Almost all of them were captured in-browser, and you can download or clone all the files from GitHub. If you’d rather just browse them online, you can do so thanks to GitHub Pages. That’s also where to find the transition and animation examples that are referenced in the text, but not figures themselves (detailed animation being somewhat difficult to represent on paper). If we add figures and animation examples together, there are 826 elements supporting the main text. Which feels like a lot to me.
The book will be available in both tree-wafer and glowing-display formats from your favorite supplier of such things; e.g., Amazon. (If you’re going to buy through Amazon and are inclined to support another aspect of my life, please designate Rebecca’s Gift as your Amazon Smile recipient before buying the book.) I also hear tell it will be available DRM-free from eBooks.com, and potentially in PDF form for those who prefer it. O’Reilly doesn’t sell books directly any more, but I do believe it will be avialable to those with Safari subscriptions.
I’ll have more to say about the book and its contents as the release date draws closer. Last I heard, it should be out by the end of this month, but as always, release dates can slip for any number of reasons. Even if this release does slip, it should still come out no later than early November.
(Let’s hope I didn’t just jinx that.)
This is always a tense and exhilarating time. What if I got a huge piece completely wrong? What if I made the wrong calls on what to include and what to defer to the next edition? What if I missed egregious typos? What if nobody likes it? Basically, the same doubts that strike most any author. But there’s also the incredible feeling of a project brought to its conclusion and the anticipation of getting it into readers’ hands. This has been a longer-than-usual time coming, but as it usually does, the time has come at last. I hope you’re looking forward to it half as much as I am.
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:
CSS and Documents
Specificity and the Cascade
Values, Units, and Colors
Basic Visual Formatting
Padding, Borders, Outlines, and Margins
Colors, Backgrounds, and Gradients
Floating and Shapes
Flexible Box Layout
Table Layout in CSS
Lists and Generated Content
Filters, Blending, Clipping, and Masking
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 usualchannels. 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.
…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.
As I’ve said before, I understand being hesitant. Based on our field’s history, it’s natural to assume that Grid as it stands now is buggy, incomplete, and will have a long ramp-up period before it’s usable. I am here to tell you, as someone who was there for almost all of that history, Grid is different. There are areas of incompleteness, but they’re features that haven’t been developed yet, not bugs or omissions. I’m literally using Grid in production, right now, on this site, and the layout is fine in both Grid browsers and non-Grid browsers (as the article describes). I’m very likely to add it to our production styles over at An Event Apart in the near future. I’d probably have done so already, except every second of AEA-related work time I have is consumed by preparations for AEA Seattle (read: tearing my new talk apart and putting it back together with a better structure).
Again, I get being wary. I do. We’re used to new CSS stuff taking two years to get up to usefulness. Not this time. It’s ready right now.
I’ve been working a lot with the clip-path property recently, as I write the chapter on filters, blends, clipping, and masking for CSS: The Definitive Guide’s long-delayed 4th edition (available now in early-release format!). One of the nifty things you can do with clipping paths is define them with percentage-based coordinates. For example, here’s a hexagon-like clipping path:
I didn’t want pixels, though. I want percentages, darn it all!
So I asked around on Twitter, and Markus Stange pointed me to the solution: converting all the SVG coordinates to the range 0–1 and using the clipPathUnits attribute. The working version looks like this:
That yields the same result as the polygon() CSS shape with the percentages I showed before.
All that is great if you’re writing your own SVG shapes and can make sure you set it up properly, but what if someone hands you a shape to be used as a clip path and it’s in absolute coordinates like 100 75? If you’re really lucky, the shape has a viewbox of 0 0 100 100 (or all the coordinate points are in that range) and you can just divide all the coordinate points by 100 to get the proper values. But that’s really tedious for any but the simplest of shapes, and besides, what if it has some other viewbox? That’s where the transform attribute saves the day.
For example, suppose you get an SVG file that looks like this (with the actual path coordinates removed because there are a lot of them):
Next, look at the viewBox attribute on the <svg> element itself. The value there is 329.6667 86. That means 329.6667 coordinate units horizontally, and 86 units vertically. So all you need to do now is divide all the horizontal values by 329.6667, and the vertical values by 86. Which would be super tedious, except we have scaling transforms at our disposal:
Those two values are 1/329.6667 and 1/86, respectively, and they effectively scale every point in the d attribute to fit into the needed 0–1 range. (That’s not precisely what happens, but the outcome is the same.) Thus we have an SVG clipping path that scales with the element and fits to its dimensions!
This works just as well for other markup patterns. To return to the hexlike path from before, assume it was written like this:
If that were applied as-is, via clip-path: url(#hexlike), it would create a hex-like clipping path that fits a 100px by 100px box, positioned in the top left of the element (in left-to-right languages, I presume). The quick fix:
Bingo bango bongo, it will now scale to the element’s dimensions, whatever those turn out to be.
Of course, if you apply that to something like a short paragraph, it will be verrrrry stretched out, but the same would be true with a percentage-based polygon() shape. The beauty here is that you can scale any coordinate set, so if you have a tiny path that you want to blow up, or a huge path you want to shrink down, you can transform it without using clipPathUnits to stretch it over the bounding box. Something like this:
That gets you a hexlike shape that fits a 400px by 400px box, for example.
Now all CSS needs is the ability to size and position clipping paths in a manner similar background images, and we’ll be in clover. I hope such properties are in the WG’s mind, because I’d love to be able to just point an at SVG clipping path, and then say something like clip-path-position: center; clip-path-size: contain;. That would remove the need for fiddling with SVG attributes altogether.
Thanks to Markus Stange for the technique and his invaluable assistance in proofreading this article.
Sara and I are guests on the most recent Shop Talk Show, espiode #212, where we talked with Chris and Dave about Design for Real Life, Google Mic Drop, and more. We had a good time with it, and hope you will too.
In a moment of slight coincidence, the episode was released almost exactly a year after my first appearance on Shop Talk (espisode #161), where I covered similar topics. At that point, Sara and I were still researching and tossing ideas for the book back and forth. Now here we are, a year later, with the book out. It’s a little wild to contemplate, honestly. It was a lot of work in a pretty short time frame… but so very much worth it.