That’s not at all minor point.  I don’t believe it overstates the case to say that if CERN hadn’t made the web free and open to all, it wouldn’t have taken over the net.  Like previous attempts at hypertext and similar information systems, it would have languished in a niche and eventually withered away.  There were other things that had to happen for the web to really take off, but none of them would have mattered without this one simple, foundational decision.

I would go even further and argue that this act infused the web, defining the culture that was built on top of it.  Because the medium was free and open, as was often the case in academic and hacker circles before it, the aesthetic of sharing freely became central to the web community.  The dynamic of using ideas and resources freely shared by others, and then freely sharing your own resources and ideas in return, was strongly encouraged by the open nature of the web.  It was an implicit encouragement, but no less strong for that.  As always, the environment shapes those who live within it.

It was in that very spirit that Dave Shea launched the CSS Zen Garden ten years ago this week.  After letting it lie fallow for the last few years, Dave has re-opened the site to submissions that make use of all the modern capabilities we have now.

It might be hard to understand this now, but the Zen Garden is one of the defining moments in the history of web design, and is truly critical to understanding the state of CSS before and after it debuted.  When histories of web design are written—and there will be—there will be a chapters titled things like “Wired, ESPN, and the Zen Garden: Why CSS Ended Up In Everything”.

Before the Zen Garden, CSS was a thing you used to color text and set fonts, and maybe for a simple design, not for “serious” layout.  CSS design is boxy and boring, and impossible to use for anything interesting, went the conventional wisdom.  (The Wired and ESPN designs were held to be special cases.)  Then Dave opened the gates on the Zen Garden, with its five utterly different designs based on the very same document…and the world turned.

I’m known to be a history buff, and these days a web history buff, so of course I’m super-excited to see both these sites online and actively looked after, but you should be too.  You can see where it all started, and where a major shift in design occurred, right from the comfort of your cutting-edge nightly build of the latest and greatest browsers known to man.  That’s a rare privilege, and a testimony to what CERN set free, two decades back.

@supports (text-decoration: blink) {
	#test {
		color: green;
		background: yellow;
		text-decoration: blink;
	}
}

Results in all @supports-supporting browsers I was able to test: green text on a yellow background, except Firefox 22, which additionally blinks the text.  The latest nightly builds of Firefox 23 do not blink the text, thanks to bug 857820.

Discuss.

One of the things I teach tech writers: it’s okay to have fun with your audience most of the time. But never joke with frustrated people. If you’re delivering bad news, an alert, or helping a new user troubleshoot a problem, be straightforward and transparent.

As I’m sure Amber would be the first to say, said rule is not just for tech writers.  In any online interaction, synchronous or asynchronous, with someone you don’t know really, really well, that rule applies.  Always.  And the defense “Hey, man, where’s your sense of humor?” is usually the reddest of flags that you have already screwed this up, and should consider apologizing.

(I’m especially looking at you, Twitterers.)

I mean, what do you think @supports means?  Take a moment to formulate a one-line definition of your understanding of what it does, before moving on to the rest of this piece.

If you’ve never heard of it before and wonder how it works, here’s a very basic example:

body {background-color: white;}
@supports (background-color: cornflowerblue) {
	body {background-color: cornflowerblue;}
}

The idea is that if the browser supports that property:value combination, then it will apply the rule or rules found inside the curly brackets.  In this sense, it’s just like @media rules: if the conditions in the parentheses are deemed to apply, then the rules inside the declaration block are used.  The module refers to this ability as “feature queries”.

There are some logical combination keywords available: and, or, and not.  So you can say things like:

