A few more details:

• New CSS Layout (October 17-18) is two days of deep diving into flexbox, multicolumn, grid, and related technologies.  There will be a heavy emphasis on Things You Can Use Today, including bugs and how to handle them, with a keen focus on using everything in a progressively enhancing way.  In other words, you should walk away knowing how to use new technologies right away, without leaving behind users of older browsers, and have a good sense of what you’ll be able to do in the next 6-12 months.  This will be hands-on, interactive, and very much a dialogue with technical instruction.  If you’re looking for two days of watching me drone in front of a slide show, this is not that.  I’m not even sure I’ll have any slides at all—I’ll probably spend the entire time in BBEdit and a browser instead.  The class size is limited to 40 people.
• CSS Animation (November 17-18) is another two days of diving deep into the topic.  For this one, I’ll spend the first day going through every last piece of CSS transition and animation syntax, with generous helping of transform.  On the second day, Val will show how to put that syntax to use in a way that serves and strengthens your design, instead of undermining it.  It’s basically a day of learning how the tools work, and a day of learning how to properly use the tools.  Again, class size of 40; and again, very much hands-on and interactive.

So that’s what’s up.  Looking for ways to seriously expand your skills in layout or animation or both?  Come, join us!

• The Web Ahead #115 — recorded LIVE! at An Event Apart Nashville, I joined Rachel Andrew, Jeffrey Zeldman, and host Jen Simmons for an hour-plus look at the present and future of web design and web design technologies, featuring a number of really sharp questions submitted by the audience as we talked.  We got Nostradamic with this one, so warm up the claim chowder pots!
• User Defenders #20 — Sara and I talked with host Jason Ogle for just over an hour about Design for Real Life, digging deep into the themes and our intentions.  Jason really brought great questions from having just read the book, and I feel like Sara and I kept our answers focused and compact.
• The Big Web Show #144 — Jeffrey and I talked for just under an hour about Design for Real Life and the themes of my AEA talk this year.  This one’s more of a ramble between two friends and colleagues, so if you prefer conversation a little looser, this one’s for you.

Share and enjoy!

On March 8th, 2016—just eight days from the day I’m writing this—Design for Real Life will be available from A Book Apart.  My co-author Sara Wachter-Boettcher and I are really looking forward to getting it into people’s hands.

The usual fashion is to say something like “getting it into people’s hands at long last”, but in this case, that’s not really how it went down.  Just over a year ago now, Sara published “Personal Histories”, and it was a revelation.  In her post, I could see the other half of the book that was developing in my head, a book that was growing out of “Designing for Crisis” and “Inadvertent Algorithmic Cruelty”.  So I emailed Sara and opened with:

Your post was like a bolt of lightning for me.  In the same way the Year in Review thing opened my eyes to what lay beyond “Designing for Crisis”, your post opened my eyes to how far that land beyond reaches.

After research and some intense discussions, we started writing in the spring of 2015, and finished before summer was over.  Fall of 2015 was devoted to rewrites, revisions, additions, and editing.  Winter 2015-2016 was spent in collaborative editorial and production work by the amazing team at A Book Apart.  And now…here we are.  The book is just a week away from being in people’s hands.

To celebrate, Sara and I will be hosting, with incredibly generous support from A Book Apart and PhillyCHI, a launch party at Frankford Hall in Philadelphia.  We’ll be providing some munchies, some tasty adult beverages, and there will be giveaways of both paper and digital copies of the book.  We’d love to see you there!  If you can make it, please do RSVP at that link, so we know how much food to order.

We chose Philadelphia as the site for our launch party for a few reasons.  For one, Sara lives there, so only one of us had to travel.  But to me, it brings some very personal histories full circle, because Philadelphia is where this really all got started.  It’s where Rebecca first went to be treated, where she was given the best possible shot at life, and where I started to notice the failures and successes of user experience design when it collided with the stresses of real life.

In a number of ways, this book has been a labor of love.  The most important, I think, is the love Sara and I have for our field, and how we would love to see it become more humane—really, more human.  That’s why we packed the book not just with examples of good and bad design choices, but of how we can do better.  The whole second part of the book is about how to take the principles we explore in the first part and put them to work right now—not by throwing out your current process and replacing it with a whole new, but by bringing them into your existing practice.  It’s very much about enhancing what you already do.

It’s been an intense process, both emotionally and work-wise.  We pushed as hard as we could to get this to you as soon as we could.  Now the time is almost here.  We’re really looking forward to hearing what you think of it.

