So in mid-1999, we were deep in the throes of Y2K certification. The young’uns in the audience won’t remember this, but to avoid loss of data and services when the year rolled from 1999 to 2000, pretty much the entire computer industry was engaged in a deep audit of every computer and program under our care. There’s really been nothing quite like it, before or since, but the job got done. In fact, it got done so well, barely anything adverse happened and some misguided people now think it was all a hoax designed to extract hefty consulting fees, instead of the successful global preventative effort it actually was.

As for us, pretty much everything on the Web side was fine. And then, in the middle of one of our staff meetings about Y2K certification, John Sully said something to the effect of, “Wouldn’t it be funny if the Web server suddenly thought it was 1900 and you had to use a telegraph to connect to it?”

We all laughed and riffed on the concept for a bit and then went back to Serious Work Topics, but the idea stuck in my head. What would a 1900-era Web site look like? Technology issues aside, it wasn’t a complete paradox: the ancestor parts of CWRU, the Case Institute of Technology and the Western Reserve University, had long existed by 1900 (founded 1880 and 1826, respectively). The campus photos would be black and white rather than color, but there would still be photos. The visual aesthetic might be different, but…

I decided so make it a reality, and CWRU2K was born. With the help of the staff at University Archives and a flatbed scanner I hauled across campus on a loading dolly, I scanned a couple dozen photos from the period 1897–1900-basically, all those that were known to be in the public domain, and which depicted the kinds of scenes you might put on a Web site’s home page.

Then I reskinned the home page to look more “old-timey” without completely altering the layout or look. Instead of university-logo blues and gold, I recolored everything to be wood-grain. Helvetica was replaced with an “Old West” font in the images, of which there were several, mostly in the form of MM_swapimage-style rollover buttons. In the process, I actually had to introduce two Y2K bugs to the code we used to generate dates on the page, so that instead of saying 2000 they'd actually say 1899 or 1900. I altered other things to match the time, like altering the phone number to use two-letters-then-numbers format while still retaining full international dialing information and adding little curlicues to things. Well before the holidays, everything was ready.

The files were staged, a cron job was set up, and at midnight on January 1st, 2000, the home page seamlessly switched over to its 1900 incarnation. That’s a static snapshot of the page, so the picture will never change, but I have a gallery of all the pictures that could appear, along with their captions, which I strove to write in that deadpan stating-the-obvious tone the late 19th Century always brings to my mind. (And take a close look at the team photo of The Rough Riders!)

In hindsight, our mistake was most likely in adding a similarly deadpan note to the home page that read:

Year 2000 Issues

Despite our best efforts at averting Y2K problems, it seems that our Web server now believes that it is January of 1900. Please be advised that we are working diligently on the problem and hope to have it fixed soon.

I say that was a mistake because it was quoted verbatim in stories at Wired and The Washington Post about Y2K glitches. Where they said we’d actually suffered a real, unintentional Y2K bug, with Wired giving us points for having “guts” in publicly calling “a glitch a glitch”. After I emailed both reporters to explain the situation and point them to our press release about it, The Washington Post did publish a correction a few days later, buried in a bottom corner of page A16 or something like that. So far as I know, Wired never acknowledged the error.

CWRU2K lasted a little more than a day. Although we’d planned to leave it up until the end of January, we were ordered to take it down on January 2nd. My boss, Ron Ryan, was directed to put a note in my Permanent Record. The general attitude Ron conveyed to me was along the lines of, “The administration says it’s clever and all, but it’s time to go back to the regular home page. Next time, we need to ask permission rather than forgiveness.”

What we didn’t know at the time was how close he’d come to being fired. At Ron’s retirement party last year, the guy who was his boss on January 2nd, 2000, Jim Barker, told Ron that Jim had been summoned that day to a Vice President’s office, read the riot act, and was sent away with instructions to “fire Ron’s ass”. Fortunately, Jim… didn’t. And then kept it to himself for almost 20 years.

There were a number of other consequences. We got a quite a bit of email about it, some in on the joke, others taking it as seriously as Wired. There’s a particularly lovely note partway down that page from the widow of a Professor Emeritus, and have to admit that I still smile over the props we got from folks on the mailing list. I took an offer to join a startup a couple of months later, and while I was probably ready to move on in any case, the CWRU2K episode-or rather, the administration’s reaction to it-helped push me to make the jump. I was probably being a little juvenile and over-reacting, but I guess you do that when you’re younger. (And I probably would have left the next year regardless, when I got the offer to join Netscape as a Standards Evangelist. Actual job title!)