body {color: #222; background-color: white;}
@supports ((background-color: cornflowerblue) and (color: rgba(0,0,0,0.5))) {
	body {background-color: cornflowerblue; color: rgba(0,0,0,0.5);}
}

Okay, but what does that actually mean?  Here’s what the specification says:

A CSS processor is considered to support a declaration (consisting of a property and value) if it accepts that declaration (rather than discarding it as a parse error). If a processor does not implement, with a usable level of support, the value given, then it must not accept the declaration or claim support for it.

So in that first sentence, what we’re told is that “support” means “accepts [a] declaration” and doesn’t drop it on the floor as something it doesn’t recognize.  In other words, if a browser parses a property:value pair, then that qualifies as “support” for said pair.  Note that this sentence says nothing about what happens after parsing.  According to this, a browser could have a completely botched, partial, and generally unusable implementation of the property:value pair, but the act of recognizing means that there’s “support”.

But wait!  That second sentence adds an additional constraint, after a fashion: there must be “a usable level of support”, the lack of which means that a browser “must not…claim support”.  So not only must a browser parse a property:value pair, but support it to “a usable level”.

But what constitutes a “usable level”?  According to everyone who’s told me that I was wrong about vendor prefixes, any browser implementation of a feature should be complete and error-free.  Is that what’s required to be regarded as a usable level?  How about if the implementation has one known bug?  Three?  Ten?  Can any of them be severe bugs?  What about merely serious bugs?  What if two browsers claim usable support, and yet are not interoperable?

So.  How does the definition of @supports match the one-line definition I asked you to formulate, back at the beginning?  Are they exactly the same, or is there a difference?

I suspect that most people, especially those coming across @supports for the first time, will assume that the word means that a browser has complete, error-free support.  That’s the implicit promise.  Very few people think of “supports” as a synonym for “recognizes” (let alone “parses”).  There’s a difference, sometimes a very large one, between recognizing a thing and supporting it.  I’m sure that browser teams will do their best to avoid situations where a property:value pair is parsed but not well supported, but it’s only a matter of time before a “supported” pair proves to be badly flawed, or retroactively made wrong by specification changes.  Assuming that such things will be allowed, in an environment where @supports exists.

If feature queries were set with @feature, as media queries are set using @media, or even if the name were something along the lines of @parses or @recognizes, I’d be a lot less bothered.  The implicit promise would be quite a bit different.  What I feel like we face here is the exact inversion of vendor prefixes: instead of a marker for possible instability and a warning that preserves the possibility of changing the specification when needed, this pretends to promise stability and safety while restricting the WG’s ability to make changes, however necessary.  My instinct is that @supports will end up in the same place: abused, broken, and eventually reviled—except this time, there will be the extra bitterness of authors feeling that they were betrayed.

So how did they do it?  With CSS.  Here it is:

.tweet-display-linebreaks .tweet .js-tweet-text{
	white-space:pre-wrap
}

That’s it.  I’m not going to comment on their selector construction, except in the meta sense that I just did, but that single rule is all it took.

Well, not quite all.  The other thing they’ve done is to trim off any leading or trailing whitespace, and make sure the tweet’s content is right up against the opening and closing tags of the element.  It looks like so:

<p class="js-tweet-text">Y’all ready for this?</p>

When I input that tweet, it was like this, extra linefeeds and all:

Y’all ready for this?

So why do they trim off the edges?  Because if they left any whitespace between the tags and the content, pre-wrap would honor it.  This would happen even if Twitter, and not the author, was the source of the linefeeds between tags and content.  So rather than just ensure the content was placed normally, without any extra space, they went the trim($tweet) route.  I’m sure there are ways to beat the trimming; I haven’t tried to find them.  And there may be perfectly good reasons why they went the trim() route.  Maybe someone from Twitter will drop by to fill us in.

I will also note that white-space: pre-wrap preserves spaces between characters, just like pre elements do.  That means that anyone who double-spaces after sentences will have that space show up in their tweets, for everyone else to see.  Just like with the line breaks, author intent is thus preserved.  Deal with it.

To see what I mean, you can load up my testcase in any Windows browser—IE, Firefox, Chrome, whatever—assuming that you haven’t installed Helvetica on your Windows machine.  (If you have, then I’d love to know what results you get.)  Given that you haven’t installed Helvetica, you should see that three of the four bottom-bordered spans are using Arial.  This can be determined due to the shapes of the “GR” characters—they are notably different between Helvetica and Arial.  Here’s what I apply to the first test list item:

#l01 .s01 {font-family: Helvetica, monospace;}
#l01 .s02 {font-family: Arial, monospace;}

My result is that they use exactly the same face, and that face is Arial, which should not have happened.  If Helvetica is not present, the first span should be rendered using a monospace font face.  If it is present, then the first span should have different letterforms than the second.

But it’s the second line where things get really interesting.  There, I assigned local copies of Helvetica and Arial (if they exist) to the invented family names “H” and “A”.  Then I apply this to the second test list item:

#l02 .s01 {font-family: H, monospace;}
#l02 .s02 {font-family: A, monospace;}

The result should be the same as the first line, but it isn’t: the first span gets a fallback font face, and the second span gets Arial.  So while the system redirects requests for Helvetica to Arial, it doesn’t do so in such a way that the invented family name “H” resolves to Arial, even though it was assigned Helvetica (or perhaps I should say “Helvetica”) as its source.

I’d be interested to know if there’s something I’ve overlooked or misunderstood here, because these waters are deep and I suspect my understanding of them is somewhat shallow.

I gave him the requested high-five, of course, and then another for being proactive.  It was the first time he’d ever asked for one.  He could not have looked more pleased with himself.

And I suddenly realized that I wanted to be able to say to my glasses, “Okay, dump the last 30 seconds of livestream to permanent storage.”

There have been concerns raised about the impending crowdsourced panopticon that Google Glass represents.  I share those concerns, though I also wonder if the pairing of constant individual surveillance with cloud-based storage mediated through wearable CPUs will prove out an old if slightly recapitalized adage: that an ARMed society is a polite society.  Will it?  We’ll see—pun unintentional but unavoidable, very much like the future itself.

And yet.  You think that you’ll remember all those precious milestones, that there is no way on Earth you could ever forget your child’s first word, or the first time they took their first steps, or the time they suddenly put on an impromptu comedy show that had you on the floor laughing.  But you do forget.  Time piles up and you forget most of everything that ever happened to you.  A few shining moments stay preserved, and the rest fade into the indistinct fog of your former existence.

I’m not going to hold up my iPhone or Android or any other piece of hardware all the time, hoping that I’ll manage to catch a few moments to save.  That solution doesn’t scale at all, but I still want to save those moments.  If my glasses (or some other device) were always capturing a video buffer that could be dumped to permanent storage at any time, I could capture all of those truly important things.  I could go back and see that word, that step, that comedy show.  I would do that.  I wanted to do it, sitting on the floor of my child’s room this morning.

That was when I realized that Glass is inevitable.  We’re going to observe each other because we want to preserve our own lives—not every last second, but the parts that really matter to us.  There will be a whole host of side effects, some of which we can predict but most of which will surprise us.  I just don’t believe that we can avoid it.  Even if Google fails with Glass, someone else will succeed with a very similar project, and sooner than we expect.  I’ve started thinking about how to cope with that outcome.  Have you?

On Friday, the Web Standards Project announced its own dissolution.  I felt a lot of things upon reading the announcement, once I got over my initial surprise: nostalgia, wistfulness, closure.  And over it all, a deep sense of respect for the Project as a whole, from its inception to its peak to its final act.

In some ways, the announcement was a simple formalization of a longstanding state of affairs, as the Project has gradually grown quieter and quieter over the years, and its initiatives had been passed on to other, more active homes.  It was still impressive to see the group explicitly shut down.  I can’t think of the last time I saw a group that had been so influential and effective recognize that it was time to turn off the lights, and exit with dignity.  As they wrote:

Thanks to the hard work of countless WaSP members and supporters (like you), Tim Berners-Lee’s vision of the web as an open, accessible, and universal community is largely the reality. While there is still work to be done, the sting of the WaSP is no longer necessary. And so it is time for us to close down The Web Standards Project.

I have a long history with the WaSP.  Way, way back, deep in the thick of the browser wars, I was invited to be a member of the CSS Action Committee, better known as the CSS Samurai.  We spent the next couple of years documenting how things worked (or, more often, didn’t) in CSS implementations, and—and this was the clever bit, if you ask me—writing up specific plans of action for browsers.  The standards compliance reviews we published told browsers what they needed to fix first, not just what they were getting wrong.  I can’t claim that our every word was agreed with, let alone acted upon, but I’m pretty confident those reviews helped push browser teams in the right direction.  Or, more likely, helped browser teams push their bosses in the direction the teams already wanted to go.

Succumbing to a wave of nostalgia, I spent a few minutes trawling my archives.  I still have what I think is all the mail from the Samurai’s mailing list, run through Project Cool’s servers, from when it was set up in August 1998 up through June of 2000.  My archive totals 1,716 messages from the group, as well as some of the Steering Committee members (mostly Glenn Davis, though George Olsen was our primary contact during the Microsoft style sheets patent brouhaha of February 1999).  If I’m not reading too much into plain text messages over a decade old, we had a pretty great time.  And then, after a while, we were done.  Unlike the WaSP itself, we never really declared an end.  We didn’t even march off into the sunset having declared that the farmers always win.  We just faded away.

Not that that’s entirely a bad thing.  At a certain point, our work was done, and we moved on.  Still, I look back now and wish we’d made it a little more formal.  Had we done so, we might have said something like the WaSP did:

The job’s not over, but instead of being the work of a small activist group, it’s a job for tens of thousands of developers who care about ensuring that the web remains a free, open, interoperable, and accessible competitor to native apps and closed eco-systems. It’s your job now…

And so it is.  These last years have shown that the job is in very good hands.

“Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has.” said Margaret Mead.  I see now that the way those small groups truly change the world is by convincing the rest of the world that they are right, thus co-opting the world to their cause.  Done properly, the change makes the group obsolete.  It’s a lesson worth remembering, as we look at the world today.

I’m honored to have been a part of the WaSP, and I offer my deepest samurai bow of respect to its founders, its members, and its leaders.  Thank you all for making the web today what it is.

Well, so it was.  But there was another stage to the analogy that I didn’t bring up because it seemed to so remote, back then: that one of the browsers would start to gobble up or kill off its competitors, as MS Word did in the word processor space.  Sure, there are still alternatives, but how many people use them?

You can argue that this sort of consolidation is inevitable.  You can argue that it has benefits that outweigh the drawbacks, and vice versa.  Certainly having a de facto word processor made publishers’ lives easier in many ways, even if it disrupted life for authors who had invested in other-than-de-facto programs.  It made life easier for people who wanted to extend the word processing space by writing extensions, helpers, and other tools.  And it definitely made life easier for the Office team, which could proceed to add whatever feature they liked without having to worry overmuch about interoperability with others.  (It was, obviously, up to others to be interoperable with them.)

This is the lens through which I view Opera’s announcement that they will migrate to WebKit.  Actually, that’s not true: it’s one of the lenses.  I also remember the first browser wars, and the calls to have all browsers just use Trident, the engine in IE5 and IE6.  It was dominant, after all, and as good as or better than all its competitors, blessed with great resources and smart developers.  I find myself peering through that lens as well.

There are parallels and divergences, of course:  no analogy is ever perfect and no two events are identical.  We could argue about how this is exactly like or not like a decade ago, how this is precisely like or not like the word processor market, and some of us will.  No matter where you fall, of course, the Opera migration to WebKit and the sunset of Presto is going to happen.  As once was said:  The avalanche has already started.  It is too late for the pebbles to vote.

To which I would add: in this case the pebbles have already voted, have been voting for years now, and their votes determined that the avalanche would proceed in this direction and not another.  And no, I don’t mean the users.

The first is that Jen and I have done two more “The Web Behind” episodes since the last time I mentioned it, and they were both really fun.  Back on November 28th, I interviewed Tom Bruce of the Cornell Legal Information Institute about the very earliest days of the web, parallels between the arguments then and the arguments now, writing the first Windows web browser more or less from scratch, his invention of marquee, and the time he took a road trip to NCSA with Tim Berners-Lee to help bring cgi-bin to the web.

Then on December 20th, I got Tantek Çelik on the line to discuss how the web is like OpenDoc, why the web didn’t impress him the first time he saw it, the creation and interesting features of Internet Explorer 5 for Mac, how interviewing developers working in the field helped shape IE/Mac and thus the browsers that followed it, and how DOCTYPE switching came to be (and who thought it up).

On the other side of the microphone, I was honored to be the guest for the first episode of Besquare’s “12 Days of Podcasts”, which started on Boxing Day and continues on through the Feast of the Ephiphany.  We talked for just over half an hour about CSS past and future, conferences, how I got started on the web, and ways to land a job in the web industry.  As I publish this, they’re just three episodes into the series, so it’s not too late to jump in.

Happy listening, and a joyous New Year to you and yours!

You may want to exclude hyphenation on <code> tags within your blog. For both readability purposes (since many CSS tags already make heavy use of hyphens) and to avoid introducing some confusing/misleading references… Is it re-peating-linear-gradient? Or perhaps repeating-lin-ear-gradient?

He’s absolutely right, of course.  If you’re going to blog about technical topics, or even if you’re just writing a style sheet that you expect to release into the wild for use by anyone, there are some elements that you should avoid hyphenating.  And since hyphens is an inherited property, it isn’t sufficient to set it for a limited number of elements and assume you’re done.  You have to make sure you’ve turned it off for the elements that shouldn’t be hyphenated.

In my opinion, those elements are:

• code
• var
• kbd
• samp
• tt
• dir
• listing
• plaintext
• xmp
• abbr
• acronym

Yes, most of those are old and obscure and in some cases (massively) deprecated, but they’re all elements that could be hanging around on a web site and by their nature shouldn’t have their content hyphenated.  I mean, I would hope that a browser would recognize not to hyphenate an acronym or abbreviation element, but who knows?  Maybe ZOMGWTFBBQROFLMFAOCOPTER has enough word-like strings to qualify for hyphenation in some hyphenation dictionaries.  (Or not.)

“So what about pre?” you ask.  A very good question.  I rate that as a solid “maybe”.  For most uses of pre, the content won’t line-wrap anyway thanks to white-space: pre, so it’s a moot point.  However, if a pre has been set to white-space of pre-wrap, pre-line, or even normal, then hyphenation may well kick in.

At that point, the question is what kind of content the pre contains.  It apparently is no longer meant to be rigidly preformatted, as the element name would imply, so what is it?  If it’s a code block, there should already be a code element present within the pre, so suppressing hyphenation for code will be sufficient.  Ditto if it’s an example of user input (kbd), program output (samp), and so on.  This is why semantic markup matters.  It’s why, if you’ve been using it all along, you can make fine-grained choices here.

Of course, lots of people weren’t as forward-looking as you and anyway nobody’s perfect, so it’s probably a good idea to switch off hyphenation for pre, just in case the more semantic elements were left out.

There are similar questions to confront regarding q and blockquote.  If you’re quoting someone, almost certainly something that someone wrote, is it advisable to hyphenate that text when they didn’t?  I’m honestly not sure if it matters or not.  I’ve personally suppressed hyphenation in those cases, but I did that purely on instinct and I’d love to know what content and typography specialists think of that question.  (Be polite, please.  We’re all learning here.)

For the last interesting question, what about auto-linked URLs?  If we suppress hyphenation for all links, then that solves one problem to introduce another.  What I have noticed is that if you drag-select CSS-hyphenated text, the auto-generated hyphen(s) and line break(s) are ignored when you copy the text.  You just get the original.  That’s why I don’t think it’s really necessary to suppress hyphenation on the a element, though I’m willing to change my mind in the presence of new evidence.

Thus, at the moment, meyerweb’s base style sheet contains the following:

body {hyphens: auto;}
code, var, kbd, samp, tt, dir, listing, plaintext, xmp,
      abbr, acronym, blockquote, q {hyphens: none;}

I may adjust those rules over time, but that’s where I’ve landed.

Update 18 Dec 12: I should make it more clear that this post is intended to be a starting point, not the final word.  I’m not proposing that these are all the elements on which one should ever suppress hyphenation, full stop, end of discussion.  There may well be others, like form labels and textareas and text inputs and so forth, that should also be excluded.  (Though I kind of enjoy watching my text input get auto-hyphenated as I type.  It’s a little surreal.)  Hopefully, this post will get people thinking about exactly how authors should handle hyphenation if they do choose to put it in place, and eventually help us figure out some solid best practices.

A couple of weeks back, PPK posted about the sudden emergence of CSS hyphenation support in several browsers (which got picked up by WebMonkey, the lucky dog).  At the time, there was some confusion about whether a lang attribute it required to allow the hyphenation to happen—PPK said it did, but my testing indicated the opposite.

Well, it turned out that at the moment I did that test, I was running Firefox 16, and FF16 apparently honored the -moz-hyphens property with nary lang a attribute in sight.  We might ask how that’s supposed to work, since hyphenation dictionaries are language-dependent, but never mind: it did.  Firefox 17, on the other hand, requires a lang attribute value in order to apply hyphens (note the lack of prefix).

I haven’t gone running down the behavior of other browsers, because the upshot is this: if you want hyphenation to work in a future-friendly way, you need a lang attribute.  What older versions do will become of fading relevance.

All of which raises a fairly important question: should you enable hyphenation?

After all, hyphenation, I am told, was invented to increase the density of text and reduce the number of column inches needed in printed media, where paper can be expensive and space at a premium.  Hyphenation, in other words, was devised as a trick to let authors be a little bit more wordy.  (Also as a way to help reduce interword spacing in fully justified text.)

On the web, of course, we have no physical length constraints: The Web Ain’t Print.  We can run on as long as we like, limited only by our thesaurus, our RSI flare-ups, and the attention span of our readers.

But wait…that’s all true for the desktop web.  We have lovely big monitors and easily resizeable windows and zoomable text.  On mobile devices, however, the real estate is much more limited.  We still have infinite length, yes, but line lengths tend to be a lot shorter on iPhone or Android—particularly if you’ve given your mobile users a nicely readble font size.

Right after PPK’s article hit my aggregator, I turned on hyphenation here on meyerweb.  For desktop reading, at first it caught my eye a bit, but now I don’t see it at all.  Years and years of print reading has made it seem familiar.  Things would be just fine without the hyphens, of course.  But when reading pages on mobile, the hyphens feel useful.  They give me a little bit more reading for each “screenful”, and just feel comfortable.

Thus my recommendation of the moment: if you’re going to use CSS hyphenation, turn it on for mobile contexts.  For desktop—well, that’s a much murkier call.  It may well depend on your font family, layout, default language, and so on.  If you do turn them on, just make sure you have that lang attribute (I put mine on the html element) so your hyphens will persist.

There are a lot of things that go through your head at that moment.  You think that maybe you should be offended, but then remember all the times you asked potential hires why you should give them the position.  You think about everything you’ve done and been through just to get to this point, the paperwork and training and classes and inspections and certifications, wondering how all that time and energy and expense could go unnoticed even as you realize it wasn’t.  It wasn’t overlooked.  She knows about all that; this is something else.  This is a character-divination exercise, just the latest in a very long series of hurdles, this one smaller than most, but a hurdle that has to be cleared all the same.

Because the basically cheerful, kindly woman sitting across the coffeeshop table from you holds your future in her hands.  She can decide that you are not fit to be a parent.  That power is hers.

You’ve gotten to know her over the previous months, through all the meetings and home inspections, and don’t think for an instant that she would turn you down capriciously or out of anything but a deep, genuine concern.  She’s not out to get you, or stop you, or hurt you.  She wants to help.  It’s up to you to not screw it up.

Which is why you pause for a moment to consider your answer, not because you haven’t thought about this exact question and your answer to it a thousand times before, but because you don’t want to screw this up.

This is what it’s like to adopt.

In that moment of pause, a lot of impressions flood in.  You don’t think about things, don’t remember events like a movie, but you feel all of their impressions on your life.

You recall deciding to stop using birth control, and the year of trying to get pregnant, using what is in effect the inverse rhythm method, and fittingly enough you got the opposite of the usual result.  You recall the fertility consultations, the blood draws and testing and the sample bottle that you need to fill no matter how sterile and cold and impersonal the little room might be, because as soon as you do then the doctor can take your issue and put it into a contraption that will be inserted right up into your wife so the sperm are deposited exactly where they have the best chance of meeting up with an egg and doing their thing.  With you holding her hand the whole time.  You recall the elective surgeries to correct discovered conditions that turn out, in the end, to have no positive effect.  You recall every one of the times the lab called to congratulate you on successful conception, and every one of the times the lab called a few days later to tell you that the pregnancy had failed, and how you learned that there are far, far more conceptions than there are pregnancies, even among those who aren’t undergoing fertility treatment.  You recall finding out that your only hope of pregnancy was IVF, and even that was a long shot, not to mention medically inadvisable when you looked at it dispassionately, as if such a thing were possible.

You recall deciding together that being pregnant was not nearly as important to you as being parents.

This is what it’s like to adopt.

You recall the Fire Marshall telling you that your house’s wiring needed to be upgraded and you needed to post floor-by-floor fire evacuation maps—in your compact, center-hall Colonial, only-one-staircase house—before he could sign off on your form, the form you needed to be signed so you could proceed.  You recall pressing your fingers into the fingerprint scanner so that the FBI could look into your background and declare your lack of criminality, so far as they knew, so you could proceed.

You recall sitting in the infant/child CPR class, looking at the other couples, some of them obviously well along in their pregnancies and others with no signs at all, you the only single person because your wife’s professional training already covers this stuff, wondering if any of them are hoping to adopt but not sure how to bring it up without looking like you’re trying to be a show-off or something.

You recall handing over more financial data than was required the last time you bought a house, which was the only time you bought a house, because you skipped the whole “starter home” thing and saved until you could buy the right house, the one with the huge front porch for summer dinner parties and the fireplace for winter evening cuddles and the bedrooms all about the same size so your someday children wouldn’t get into fights over who got stuck with the tiny room.  You also recall knowing that one day they would fight about it anyway, because someone would bust out a tape measure and complain that they’d been shorted by eight square feet, and you couldn’t wait for that day.

You recall the agony of filling out your medical/social profile, twenty draining pages of research and prejudgment and soul-searching, asking yourself what you thought you could or could not accept in a newborn baby and its parents and their parents and relatives and asking yourself who you were to judge another life, and then remembering that if you hoped to be parents you’d better be ready to judge all the time, not angrily, but fairly and compassionately and (if at all possible) wisely.  But you still had to finish this form, even though it felt like passing judgment on all the possibilities yet to be, because it had to be finished before you could proceed.

You recall wishing you could be angry about all the barriers and hurdles and hoops, all these things standing in the way of two people who wanted so much to raise a family, but understanding and accepting the reasons for all of them.  You analyze conceptual systems by trade, pull apart ideas and specifications to see how the pieces work, spend lots of time figuring out the why as well as the how, and that’s how you can see all too clearly why all these trials exist.  It is a grave responsibility to be a parent, and a graver responsibility for a third party to approve the transfer of a tiny, helpless, utterly dependent baby into a household of strangers.  If the state and its designated agents are to be party to that transfer, then they are responsible for doing all that they can to ensure that the transfer is made to good, decent people who can provide all the kinds of nourishment a new life needs.

And so all the things you ever thought potential parents should be tested on before they’re allowed to reproduce, as you shake your head at some obvious example of terrible, terrible parenting, forgetting for a moment that everyone has bad days and that you don’t know the first thing about those people and their lives and histories, all those things you’ve thought should be part of the Are You Fit To Be A Parent Test are all placed in front of you now, and twice as much more that had never occurred to you, all standing between you and the someday family you decided to create.

You recall them all, all the weight of all those challenges, and you look her in the eye and draw in your breath to answer.

This is what it’s like to adopt.

After the interview is over, you chat for a bit and then go your separate ways.  Soon you will finish up the last pieces of paperwork, send in your finished profile, and wait.

And wait.

And wait.

And wait.

And then one day, out of the blue, the phone rings and a frenzied chain of events are instantly set into motion, tying up loose ends and postponing appointments and deciding who to tell and making sure you have absolutely everything you need, because eighty hours after that phone call you are nestling a tiny, trusting, utterly exquisite baby to your chest and listening to it breathe, feeling its weight and warmth against you, your head still spinning from the uproar of the past few days and at the same time suddenly spinning the other direction because it hits you, with all the force of a newborn’s scent and all the piercing of a newborn’s cry, that you are holding your future in your hands.

This is what it’s like to adopt.

To be a parent.

If you’re interested in joining us in 2013, you can check out the event nearest you…or maybe the event being held where you’ve always wanted to go!  If you have your eye on Atlanta, bear in mind that the Early Bird rate (which saves you $100) ends on Christmas Eve, so don’t wait too much longer.  And if you were waiting for a detailed schedule in either San Diego or Boston before deciding to register, well, your wait is over.  More schedules will be released as the shows get closer.

I don’t talk very much about An Event Apart, and I probably talk about it far less than I should.  I blame that on the show itself, partly.  Our last show of 2012, held at the opulent Palace Hotel in San Francisco, is now three weeks behind us and I’m still struck a little bit speechless by another year of fantastic attendees and speakers.  The fundamental nature of what we’ve created together really is overwhelming to me, in the best possible way.  Thank you, one and all, for making that possible.

To celebrate the year just past as well as the year to come, we’ve once again made a donation to CFY (formerly Computers For Youth) to help advance their efforts to bring digital literacy and access to impoverished elementary school students.  They’ve already seen great improvements in schools where they operate, and we’re thrilled to support their work.  If you’d like to support them as well, please do, or take a moment in all the end-of-year rush and lend some aid to the charity that speaks most clearly to you.

Web design isn’t like chemistry, where the precipitate either forms or it doesn’t. If chemical engineers had to work in conditions equivalent to web developers, they’d have to mix their solutions in several parallel universes, each one with different physical constants, and get the same result in all of them.

While that’s still true, the constants are a lot less divergent these days.  The parallel universes that are web browsers are much closer to unity than once they were.

Remember those days?  When major web sites had a home page with two links: one for Netscape users to enter, the other for IE users?

Madness.

We know better now, of course.  Thanks to early pioneers like the organizers of the Web Standards Project, the path of web development was bent to a much saner course.  We still have little glitches and frustrations, of course, but it could be so unimaginably worse.  We know that it could be, because it was, once.

Along the way, the book cover of my friend and business partner’s book, Designing With Web Standards, gave rise to Blue Beanie Day, the day on which we give visible presence to our solidarity with the idea that web standards make possible the web as we know it.  Pictures go up on Twitter, Instagram, and Flickr with the tag #bbd12, and can be added to the Flickr group if you post there.

In this rapidly unfolding age of multiple device platforms and web access experiences, standards are more important than ever, even as they come under renewed pressure.  There will always be those who proclaim that standards are a failed process, an obstruction, an anachronism.  The desire to go faster and be shinier will always tempt developers to run down proprietary box canyons.

But so too will there always be those of us who remember the madness that lies that way.  Come November 30th, thousands of us will don our blue beanies.  I hope you’ll be among us.

Image © Kevin Cornell.  Used with permission.