There were a lot of strange confluences that went into that talk, some of them horrific, others just remarkable.  One that stands out for me, as I look at that screenshot, is how a few years ago, Jared Spool gave a talk at AEA where he discussed the GE Adventure Series, in a segment that never failed to choke me up (and often choked up Jared).  I remember being completely floored by that example, and at one point, based solely on what he’d said about the GE Adventure Series, I remarked to Jared that I occasionally thought about switching career tracks to become an experience designer.

Less than two years later, I stood in one of the first Adventure Series rooms at the University of Pittsburgh Medical Center, standing in the middle of a design I’d only ever seen on a projector screen, the same room you can see in the screenshot above, as my daughter’s head was scanned to see if the experimental medicine we’d been giving her had slowed her tumors.

Six months after that, I was talking about it on stage in Orlando, as an example of how designing for crisis can have spectacularly positive results.  The video we released last week came a year later, and is a much better version of that first talk.  I’m very happy that we can now share it with the world.

As I’ve said before, I came to realize that “Designing for Crisis” was just one piece of a larger puzzle.  To start exploring and understanding the whole puzzle, I recently finished co-authoring Design for Real Life with Sara Wachter-Boettcher, to be published by A Book Apart, possibly as soon as March (but there’s not an official date yet, so that could change).  In it, Sara and I explore a small set of principles to use in approaching design work, and talk about how to incorporate those principles into your existing design practice.  The book is the foundation for a new talk I’ll be presenting at every An Event Apart in 2016—including this year’s Special Edition show in Orlando.

As soon as the book is available for order, we’ll let everyone know—but for now, I hope you’ll find last year’s talk useful and enlightening.  Several people have told me it changed the way they approach their work, and it serves as a pretty good introduction to the ideas and themes I’ve built on it for the book and this year’s talk, so I hope it will be an hour well spent.

To understand why, let’s explore a use case, which you can see in various forms on this test page.  I cribbed this use case pretty directly from Fantasai, but I’m going to be analyzing it a little differently.  The basis is a form with the various fields and labels in unordered list items, to help with accessibility and to be basically readable and usable if the CSS somehow fails to be applied.  The markup looks like this:

<form method="post" action="script.cgi">
  <ul>
    <li><label for=name>Name:</label>
        <input id=name name=name></li>
    <li><label for=email>Email:</label>
        <input id=email name=email type=email></li>
    <li><label for=tel>Telephone:</label> 
        <input id=tel name=tel type=tel></li>
    <li><label for=url>Homepage:</label>
        <input id=url name=url type=url></li>
    <li><label for=bday>Birthday:</label>
        <input id=bday name=bday type=date></li>
  </ul>
</form>

Ideally, we’d like the form fields to all line up into a column, and the labels to be in another column.  Furthermore, we’d like the label column to be only as wide as the widest label’s element box, and no more; the rest of the grid can be taken up by the input column.

This seems like a case tailor-made for grid layout, but there’s a problem.  Because grid items are only ever the child elements of a grid container, we can’t just apply a grid to the ul element and go from there.  Instead, we have to make each li element a grid container, in order to make each label and input element a grid item.  But that means each list item’s grid affects its children, with no reference to the other list items’ grids.  We can write the template we want, like so:

form ul li {display: grid;
  grid-template-columns: [start label] max-content [input] 1fr [end];}

That will get us a result almost precisely as if we’d applied no grids at all.  The only difference is that the input elements will all be as wide as their columns, according to the CSS Grid specification.  Chrome fails to do this last bit correctly, whereas Firefox Nightly gets it right, but otherwise the layout is essentially the same.  You can see this in the #form1 example on the test page.  (Remember, you have to have a current grid-supporting browser for the examples to correspond to what I’m talking about here.)

We can get closer to our goal by experimenting with a fixed-width grid column for the labels, figuring out the width of the widest label, and then just making all the label columns be that wide.  That would be written something like this:

form ul li {display: grid;
  grid-template-columns: [start label] 7em [input] 1fr [end];}

That works pretty well so long as none of the labels ever change—if a label is added (or edited) to be wider, it will wrap to multiple lines.  Alternatively, if the longest label is dropped or edited to be shorter, the label column won’t resize down.  It will just stay the same dumb fixed width until someone hand-adjusts it.  And honestly, at that point I may as well be using flexbox, which would do this version of the layout just as well, and would be more widely supported for the near to intermediate future.  At any rate, you can see the grid version of this in the #form2 example on the test page.

But what if we could set a grid on the ul element, and then make all the li elements grids that use their parents’ grid for the layout of their children?  That’s exactly what subgrids do.  This is the solution we’ve been seeking, in basic form:

form ul {display: grid;
  grid-template-columns: [start label] max-content [input] 1fr [end];}