So, that’s the story of how Y2K affected me. There are some things I probably would have done differently if I had it to do over, but I’m 100% glad we did it.

Originally published at meyerweb.com on January 1, 2020.

I’ve had it for so long, I’d forgotten how long I’ve had it. I searched for information about its production dates and wouldn’t you know it, Wikipedia has an article devoted solely to Logitech products throughout history, because of course it does, and it lists (among other things) their dates of release. The MX500 was released in 2002, and superseded by the MX510 in 2004. I then remembered a photo I took of my eldest child when she was an infant, trying to chew on a computer mouse. I dug it out of my iPhoto library and yep, it’s my MX500. The picture is dated June 2004.

So I have photographic evidence that I’ve used this specific mouse for 15 years or more. The logo plate on top of the mouse has been worn half-smooth and half-paintless by the palm of my hand, much like the shiny-smooth areas worn into the subtle matte surface texture where the thumb and pinky finger grip the sides. The model and technical information printed on the underside has similarly worn away. It started out with four little oval glide nubs on the underside that held the bottom away from the desk surface; only one remains. Even though, as an optical mouse, it can be used on any surface, I eventually went back to soft mousepads, so as to limit further undercarriage damage.

Why have I been so devoted to this mouse? Well, it’s incredibly well engineered, for one — it’s put up with 15 years of daily use. It’s exactly the right shape for my hand, and it has multiple configurable inputs right where I expect them. There are arrow buttons just above my thumb which I use as forward/backward in browsers, buttons above and below the scroll wheel that I map to Page Up/Page Down, an extra button at almost the apex of the mouse’s back mapped to ⌥⇥ (Option-Tab), and the usual right click/left mouse buttons. Plus the scroll wheel is itself a push-down-to-click button.

Most of these features can be found on one mouse or another, but it’s rare to find them all in one mouse — and next to impossible to find them in a shape and size that feels comfortable to me. I’d occasionally looked at the secondary market, but even used, the MX500 can command three figures. I checked Amazon as I wrote this, and an unused MX500 was listing for two hundred fifty dollars. Unused copies of its successor, the MX510, were selling for even more.

Now, if you were into gaming in the first decade of the 2000s, you may have heard of or used the MX510’s successor, the MX518. Released in 2005, it was basically an MX500/MX510, but branded for gaming, with some optical-sensor upgrades for more tracking precision. The MX518 lasted until 2011, when it was superseded by a different model, which itself was superseded, which et cetera, et cereta, et cetera.

Which brings me to the point of all this. A few weeks ago, after a several weeks of sporadic glitches, the scroll wheel on my MX500 almost completely stopped responding to being scrolled. Which maybe doesn’t sound like a big deal, but try going without your scroll wheel for a while. I was surprised to discover how much I relied on it. So, glumly, knowing the model was long out of production and incredibly expensive to buy, I went searching for equivalents.

And that’s when I discovered that Logitech had literally announced less than a week earlier that they were releasing an updated MX518, available for pre-order.

Friends, I have never pre-ordered anything so fast.

This past Thursday afternoon, it arrived. I got it set up and have been working with it since. And I have some impressions.

Physically, the MX518 Legendary (as Logitech has branded it) is 95% a match for my old MX500. It’s ever so slightly smaller, just enough that I can tell but not quite enough to be annoying, odd as that may seem. Otherwise, everything feels like it should. The buttons are crisp and clicky, and right where I expect them. And the scroll wheel… well, it works.

The coloration is different — the surface and buttons are all black, as opposed to the MX500’s black-and-silver two-tone styling. While I miss the two-tone a bit, there’s an upgrade: the smooth black top surface has subtle little sparkles embedded in the paint. Shiny!

On the other hand, configuring the mouse was a bit of an odyssey. First off, let me make clear that I have a weird setup, even for a grumpy old Mac user. I plug a circa-2000 Macally original iKey 104-key keyboard into my 2013 MacBook Pro. (Yes, you have sensed a trend here: when I find hardware I really like, I hang onto it like a rabid weasel. Ditto software.) The “extra” keys on the Macally like Page Up, Home, and so on don’t get recognized by a lot of current software. Even the Finder can’t read the keyboard’s function keys properly. I’ve restored their functionality with the entirely excellent BetterTouchTool, but it remains that the keyboard is just odd in its ancientness.

Anyway, I first opened System Preferences and then the Logitech Control Center pane. It couldn’t find the MX518 Legendary at all. So next I opened the (separate) Logitech Options pane, which drives the wireless mouse I use when I travel. It too was unable to find the MX518.