form ul li {display: grid; grid: subgrid; grid-column: start / end;}

Here the list items establish grid containers, thus making the label and input elements into grid items like before, but are stretched across the two columns of the ul while using those very grid lines for laying out their child elements, plus those children influence the placement of their grandparent’s grid lines.  Thus, we can specify things like max-content for the label column size and have it Just Work™.

Or it would Just Work™, except that as I write this, none of the grid implementations have subgrid support.  Authors who want to create the kind of layout we’re after have to compromise in one way or another—either by faking the content-sizing with a fixed-width column, or by stripping down the markup until there’s barely anything left—thus sacrificing accessibility, progressive enhancement, and general best practices, as Fantasai illustrated in her article.

You can probably see a lot of other ways in which subgrids would be useful.  Take defining a full-page grid, the kind with a bunch of regularly repeating grid lines onto which various elements can be attached, like this one or this one.  In this scenario, being able to designate each section of the page a subgrid would let you have all the pieces inside that section participate in, and lay out in relation to, the overall page grid.  Without subgrids, you’d either have to make every element you want to lay out a child of the body element (or whatever you used to create the page grid), or you’d have to recreate segments of the page grid in each nested grid, and give up any hope of columns that can flex with the contents of multiple page sections.  Neither solution is appealing.

This is why I’ve come to the same conclusion other grid experts (like Rachel) already have: subgrids are a major component of grid layout, and should be a part of any grid layout implementation when it emerges from developer-preview status.  If that means delaying the emergence of grids, I think it’s worth it.

I say that because our field has a tendency to glom onto the first iteration of a technology, learn it inside out, hack around its limitations, and then ignore any future improvements unless somehow forced to do so.  If grid layout is released without subgrid support, we’re risking shoving subgrids into the back of the author-practices cupboard for a long time to come.  And along with it, potentially, grids themselves.  The frustration of trying to build layouts without subgrids will quickly become overwhelming for all but the simplest cases, leading authors to try and then discard grids as a serious tool.

First impressions matter.  CSS itself suffered for years from the initial impressions designers formed of “boring, boxy” layouts, and it still suffers from the handicap of being a presentation system without a layout engine at its core.  Grid layout is the first serious candidate to fill that hole in the past two decades, and I don’t want to see them hamstrung from the outset.  Subgrids are essential to the adoption of grids.  I hope they’ll be implemented as soon as possible, and before grids are pushed into public release channels.

Just the three of us, talking throughout the single day of the event, trading off talks until lunch and then throughout the afternoon.  The slides, most of them running on S5, were projected onto a pull-down Da-Lite screen, and we tapped the screen with our hands to draw attention to bits of design (or code).  In the audience, there was an attendee who’d flown in from Tokyo, just to be there.  Another from London.  We were staggered to think anyone had come more than half an hour’s drive.

It was as lo-fi as it gets without paper megaphones, and we made a whole slew of rookie organizer mistakes—but we got the essentials right, the same essentials we’ve kept alive all these ten years: present in-depth, practical, higher-level content to an audience of savvy web folks, and treat them right.  As we’ve grown over the years from one day to two to three, and from three speakers to twelve (and sometimes eighteen), we’ve kept one central goal in mind: to create a conference we’d gladly pay to attend, every time.  And while I’m admittedly biased, I believe we’ve pretty much succeeded at that goal.

Ten years, which is a lifetime ago and then some, and still rolling strong.  We’re calling it A Decade Apart, because why wouldn’t we?  To celebrate, we’ll be doing some fun stuff at all our events in 2016, special giveaways on top of the usual giveaways, the return of some audience favorites…but I don’t want to give away too much just yet.  Suffice to say, we’re planning on making this our best year ever, and everything’s shaping up to deliver on those plans.

If you’ve been to a past Event Apart, thank you—and if you have a memory to share, I’d really love to hear about it in the comments.  And whether you’ve been or not, I hope to see you in 2016!

Of course, I’ve written a bunch of books that earned me some royalties, but books are not a way to become wealthy, unless you’re crazy lucky.  Yes, you have to put in the work to write the book, but in the end, whether your book makes you coffee money or high-end-chrome coffee machine money is down to forces entirely outside your control.  Certainly outside mine.  When I wrote my first CSS book, nobody expected CSS to be more than a slowly dying niche technology.  When I wrote the second, CSS had been declared dead twice over.  When I wrote the third and fourth, it was just starting to revive.

I invested tons of effort and time into understanding CSS, and then to explaining it.  Because I was lucky enough to put that work toward a technology that turned out to be not just successful, but deeply important to the web, the work paid off.  But think of the people who put that same kind of time and effort into understanding and explaining DSSSL.  “Into what, now?” you say.  Exactly.

Similarly, when Jeffrey and I set out to create An Event Apart, there was no assurance that there was a viable market there.  Nearly all the old web conferences had died, and those few that remained were focused on audience very much unlike the one we had in mind.  Luckily for us, the audience existed.  We worked really hard—still work really hard—to find and speak to that audience with the topics and speakers we present, but it would all have come to nothing if not for the sheer luck of having an audience for the kind of show we wanted to create.

For most of my adult life, I’ve been keenly aware of the incredible amount of luck that goes into success, and the awareness only grows as the years pass by.  Just putting in a lot of hard work isn’t enough.  You also have to have the sheer good fortune to have that hard work pay off.  You can sink everything you have, money and soul, into building a place in life, only to have it all sabotaged and swept away by random chance.  You can invest very bit of your life and fortune into an outcome that blind fate renders impossible.

So yes, I worked hard to understand the web, and to explain the web, and to write books and talks, and to create a conference series, and everything else I’ve done over the years—but I was supremely lucky to have that work come to something.  An incredible combination of time and place and interest and birth and a million million other things made that possible.

More to the point, the existence of people interested in what I have to say made that possible.  So I thank you, one and all, for all that and still more.  Thank you for rewarding and redeeming the work I’ve done.  Thank you for being of like mind.  Thank you for your support.  Thank you for listening.  Thank you.

This article was originally published at The Pastry Box Project on 2 December 2015.

Andrew ellicott lobortis decima thomas jefferson vulputate dynamicus fiant kingman park sollemnes ford’s theater. Vero videntur modo claritatem possim quis quod est noma howard university consequat diam. Blandit ut claram north michigan park seacula judiciary square william jefferson clinton hawthorne millard fillmore iis…

This was a product of some simple PHP I’d originally written to generate Cleveland-themed filler text a year or so back, which you can find at localipsum.meyerweb.com, and which I’d expanded upon to let me generate text for my presentations at AEA.  The name comes from the original idea I had, which was to provide a list of cities/regions/whatever, so that users could pick one and generate some filler text.  That never quite came together.  I had a semi-working version once, but the UI was horrible and the file management was worse and I got discouraged and rolled back to what you see now.

I kept telling myself that I’d get back to it, do the city-selection thing right, polish it nicely, and then finally release the source.  I’ve told myself that all year, as I manually swapped in city information to generate the filler text for each of my talks.  Now I’ve finally admitted to myself that it isn’t going to happen, so: here’s the source.  I chose a pretty permissive license—BSD-ISC, if I recall correctly—so feel free to make use of it for your own filler text.  I’ll be happy to accept pull requests with improvements, but not package-management or complete MVC restructuring.  Sorry.

I know, it’s a goofy little thing and the code is probably pants, but I kinda like it and figure maybe someone out there will too.  If nothing else, we can look for a few laughs in the output and maybe—just maybe—learn a little something about ourselves along the way.

(P.S. Speaking of “Designing for Crisis”, look for a post about that, and more specifically video of it, in the next few weeks.)

When I first took up CSS and it didn’t do what I expected from reading the spec, I started creating simple, focused tests of each property and its values, to figure out what I was getting wrong.  Because I wanted to be sure, I built tests for all the properties, even the ones I was confident about understanding—and, in places, found out my confidence was misplaced.  Eventually, those tests became the CSS1 Test Suite.  Since I had discovered that, in a lot of cases, the browsers were actually wrong, I decided to document CSS support in browsers.  That became the CSS Mastergrid (long since gone).  On the strength of that resource, I started writing articles to explain how things worked, or didn’t, which led to writing my first book.  And so on.

But it all started because I assumed I was wrong about how CSS should work, not that the browsers were fundamentally broken.  Simple test cases seemed like the best way to find out.  One thing led to another.  In a lot of ways, you could say that my career was made possible by me assuming I was wrong, and setting out to determine exactly how wrong I was.

It’s not that I want to be wrong; in fact, I dislike being wrong.  But I dislike continuing to be wrong much more, so I try to find out how I’m wrong, in hopes of becoming less wrong.  It’s not even “strong opinions, weakly held”—it’s more “strong suspicion of error, strongly pursued”.  In public, when necessary.  (This is where it helps to be willing to look like a dork, or even a fool, as Kitt wrote about yesterday.)

When asking for help, this is the approach I take.  When I post to mailing lists or forums, it usually comes out as, “Here’s what I think is so, but results don’t match that understanding.  What am I missing?  Please help me get it right.”

How am I wrong?  Because I’m probably wrong.

This article was originally published at The Pastry Box Project on 2 November 2015.