Some Bing-ing led me to a download for Logitech Gaming Software (hereafter LGS), which I installed. That could see the MX518 just fine. Once I stumbled my way into an understanding of LGS’s UI, I set about trying to configure the MX518’s buttons to do what I wanted.

And could not. In the list of predefined mouse actions that could be assigned to the buttons, precisely none of my desires were listed. No ⌘-arrow combos, no page up or down, not even ⌥⇥ to switch apps. I mean, I guess that’s to be expected: it’s sold as a gaming mouse. LGS has plenty of support for on-the-fly-dee-pee-eye switching and copy-paste and all that. Not so much for document editing and code browsing.

There is a way to assign keyboard combos to buttons, but again, the software could understand precisely none of the combos I wanted to record when I typed them on my Macally. So I went to the MacBook Pro’s built-in keyboard, where I was able to register ⌥⇥, ⌘→, and ⌘←. I could not, however much I tried, register Page Up or Page Down. I pressed Fn, which showed “Fn” in the LGS software, and then pressed the down arrow for Page Down, and as long as I held down both keys, it showed “Page Down”. But as soon as I let go of the down arrow, “Fn” was registered again. No Page Down for me.

Now, recall, this was happening on the laptop’s built-in keyboard. I can’t really blame this one on age of the external Macally. I really think this one might fall on LGS itself; while a 2013 MacBook is old, it’s not that old.

I thought I might be stuck, but I intuited a workaround: I opened the Keyboard Viewer app built into the Finder. With that, I could just click the virtual Page Up and Page Down keys, and LGS registered them without a hiccup. While I was in there, I used it to set the scroll wheel’s middle-button click to trigger Mission Control (F3).

The one letdown I have is that the buttons don’t appear to repeat keystrokes. So if I hold the button I’ve assigned to Page Down for example, I get exactly one page-down, and that’s it until I release and click the button again. On the MX500, holding down the button assigned to Page Down would just constantly page down until I let go. This was sometimes preferable to scrolling with the scroll wheel, especially for long documents I wanted to very quickly scan for a certain figure or other piece of the page. The same was true for all the buttons: hold it down, and the thing it was configured to do happened repeatedly until you let go.

The MX518 Legendary isn’t doing that. I don’t know if this is an inherent limitation of the mouse, its software, my configuration of it, the interaction of software and operating system, or something else entirely. It’s not an issue forty-nine times out of fifty, but that fiftieth time is annoying.

The other annoyance is one of possibly missed potential. The mouse software has, in keeping with its gaming focus, the ability to set up multiple profiles; that way, you can assign unique actions to the buttons on a per-application basis. I set up a couple of profiles to test it out, but LGS is completely opaque about how to make profiles switch automatically when you switch to an app. I’ll look for an answer online, but it’s annoying that the software promises per-app profiles, and then apparently fails to deliver on that promise.

So after all that, am I happy? Yes. It’s essentially my old mouse, except brand new. My heartfelt thanks to Logitech for bringing this workhorse out of retirement. I look forward to a decade or more with it.

Originally published at meyerweb.com on March 18, 2019.

In the middle of last month (July 2018), I found myself staring at a projector screen, waiting once again to see if Wikipedia would load. If I was lucky, the page started rendering 15–20 seconds after I sent the request. If not, it could be closer to 60 seconds, assuming the browser didn’t just time out on the connection. I saw a lot of “the server stopped responding” over the course of a few days.

It wasn’t just Wikipedia, either. CNN International had similar load times. So did Google’s main search page. Even this here site, with minimal assets to load, took a minimum of 10 seconds to start rendering. Usually longer.

In 2018? Yes. In rural Uganda, where I was improvising an introduction to web development for a class of vocational students, that’s the reality. They can have a computer lab full of Dell desktops running Windows or rows of Raspberry Pis running Ubuntu or whatever setup there is, but when satellites in geosynchronous earth orbit are your only source of internet, you wait. And wait. And wait.

I want to explain why — and far more importantly, how we’ve made that experience interminably worse and more expensive in the name of our comfort and security.

First, please consider the enormously constrained nature of satellite internet access. If you’re already familiar with this world, skip ahead a few paragraphs; but if not, permit me a brief description of the challenges.

For geosynchronous-satellite internet access, the speed of light become a factor in ping times: just having the signals propagate through a mixture of vacuum and atmosphere chews up approximately half a second of travel time over roughly 89,000 miles (~152,000km). If that all that distance were vacuum, your absolute floor for ping latency is about 506 milliseconds.