To get access to screenshot, you first have to hit ⇧F2 for the Developer Toolbar, not ⌥⌘K for the Web Console.  (I know, two command lines—who thought that was a good idea?  Moving on.)  Once you’re in the Developer Toolbar, you can type s and then hit Tab to autocomplete screenshot.  Then type a filename for your screenshot, if you want to define it, either with or without the file extension; otherwise you’ll get whatever naming convention your computer uses for screen captures.  For example, mine does something like Screen Shot 2015-10-22 at 10.05.51.png by default.  If you hit [return] (or equivalent) at this point, it’ll save the screenshot to your Downloads folder (or equivalent).  Done!

Except, don’t do that yet, because what really makes screenshot great is its options; in my case, they’re what elevate screenshot from useful to essential, and what set it apart from any screen-capture addon I’ve ever seen.

The option I use a lot, particularly when grabbing images of web sites for my talks, is --fullpage.  That option captures absolutely everything on the page, even the parts you can’t see in the browser window.  See, by default, when you use screenshot, it only shows you the portion of the page visible in the browser window.  In many cases, that’s all you want or need, but for the times you want it all, --fullpage is there for you.  Any time you see me do a long scroll of a web page in a talk, like I did right at the ten-minute mark of my talk at Fluent 2015, it was thanks to --fullpage.

If you want the browser --chrome to show around your screenshot, though, you can’t capture the --fullpage.  Firefox will just ignore the -fullpage option if you invoke --chrome, and give you the visible portion of the page surrounded by your browser chrome, including all your addon icons and unread tabs.  Which makes some sense, I admit, but part of me wishes someone had gone to the effort of adding code to redraw the chrome all the way around a --fullpage capture if you asked for it.

Now, for the purposes of CSS:TDG4e’s figures, there are two screenshot options that I cannot live without.

The first is --selector, which lets you supply a CSS selector to an element—at which point, Firefox will capture just that element and its descendants.  The only, and quite understandable, limitation is that the selector you supply must match a single element.  For me, that’s usually just --selector 'body', since every figure I create is a single page, and there’s nothing in the body except what I want to include in the figure.  So instead of trying to drag-select a region of the screen with ⇧⌘4, or (worse) trying to precisely size the browser window to show just the body element and not one pixel more, I can enter something like screenshot fig047 --selector 'body' and get precisely what I need.

That might seem like a lot to type every time, but the thing is, I don’t have to: not only does the Web Toolbar have full tab-autocomplete, the Toolbar also offers up-arrow history.  So once I’ve tab-completed the command to capture my first figure, I just use the up arrow to bring the command back and change the file name.  Quick, simple, efficient.

The second essential option for me is --dpr, which defines a device pixel ratio.  Let’s say I want to capture something at four times the usual resolution.  --dpr 4 makes it happen.  Since all my figures are meant to go to print as well as ebooks, I can capture at print-worthy resolutions without having to use ⌘+ to blow up the content, or fiddle with using CSS to make everything bigger.  Also if I want to go the other way and capture a deliberately pixellated version of a page, I can use something like --dpr 0.33.

I have used this occasionally to size down an image online: I “View Image” to get it in its own window, then use screenshot with a fractional DPR value to shrink it.  Yes, this is a rare use case, even for me, but hey—the option exists!  I haven’t used the DPR option for my talks, but given the growing use of HD 16:9 projectors—something we’ve been using at An Event Apart for a while now, actually—I’m starting to lean toward using --dpr 2 to get sharper images.

(Aside: it turns out this option is only present in very recent versions of Firefox, such as Developer Edition 43 and the current Nightlies.  So if you need DPR, grab a Nightly and go crazy!)

And that’s not all!  You can set a --delay in seconds, to make sure a popup menu or other bit of interaction is visible before the capture happens.  If you want to take your captured image straight into another program before saving it, there’s --clipboard.  And there’s an option to upload straight to --imgur, though I confess I haven’t figured out how that one works.  I suspect you have to be logged into imgur first.  If anyone knows, please leave a comment so the rest of us know how to use it!

The one thing that irks me a little bit about screenshot is that the file name must come before the options.  When I’m producing a bunch of figures in a row, having to drag-select just the file name for replacement is a touch tedious; I wish I could put the file name at the end of the command, so I could quickly drag-select it with a rightward wrist-flick.  But all things considered, this is a pretty minor gripe.  Well, shut my mouth and paint me red—it turns out you can put the filename after the options.  Either that wasn’t possible at some point and I never retested the assertion, or it was always possible and I just messed up.  Either way, this irk is irksome no more!