That’s just the time for the signals to make two round trips to geosynchronous orbit and back. In reality, there are the times to route the packets on either end, and the re-transmission time at the satellite itself.

But that’s not the real connection killer in most cases: packet loss is. After all, these packets are going to orbit and back. Lots of things along those long and lonely signal paths can cause the packets to get dropped. 50% packet loss is not uncommon; 80% is not unexpected.

So, you’re losing half your packets (or more), and the packets that aren’t lost have latency times around two-thirds of a second (or more). Each.

That’s reason enough to set up a local caching server. Another, even more pressing reason is that pretty much all commercial satellite connections come with data caps. Where I was, their cap was 50GB/month. Beyond that, they could either pay overages, or just not have data until the next month. So if you can locally cache URLs so that they only count against your data usage the first time they’re loaded, you do that. And someone had, for the school where I was teaching.

But there I stood anyway, hoping my requests to load simple web pages would bear fruit, and I could continue teaching basic web principles to a group of vocational students. Because Wikipedia wouldn’t cache. Google wouldn’t cache. Meyerweb wouldn’t cache. Almost nothing would cache.

Why?

HTTPS.

A local caching server, meant to speed up commonly-requested sites and reduce bandwidth usage, is a “man in the middle”. HTTPS, which by design prevents man-in-the-middle attacks, utterly breaks local caching servers. So I kept waiting and waiting for remote resources, eating into that month’s data cap with every request.

The drive to force every site on the web to HTTPS has pushed the web further away from the next billion users — not to mention a whole lot of the previous half-billion. I saw a piece that claimed, “Investing in HTTPS makes it faster, cheaper, and easier for everyone.” If you define “everyone” as people with gigabit fiber access, sure. Maybe it’s even true for most of those whose last mile is copper. But for people beyond the reach of glass and wire, every word of that claim was wrong.

If this is a surprise to you, you’re by no means alone. I hadn’t heard anything about it, so I asked a number of colleagues if they knew about the problem. Not only had they not, they all reacted the same way I did: this must not be an actual problem, or we’d have heard about it! But no.

Can we do anything? For users of up-to-date browsers, yes: service workers create a “good” man in the middle that sidesteps the HTTPS problem, so far as I understand. So if you’re serving content over HTTPS, creating a service worker should be one of your top priorities right now, even if it’s just to do straightforward local caching and nothing fancier. I haven’t gotten one up for meyerweb yet, but I will do so very soon.

That’s great for modern browsers, but not everyone has the option to be modern. Sometimes they’re constrained by old operating systems to run older browsers, ones with no service-worker support: a lab full of Windows XP machines limited to IE8, for example. Or on even older machines, running Windows 95 or other operating systems of that era. Those are most likely to be the very people who are in situations where they’re limited to satellite internet or other similarly slow services with unforgiving data caps. Even in the highly-wired world, you can still find older installs of operating systems and browsers: public libraries, to pick but one example. Securing the web literally made it less accessible to many, many people around the world.

Beyond deploying service workers and hoping those struggling to bridge the digital divide make it across, I don’t really have a solution here. I think HTTPS is probably a net positive overall, and I don’t know what we could have done better. All I know is that I saw, first-hand, the negative externality that was pushed onto people far, far away from our data centers and our thoughts.

My thanks to Tim Kadlec and Ethan Marcotte for their feedback and insight while I was drafting this post, and to Lara Hogan and Aaron Gustafson for their early assistance wth my research.

Originally published at meyerweb.com on August 7, 2018.

The twentieth anniversary is, traditionally, the china anniversary. Kat’s immediate reaction upon hearing this was that it makes total sense, since by 20 years you’ve probably broken most of your wedding china and need replacements. For us, though, the resonance is a little different, since our honeymoon was a trip to China. And therein hangs an origin story.

At some point in the late 1997, Kat and I were at a Meyer family gathering, probably Thanksgiving, at my paternal grandparents’ house in Cincinnati. As was my wont, I was perusing the stacks of National Geographics they had always lying around. Not like in a dentist’s office; no, these were always up to date. But there were always many of them, interleaved with many similarly contemporary Readers’ Digests.

I picked up one with a cover shot and title about China’s Three Gorges, and started leafing through it, eventually reaching the cover story. It chronicled the incredible landscapes of the Three Gorges of the Yangtze River, soaring cliff faces and ancient villages, I was immediately captivated by the story and especially the photography. I decided that I wanted to see the Gorges before they were submerged by the Three Gorges Dam Project, which is the sort of snap decision I almost never make. Usually I take time to analyze an idea and game out scenarios before reaching a conclusion, but not this time. I was immediately certain. I was certain enough to say it out loud to other people, like Kat and my parents and, who knows, probably a bunch of my extended family.

Now, fast forward a bit. At the end of that same year, Kat and I were with my parents for Christmas. We went out to dinner at Mom’s favorite spot for her birthday (also Boxing Day) and my parents said they had presents for me and my sister. We each got an envelope.

Both of them contained checks for several thousand dollars, windfall of an inheritance distribution that Mom had insisted be passed on to us. In mine, with the check, were a number of brochures for tours of China.

I was speechless. Kat asked what it was a couple of times, a little bewildered by the look on my face.

And here I must take a side trip. Kat and I had been on a trip to California a few weeks prior, just the two of us. We spent a couple of nights at Ragged Point, a spot I’d stumbled over on a previous solo trip, back in the days when the rooms intentionally had no TVs or phones. The restaurant was booked by a large group, so we ate dinner alone on the open patio under a heat umbrella, looking at the stars and enjoying the fantastic food; the chef at the time was a genius. Music played softly through hidden speakers, and although we were literally sitting outside it felt as quiet and private as any candlelit back room.

“The Christmas Song”, generally better known as “Chestnuts Roasting on an Open Fire”, started playing. Kat, smiling, asked me if I would like to dance. So we stood and danced close together, slowly shuffling around the open space the way untrained dancers do, just us and the song and the stars.

Kat swears I drew breath and opened my mouth to ask her to marry me. Maybe she’s right. But I didn’t, then. Nor the next day. Nor on Christmas Day. Which caused Kat to start thinking that maybe it wasn’t going to happen at all. She was feeling disappointed and hurt by this, as you can probably imagine, but keeping it to herself because she wasn’t sure yet if she was right or wrong.

So: back to Mom’s birthday dinner in Mansfield, Ohio, and me sitting stunned by the check and the China brochures and this unexpected, unprecedented windfall.

“Eric, what is it?” Kat asked again, with some concern starting to color her words.

“We’re going to China!” I finally blurted out.

“No, you’re going to China,” she replied a little tartly.

“No, we’re going to China,” I repeated.

Because in that moment, right there, I knew that this trip I wanted to take, the things I wanted to see so badly before they were gone — I couldn’t imagine doing and seeing all that without Kat.

That’s when I knew, beyond any shadow of a doubt, that I wanted to marry her.

I didn’t propose that night either, because I had to explain this all to her in halting, still-new words and help her (and me!) understand what had happened. She got it, as I think I knew she would. We went shopping for rings just after the New Year. I formally proposed to her, shivering on an ice-crusted deck by the Chagrin Falls, on her birthday in March.

And on July 19th, 1998, we stood underneath the spreading boughs of the tree in the front yard of her childhood home, and exchanged our wedding vows. A short time later, in a backyard tent in the heat of a mid-July afternoon on Long Island, we stood on the compact dance floor and danced to “The Christmas Song”, baffling half the attendees and bemusing the other half.

The next very day, we flew to China, and saw so much together over the next seventeen days: the Three Gorges, yes, but much more. Suzhou, Dazu, and Guilin stand out in particular for being a little more remote and not so overrun by tourists, the kinds of spots we always find inherently more interesting than large cities and glitzed-up, polished destinations. We still want to go back to Guilin some day.

In the two decades since we vowed to love and honor and respect and amuse each other, we’ve had many adventures together. Some were incredible, some were stressful, and some I would have spared us both. Picking out a card was difficult, with so many of them written as if 20 years together could never be anything but an unbroken stretch of bliss and good fortune. We’ve been through too much to respond well to such bromides; we’ve had fortune great and terrible, difficulty and ease, endless joy and boundless grief.

Every one of those days and weeks and months and years, we’ve supported and shared with each other. Kat’s been so strong, and so selfless, and I’ve tried to be the same for her. Neither of us did so perfectly, but we always tried — and we always understood when the other had to nurse a weakness, or look inward for a while. We have always been honest with each other, and accepted each other. That, more than anything, is what’s allowed us to travel together these two decades and still love each other.

I couldn’t have asked for a better partner in life and death than Kat, and I hope she’s even half as proud of and grateful for me as I am for her.

Happy China Anniversary, my love.