The other thing I wish screenshot could do is let me define a precise width or height in pixels—or, since I’m dreaming, a value using any valid CSS length unit—and scale the result to that measure.  This isn’t really useful for the CSS:TDG4e figures, but it could come in pretty handy for creating talk slides.  No, I have no idea how that would interact with the DPR option, but I’d certainly be willing to find out.

So that’s one of my “unusual but essential” tools.  What’s yours?

First they announced that they aren’t adding a Dislike button, but they are adding a set of six emoji reactions to the “Like” button, so you can indicate a wider range of emotion.  Some people immediately linked this to Slack, as if emoji reactions hadn’t been a thing on social media for the last couple of years.  I happened to see Sally Herships asking “what are your thoughts?” about it on Twitter (heh), and oh, I had thoughts.  I ended up sharing some of those thoughts by phone, and one of them was part of a segment on American Public Media’s Marketplace.

It’s funny, in a way, that my thought on marketing and advertisers was what made it into the piece, because I think that was literally my whole thought about that side of things.  Most of the rest of my conversation with Sally was about how Facebook could use these reactions as a way to avoid insensitive design choices.  As an example, a status update that gets lots of interaction in the frowny-face or sad-face realm could be avoided when it comes to things like Year in Review.  I said something to the effect of:

People are sharing everything about their lives, positive and negative, billions of us every day.  That isn’t going to stop, so it’s great to see Facebook making changes to meet us where we are, or at least meet us partway.

These reaction emoji almost certainly aren’t the last word on this, but they’re a credible initial attempt.  In more than one sense, they’re a first step into a larger world.

Next, Facebook introduced filtering for its On This Day (OTD) feature.  This is another step in the evolution of On This Day, one that’s very welcome.  Facebook had already been revising its language to be more humane, shifting from simple “Relive this memory” to nuanced language expressing care and openness.

With its new OTD preferences, Facebook now lets you define ranges of dates you’d like to be blacklisted, in effect, as well as people you don’t want to see memories about.  I’d commented on the lack of this, back when OTD launched:

…what I notice here is what’s missing:  I don’t see any reference to an ability to opt out of On This Day, either for certain days or altogether.

So far as I can tell, you still can’t opt out entirely; even if you turn off all notifications, you can still get memories inserted into your timeline.  For me, I see about one a month, more or less.  But here’s the interesting thing: they’re almost never my memories.  In what I still regard as a major gamble by Facebook, On This Day will show you posts, pictures, and videos posted by someone else, but on which you were tagged.  I presume (though I have no simple way to test) that adding a person in the OTD filtering preferences will prevent you from seeing memories in which they’re tagged as well as memories they posted.

If so, that’s a really smart step, as I can only imagine how a spiteful ex might abuse OTD.  It still leaves open the possibility of old posts that you don’t remember being tagged on suddenly appearing.  In many cases, that will be a delightful moment, but in many others, the exact opposite of that.  This is why I regard Facebook’s decision to show you posts from other people a gamble.  Even if they show unwanted memories to just 1% of their user base—a ridiculously low percentage—that’s literally 10 million people a day.

Still: wrinkles or no, flaws or no, the presence of filtering preferences is a major enhancement to On This Day.  I could block out all of June 2014, if I so chose.  There might be years where I blocked it, and others where I removed the block.  The important thing is that I’m being given that capability, in an environment that’s already designed to show me memories and acknowledge that it’s easy to get that wrong.  The user experience for adding filters is still clunky, but much like the reaction emoji, I view this as a credible first try, not the final word.

All this has made for some interesting Slack discussions between me and Sara, as we literally just finished the manuscript for our forthcoming, still-not-quite-titled-but-we’re-really-close-honest book on compassion in design.  Which has references to things like On This Day, so we’re already revising a book that hasn’t even been published yet.  And when will it be published?  We’re pulling for early next year, which sounds like a long way away until you remember that 2015 is getting close to done.

Kudos to Facebook, both for its efforts to be kinder in what they do and for its willingness to try.  Not many businesses, let alone social-media titans, have had the courage to think about what can go wrong in this realm, let alone actually acknowledge missteps and work to do better.  Well done.