Originally published at meyerweb.com on July 19, 2018.

Well… yes and no. Specifically, yes if you’re using fixed-width fonts. Otherwise, mostly no.

This is because, despite what the letters ch might imply, ch units are not “character” units. They are defined as:

Equal to the used advance measure of the “0” (ZERO, U+0030) glyph found in the font used to render it. (The advance measure of a glyph is its advance width or height, whichever is in the inline axis of the element.)

So however wide the “0” character is in a given typeface, that’s the measure of one ch. In monospace (fixed-width) fonts, where all characters are the same width, 1ch equals one character. In proportional (variable-width) fonts, any given character could be wider or narrower than the “0” character.

To illustrate this, here are a few example elements which are set to be exactly 20ch wide, and also contain exactly 20 characters.

It’s probably no surprise that in Courier, all the elements are the exact same width as their text contents. In Helvetica, by contrast, this is mostly not the case except for numbers, which appear to be fixed-width. In Georgia, by contrast, none of the text contents fit the boxes, not even the numbers.

What I’ve found through random experimentation is that in proportional typefaces, 1ch is usually wider than the average character width, usually by around 20-30%. But there are at least a few typefaces where the zero symbol is skinny with respect to the other letterforms; in such a case, 1ch is narrower than the average character width. Trajan Pro is one example I found where the zero was a bit narrower than the average, but I’m sure there are others. Conversely, I’m sure there are typefaces with Big Fat Zeroes, in which case the difference between ch and the average character width could be around 50%.

So in general, if you want an 80-character column width and you’re going to use ch to size it, aim for about 60ch, unless you’re specifically working with a typeface that has a skinny zero. And if you’re working with multiple typefaces, say one for headlines and another for body copy, be careful about setting ch measures and thinking they’ll be equivalent between the two fonts. The odds are very, very high they won’t be.

It would be interesting to see the Working Group take up the idea of average character width as a unit of measure — say, 1acw or possibly just 1cw—which actually uses all the letterforms in a typeface to calculate an average value. That would get a lot closer to “make your columns 60 characters wide!” in a lot more cases than ch does now.

Originally published at meyerweb.com on June 28, 2018.

In another timeline, an early alarm woke Kat and me this morning so we could sneak into Rebecca’s room with her siblings and wish her a happy birthday at the moment she turned ten, 7:24am, June 7th, 2018.

Two digits. It’s a big milestone, in its way. Rebecca’s best friend Ruth passed it a few days ago. Ruth, who she called “Ruthie”. Who shared all three of her initials, and practically had the same birthday. Who was the last person to whom Rebecca ever spoke a complete sentence in her full voice, the morning of the day before she died: “Goodbye Ruthie, I love you, MWAH!”

Ruth, who still dreams of Rebecca, happy dreams that make her waking sad.

I have dreams like that too, when I remember them. I don’t often remember my dreams. But sometimes, I get to spend a little time with her, free of sorrow, on a nighttime walk or at an amusement park my subconscious devised out of all the parks we ever took her to.

Kat and Carolyn and Joshua and I went to the grave marker this morning, because Kat works all afternoon into the evening and Joshua has an all-day LEGO and chess camp and Carolyn has friends to see before summer vacation gets crazy. Because life moves on even when a part of you can’t understand why the sky doesn’t collapse and the world doesn’t crack open and time doesn’t shatter into a million sharded memories. Classes get taken, grades get graduated, camps get attended, trips get planned, work has to be done. Each day follows on the one before, pulling you further and further away from the last moments your life was normal.

We stood or sat or huddled around the flecked slate blue granite slab under the gray clouds of morning, emotions flaring and fading, subsumed by a profound sorrow without many tears. We’re too used to it, now. The sobs of previous years have given way to a steeled mourning. Sometimes there is resentment at the stupid blind unfairness of the holes shot through all our hearts, the hole in our lives, and all the things she and we never got to experience.

Her playgroup friends still talk of her with their parents. Rebecca was a good friend, she was funny, she was fun, she was so nice. In their way, still trying to come to grips with what happened to her. To them.

They don’t mention her to us. Children, trying to protect the grown-ups.

Which makes sense, since they know, now, that sometimes grown-ups can’t protect the children. Sometimes the killer gets into the house and there is nothing you can do to cast it out.

Sometimes there is nothing anyone can do, except hold the victim’s hand as her life ebbs away, and wish your desperate pleas to take her place had been heard. That there was something to hear, anything to hear, and accept a frantic parent’s bargain of life for life.

Ten years ago today, Rebecca came into this world. Four years ago today, she left it.

I can’t remember if I ever told her I would never forget her, or if I was too afraid of frightening her.

I clearly remember when and where she told me, sobbing, knowing that she would die, that she would never forget me.

I can still recall the terrified strength in her arms, locked around my neck.

I hope I told her then.

Today she should have been ten.

Originally published at meyerweb.com on June 7, 2018.

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.

Originally published at meyerweb.com on February 15, 2018.

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.

All my thanks to Rebecca Soffer and Gabrielle Birkner for making me a part of their incredible, inspiring work.

Originally published at meyerweb.com on January 25, 2018.

I’ll go into some details of what’s in it and what I think, and there will be some complaints. So I want to stress up front: this is an excellent book for people who want to learn web design, with the modifier if you’re available to help them out when they hit stumbling blocks. You aren’t going to have to hold their hands through the whole thing by any stretch, but there are moments where, for example, the filenames used in the text will mislead. (More on that anon.) For all that, it’s still an excellent book, and I recommend it.

The book is 94 pages, of which 88 pages are instructional, and none of it is filler — Mr. Hatter packs a surprising amount of good web design practice into those 88 pages. The pages themselves are filled with colorful design, and the text is easily readable. It’s aimed squarely at elementary-school readers, and it shows. That’s a good thing, I hasten to add. The tone is simple, uncomplicated, and stripped to the essentials. At no point does it condescend. It works well for any age, not just the suggested range of 7–17. I enjoyed reading it, even though I knew literally everything the book covers.

The organizing idea of the book is creating a small web site for a ninja band (!!!) called The Nanonauts. In the course of the book, the reader sets up a home page, an About Us page, a page listing upcoming concerts, and a couple more. Everything makes sense and interrelates, even if a couple of things feel ever so slightly forced.

Here’s a page-number timeline of concepts’ first introductions:

p. 6 Brainstorming site content and sketching a site map. Bear in mind here that the actual instructional text starts on page 6.

p. 10 Adding a style sheet to an HTML document via a link element.

p. 14 A nice breakdown of how images are loaded into the page, what the various (common) image attributes are and mean, and the importance of good alt text. On page 14.

p. 17 The concept of an empty element and how it differs from other elements.

pp. 20-24 An extended discussion of proper structure and good content for the web. It shows how using headings and paragraphs breaks up large text walls, makes the distinction between ordered and unordered lists, and demonstrates the importance of proper element nesting.

p. 25 Diving into CSS. A style sheet was added to the document back on page 10, but this is where CSS starts to be discussed in detail.

p. 28 Radial gradients! They went there! The syntax isn’t dissected and explained, but just showing working gradients clues readers in to their existence. There’s also an example of styling html separately from body, without making a super big deal out of it. This is a pattern throughout the rest of the book: many things are used without massively explaining them. The author relies on the reader to repeat the example and see what happens.

pp. 30-32 A really great explanation of hexadecimal color values. I’ve never seen better, to be honest. That’s followed by a similarly great breakdown of the uses for, and differences between, px, em, and % values for sizing.

p. 36 The first of several really lovely step-by-step explanations of style blocks. In this case, it’s styling a nav element with an unordered list of links, explaining the effects of each rule as it’s added.

pp. 50-52 An example of properly structuring and styling tabular data (in this case, a list of upcoming concerts).

p. 59 The box model and inline elements explained in sparing but useful detail. This includes a brief look at inline elements and the baseline, and vertical alignment thereof.

p. 74 Responsive web design! A nice introduction to media queries, and a quick primer on what responsive means and why it’s important.

p.78 Floating images to wrap text around them. That segues into layout, using floats for the boxes enclosing the bits of content.

p. 88 Using web fonts (basically Google fonts).

p. 90 Putting your site online.

That isn’t everything that’s touched on in the book by a long shot — max-width and min-width show up early, as do :last-child, border-radius, and several more CSS features. As I said above, these are generally introduced without much detailed explanation. It’s a bold approach, but one that I think pays off handsomely. Trusting the reader to become interested enough to track down the details on their own leaves room to include more things to spark interest.

That said, there are some aspects that may — probably will — cause confusion. The biggest of these has to do with images. There are several instances of using img to add images to pages, as you’d expect. The author does provide a downloadable archive of assets, which is a little difficult to actually find (here’s a direct link), but the real problem is that once you extract the files, the filenames don’t match the filenames in print. For example, in the book there’s a reference to nanonauts.jpg. The corresponding file in the archive is NINJA_FACE_FORWARD.png. At another point, DSC03730.png turns out to actually be NINJA_GUITAR.png. There’s no indication of this whatsoever in the book.