• CSS and Documents, which covers the raw basics of how CSS is associated with HTML, including some of the more obscure ways of strapping external styles to the document as well as media query syntax.  It’s free to download in any of the various formats O’Reilly offers.
• Selectors, Specificity, and the Cascade, which combines two chapters to cover all of the various Level 3 selector patterns as well as the inner details of how specificity, inheritance, and cascade.
• Values, Units and Colors, which covers all the various ways you can label numbers as well as use strings.  It also takes advantage of the new cheapness of color printing to use a bunch of nice color-value figures that aren’t forced to be all in grayscale.
• CSS Fonts, which dives into the gory details of @font-face and how it can deeply affect the use of font-related properties, both those we use widely as well as many that are quickly gaining browser support.
• CSS Text, which covers all the text styles that aren’t concerned with setting the font face—stuff like indenting, decoration, drop shadows, white-space handling, and so on.
• Basic Visual Formatting in CSS, which covers how block, inline, inline-block, and other boxes are constructed, including the surprisingly-complicated topic of how lines of text are constructed.  Very fundamental stuff, but of course fundamentals are called that for a reason.
• Transforms in CSS, which is currently FREE in ebook format, covers the transform property and its closely related properties.  2D, 3D, it’s all here.
• Colors, Backgrounds, and Gradients, which covers those three topics in FULL GLORIOUS COLOR, fittingly enough.  Curious about the new background sizing options?  Ever wondered exactly how linear and radial gradients are constructed?  This book will tell you all that, and more.

Here’s what I have planned to write next:

• Padding, Borders, Outlines, and Margins — including the surprisingly tricky border-image
• Positioning – basically an update, with new and unexpected twists that have been revealed over the years (case in point)
• Grid Layout – though this is coming faster than many of us realize, I may put this one off for a little bit while we see how browser implementations go, and find out what changes happen as a result

My co-author, Estelle, has these three chapters/short books currently in process:

• Transitions
• Animations
• Flexbox

Beyond those 14 chapters, we have eight more on the roster, covering topics like floating, multicolumn layout, shapes, and more.  CSS is big now, y’all.

So that’s where we are right now.  Our hope is to have the whole thing written by the middle of 2016, at which point some interesting questions will have to be answered.  While most of the book is fine in grayscale, there are some chapters (like Colors, Backgrounds, and Gradients) that really beenfit from being in color.  Printing a 22-chapter book in color would make it punishingly expensive, even with today’s drastically lower cost of color printing.  So what to do?

Not to mention, printing a 22-chapter book is its own level of difficulty.  Even if we assume an average of 40 pages a chapter—an unreasonabnly low figure, but let’s go with it—that’s still a nine hundred page book, once you add front and back matter.  The binding requirements alone gets us into the realm of punishingly expensive, even without color.

Of course, ebook readers don’t have to care about any of that, but some people (like me) really do prefer paper.  So there will be some interesting discussions.  Print in two volumes?  Sell the individual chapter books in a giant boxed set, Chronicles of Narnia style?  We’ll see!

Lanyrd says 72 as I write this, with two more coming this year.  But Lanyrd only goes back to 2003, so I already know it’s missing some of my past appearances.  Everything from 1995 (or was it 1996?) through 2003, for example.  The talks I’ve done for college classes and user groups in Cleveland.  Probably others as well.  So let’s round it off to an even one hundred, and pretend like that’s a meaningful milestone or something.

I used to talk about code, style, standards, all that stuff.  It was all, as the cliché goes, subjects for which I had prepared not my talk, but myself.  I knew the subject so thoroughly, I pretty much never wrote out a script.  I wrote an outline, assembled slides or demos or whatever to support that outline, and then mostly improvised my way through the talk.  The closest I got to rehearsal was back in 2007, I think, when my talk was two slides in Keynote and then a bunch of pre-created style snippets that I dropped into a live web page, saving and reloading, talking about the changes as I went.  Live-coding, except without relying on my sloppy typing skills.

(That one was called “Secrets of the CSS Jedi”, where I took a table of data, marked up as such, and turned it into a bar graph live on stage, the summary line of which I still remember: “CSS does not care what you think an element should look or act like.  You have far more power than you realize.”  That was a revolutionary thing to say back then.  We were coders once, and young.)

These days, my talks are nearly or entirely code-free, as I explore topics like compassion in design, and the ways that our coding has a profound influence on society now and into the future.  The talks generally start life as 9,000-word essays that I edit, rearrange, patch up, re-edit, polish, and then rehearse.  After the first two rehearsals, I re-re-edit and re-polish.  Then I rehearse several more times.

The point of all this being:

I stumble through my rehearsals, getting more and more incoherent, getting more frustrated every time I have to start over, certain I’ll never get the words to work, increasingly convinced it means the ideas behind them have no merit at all, until I want to curl up in a cushion fort and never come out.  I grapple with the fear that even if by some miracle I do have one or two worthwhile things to say, they’ll be buried in a flood of stuttered half-sentences and self-protective rhetorical tricks.

So I get nervous before my talks.  Adrenaline surges through me, elevating my pulse and making my palms sweat as they get prickly, the cold fire washing up my arms and into my cheeks.  I pace and fidget, concentrating on my breathing so I don’t hyperventilate.  Or hypoventilate, for that matter.

I do this before every talk I give at An Event Apart, even when I’ve given the talk half a dozen times previously.  I did it before I hit the stage at XOXO 2015.  I did it before I started my talks at Rustbelt Refresh.

A hundred public talks or more, and it’s still not easy.  I’m not sure it ever will be easy.  I’m not sure it ever should be easy.

The further point being:

Every speaker I know feels pretty much exactly the same.  We don’t all get the same nervous tics, but we all get nervous.  We struggle with our fears and doubts.  We all feel like we have no idea what we’re doing.

So if you’re afraid to get up in front of people and share what you know: you’re in very, very good company.  I know this, because I am too.

If you have something to share—and you do—try not to let the fear stop you.

We’re all afraid up there.

This article was originally published at The Pastry Box Project on 2 October 2015.

Consider: a user who runs a content blocker can prevent the loading of Javascript, CSS, cookies, and web fonts.  (They can block more than that, but those asset types seem to be the main targets thus far.)  A person loading an article or other page from a web site gets the content, and that’s it, assuming the publisher hasn’t put some sort of “go away” server-side script in place.

Sound familiar?  It should.  We’ve been here before.  It’s 1995 all over again.

And, just as in 1995, publishers are faced with a landscape where they’re not sure how to make money, or even if they can make money.

Content blockers are a two-decade reset button.  We’re right back where we were, twenty years ago.  Except this: we already know a bunch of stuff that doesn’t work.

I don’t mean that ads don’t work.  Ads can work.  We’ve seen small, independent ad networks like The Deck do pretty okay.  They didn’t make anyone a billionaire, but they provided a good audience to advertisers via a low-impact mechanism, and some earnings for those who ran the ads and the network.

The ads that are at risk now are the ones delivered via bloated, badly managed, security-risk mechanisms.  In other words: what’s at risk here is terrible web development.

Granted, the development of these ads was so terrible that it made the entire mobile web ecosystem appear far more broken that it actually is, and prompted multiple attempts to rein it in.  Now we have content blockers, which are basically the nuclear option: if you aren’t going to even attempt to respect your customers, they’re happy to torch your entire infrastructure.

Ethical?  Moral?  Rational?  Hell if I know or care.  Content blockers became the top paid apps within hours of iOS9’s release, and remain so.  The market is speaking incredibly loudly.  It’s almost impossible not to hear it.  The roar is so loud, in fact, it’s difficult to make out what people are actually saying.

I have my interpretation of their shouting, but I’m going to keep it to myself.  The observation I really want to make is this: the entire industry is being given a do-over here.  Not the ad industry; the web industry.

Remember, this isn’t just about ads.  Ads are emblematic of the root problem, but they’re not the actual root problem.  If ads were the sole concern of content blockers, then the blockers (mostly) wouldn’t bother to block web fonts.  It’s possible to use web fonts smartly and efficiently, but most sites don’t, so web fonts are a major culprit in slow mobile load times.  The same is true for Javascript, whether it’s served by an ad network, an analytics engine, or some other source.  So they’re both targeted by blockers—not for enabling ads, but for disabling the web.

Content blockers strip the web back to what it was 20 years ago.  All the same challenges and questions are back, full force.  How do we make sites better, smarter, and cooler?  How do we make money by publishing online?

There are reputations and probably fortunes to be made by learning from our many mistakes and finding new, smarter ways to move forward.  I would advocate that people start with the core principles of the web standards movement, particularly progressive enhancement, but those are starting points, a foundation—just as they always were.

It’s not often that an entire industry gets an almost literal do-over.  We have two decades of hindsight to work with now, as we try to figure out how to (re)build a web where users don’t feel like they need content blockers just to be online.  This is an incredibly rare and exciting juncture.  Let’s not waste it.

That’s not because what happens now will change you or me.  We’re unlikely to change much, if at all.  We’re set in our ways, most of us.

Our children are not.

What they see online will seem normal to them, just as what we saw growing up seemed normal to us.  And because there is no meaningful distinction between online and offline, what they come to accept as normal online will be seen as normal offline.

So the way we build our networks matters in the most profound possible way.  If we build networks that make it easy to abuse and harass, and make it difficult to defend against abuse and harassment, our children will come to see that as normal, even desirable.  Similarly, if we build networks where it’s hard to abuse and harass, and easy to defend against such attempts, that will become the norm.

System design is social design.  The question is, what kind of society do we want to design?

And the more important question is, when are we going to start?

This article was originally published at The Pastry Box Project on 2 September 2015.