I get it: mistakes happen, and sometimes digital assets get out of step with print. Nevertheless, I fear this could prove a major stumbling block for some readers. They see one filename in the book, and that filename doesn’t exist in the assets. Maybe they open up the asset images until they find the right one, and then maybe they figure out to replace the filename in the book with the one they found, and move on from there… but maybe they don’t. I’d be a lot happier if there were an errata note and mapping table on the download page, or the online archive’s assets were corrected.

Something similar happens on page 19, where the reader is directed to create a navigation link to songs.html when the page they’ve already created is called our-songs.html. This one is a lot more forgivable, since the filenames are at least close to each other. But again, it’s a place the reader might get lost and frustrated. The painful irony is that this error appears in a “NINJA TIP” box that starts out, “Be careful when you’re typing links. You have to get them exactly right!”

Another error of this kind happens in the section on adding a video to a page (p.45). All the markup is there, and the URL they supply in great big text loads a video just fine. The problem is that the video it loads is an ad for Scholastic, not the ninja-playing-a-guitar video the text very heavily implies it will be. I don’t know if it used to be a rock ninja shredding power chords and Scholastic replaced it or what, but it almost feels like a bait and switch. It was a little disheartening.

There’s one aspect I can’t quite make up my mind about, which is that just about everything in the book — text, design elements, media query breakpoints — is done using pixels. A couple of percentage widths show up near the very end, but not much is said about them. There is a very nice comparison of pixels, ems, and percentages on page 32, but with ems never being used (despite a claim to the contrary), readers are unlikely to use or understand them.

Now, I don’t style this way, and my every instinct rebels against it. But given that pixels really don’t mean what they used to, and that all modern browsers will scale pages up and down pretty seamlessly, is this a major problem? I’m not sure that it is. Either way, this does set readers on a specific initial path, and if that path bothers you, it’s worth knowing about so you can give them extra advice.

The third thing I found weird was the two pages devoted to embedding a live Google Map into one of the pages (showing the location of the Nanonauts’ next show). On the one hand, it’s cool in that it shows how some HTML elements (i.e., iframe) can serve as containers for external assets more complicated than images and videos, and having a live map show up in the page you’re building is probably pretty mind-blowing for someone just starting out. On the other, it’s kind of a fiddly and unusual use case: not many novice sites need an embedded widget calling an API.

I had less of a problem with the author showing a simple image-swapping-on-hover JavaScript solution, later in the book (even though my hindbrain kept chanting, “do that with CSS!”). It’s a simple example of scripting pieces of the page, and lets Mr. Hatter talk about the DOM and DOM scripting without getting super crazy about it.

The last thing I found a bit lacking was the closing two pages, which cover putting the site online. The author does their best with the two pages, and what’s there is correct, but it’s just not enough to help everyone get the results of their work online. I’m not sure two pages ever could be enough to help the novice audience. I’d have liked to see this get four pages, so there was room for more detail and more options. If you’re giving this book to someone to help them learn, my advice is to tell them up front that you’ll help them get their work online once they’ve finished the book.

Okay, all that said? I still absolutely recommend this as a beginners’ book. Nearly every topic the text introduces, and there are many I didn’t mention here, is covered just the right amount and in just the right way to get readers where they need to be, excited about what they’ve accomplished, and ready to learn more on their own. It’s pretty well up to date, at least as I write this, and isn’t likely to fall badly out of date any time soon. Approachable, accessible, and instructive.

Final grade: I give it a solid B+, only falling short of A level due to the filename mismatches.

Note: All images in this review are copyright The CoderDojo Foundation. Some were taken from the book’s asset files.

Originally published at meyerweb.com on December 3, 2017.

I thought about taking screenshots and Photoshopping wireframe boxes over the various layout pieces, but then I wondered: could I overlay boxes on the live page with CSS? Or perhaps even create and overlay them with nothing but some declarations and a wanton disregard for the sensibilities of god or man?

And that’s when I realized…I could.

Now I’m going to share my discovery with you…

…over at meyerweb.com. I’d reproduce it here, but Medium’s import feature mangled every single code block I had by stripping out the linefeed characters. And there are quite a few code blocks with quite a few linefeeds each. So kindly check out the original, and I hope you enjoy!

Original article published at meyerweb.com on November 27, 2017.