The other was the publication of the minutes of the CSS Working Group meeting in Paris, where it was revealed that several vendors are about to support the -webkit- vendor prefix in their own very non-WebKit browsers. Thus, to pick but a single random example, Firefox would throw a drop shadow on a heading whose entire author CSS is h1 {-webkit-box-shadow: 2px 5px 3px gray;}.

As an author, it sounds good as long as you haven’t really thought about it very hard, or if perhaps you have a very weak sense of the history of web standards and browser development. It fits right in with the recurring question, “Why are we screwing around with prefixes when vendors should just implement properties completely correctly, or not at all?” Those idealized end-states always sound great, but years of evidence (and reams upon reams of bug-charting material) indicate it’s an unrealistic approach.

As a vendor, it may be the least bad choice available in an ever-competitive marketplace. After all, if there were a few million sites that you could render as intended if only the authors used your prefix instead of just one, which would you rather: embark on a protracted, massive awareness campaign that would probably be contradicted to death by people with their own axes to grind; or just support the damn prefix and move on with life?

The practical upshot is that browsers “supporting alien CSS vendor prefixes”, as Craig Grannell put it, seriously cripples the whole concept of vendor prefixes. It may well reduce them to outright pointlessness. I am on record as being a fan of vendor prefixes, and furthermore as someone who advocated for the formalization of prefixing as a part of the specification-approval process. Of course I still think I had good ideas, but those ideas are currently being sliced to death on the shoals of reality. Fingers can point all they like, but in the end what matters is what happened, not what should have happened if only we’d been a little smarter, a little more angelic, whatever.

I’ve seen a proposal that vendors agree to only support other prefixes in cases where they are un-prefixing their own support. To continue the previous example, that would mean that when Firefox starts supporting the bare box-shadow, they will also support -webkit-box-shadow (and, one presumes, -ms-box-shadow and -o-box-shadow and so on). That would mitigate the worst of the damage, and it’s probably worth trying. It could well buy us a few years.

Developers are also trying to help repair the damage before it’s too late. Christian Heilmann has launched an effort to get GitHub-based projects updated to stop being WebKit-only, and Aarron Gustafson has published a UNIX command to find all your CSS files containing webkit along with a call to update anything that’s not cross-browser friendly. Others are making similar calls and recommendations. You could use PrefixFree as a quick stopgap while going through the effort of doing manual updates. You could make sure your CSS pre-processor, if that’s how you swing, is set up to do auto-prefixing.

Non-WebKit vendors are in a corner, and we helped put them there. If the proposed prefix change is going to be forestalled, we have to get them out. Doing that will take a lot of time and effort and awareness and, above all, widespread interest in doing the right thing.

Thus my fairly deep pessimism. I’d love to be proven wrong, but I have to assume the vendors will push ahead with this regardless. It’s what we did at Netscape ten years ago, and almost certainly would have done despite any outcry. I don’t mean to denigrate or undermine any of the efforts I mentioned before—they’re absolutely worth doing even if every non-WebKit browser starts supporting -webkit- properties next week. If nothing else, it will serve as evidence of your commitment to professional craftsmanship. The real question is: how many of your fellow developers come close to that level of commitment?

And I identify that as the real question because it’s the question vendors are asking—must ask—themselves, and the answer serves as the compass for their course.

I wil reiterate something I said on Twitter, though: the members of tech community, particularly those who are intimately familiar with the basic protocols of the Internet, need to keep working on ways to counteract SOPA/PIPA. What form that would take, I’m not sure. Maybe a truly distributed DNS system, one that can’t be selectively filtered by any one government or other entity. I’m not an expert in the area, so I don’t actually know if that’s feasible. There’s probably a much more clever solution, or better still suite of solutions.

The point is, SOPA and PIPA may soon go down to defeat, but they will return in another form. There is too much money in the hands of those who first drafted these bills, and they’re willing to give a fair chunk of that money to those who introduced the bills in Congress. Never mistake winning a battle with winning the war. As someone else observed on Twitter (and I wish I could find their tweet now), the Internet community fought hard against the DMCA, and it’s been US law for more than a decade.

By all means, take a moment to applaud the widespread and effective community effort to oppose and (hopefully) defeat bad legislation. When that’s done, take notes on what worked and what didn’t, and then prepare to fight again and harder. Fill the gap between battles with outreach to your elected representatives and with efforts to educate the non-technical in your life to explain why SOPA/PIPA were and are a bad idea.

Days of action feel great. Months of effort are wearying. But it’s only the latter that can slowly and painfully bring about long-term change.

Instead, I will reproduce here the letter I attempted to send via contact form to my state Senator this morning, and which I will print out and send by regular postal service later today.

Senator Brown:

I grew up in Lexington, Ohio. I moved to Cleveland in pursuit of a career, and found success. Through a combination of good luck and hard work, I have (rather to my surprise) become a widely recognized name in my field, which is web design and development. Along the way, I co-founded a web design conference with an even more widely respected colleague that has become one of the most respected and successful web design events in the world. This business is headquartered in Ohio—I live in Cleveland Heights with my family, and I intend to stay here until I either retire to Florida or die. Politically I’m best described as a moderate independent, though I do tend to lean a bit to the left.

As you can imagine, given my line of work, I have an opinion regarding the PROTECT IP Act which you have co-sponsored. The aims of PROTECT IP are understandable, but the methods are unacceptable. Put another way, if you wish to combat piracy and intellectual property theft, there are far better ways to go about it.

As someone with twenty years of technical experience with the Internet and nearly as many with the web—I started creating web pages in late 1993—please believe me when I say the enforcement mechanisms of the bill are deeply flawed and attack the very features of the Web that make it what it is. They are akin to making a criminal of anyone who gives directions to a park where drug trafficking takes place, regardless of whether they knew about the drug trafficking. You don’t have to be in favor of drug trafficking to oppose that.

This is not a case where tweaking a clause or two will fix it; correction in this case would mean starting from scratch. Again, the objection is not with the general intent of the bill. It is with how the bill goes about achieving those aims.

If you would like to discuss this with me further, I would be delighted to do whatever I can to help, but in any event I strongly urge you to reconsider your co-sponsorship of the PROTECT IP Act.

Thank you for your time and consideration.

Eric A. Meyer (http://meyerweb.com/)

Partner and co-founder, An Event Apart (http://aneventapart.com/)

If you agree that the PROTECT IP Act is poorly conceived, find out if your senator supports PIPA. If they do, get in touch and let them know about your opposition. If they oppose the bill, get in touch and thank them for their opposition. If their support or opposition isn’t known, get in touch and ask them to please speak out in opposition to the bill.

As others have said, postal letters are better than phone calls, which are in turn better than e-mail, which is in turn better than signing petitions. Do what you can, please. The web site you save might be your own.

I’m proud to have been a part of this effort since its inaugural launch back in 2007. It’s a major undertaking, mostly in analyzing the data and turning that into a detailed report, but it’s more than worth the time and effort. Before the Survey, we really didn’t know very much about who we were as a field of practice, and without it we wouldn’t have as clear a picture of who we are today.

There have been growing pains, of course, chief among them UCCASS, the survey software we’ve been using since the outset. Its limitations and lack of updates finally pushed us to find another platform, and we chose to move over to Polldaddy. Many thanks to the Polldaddy team for giving the survey a home and helping me figure out the best strategies for recreating the survey. (And also for putting up with my occasionally testy feature and support requests. Sorry, gang.)

Due to differences between UCCASS and Polldaddy, we ended up restructuring the survey into two distinct paths. I think this change actually speeds the process of taking the survey. I’m pretty sure just about anyone could get through it in under ten minutes.

Unsurprisingly, participation in the survey has dropped over the years; last year’s survey had a bit more than half as many respondents as the first-ever survey back in 2007. Tellingly, the actual results have been pretty consistent over the years. I’d really like to see how those results stand up to an increase of respondents, so please:

• If you haven’t taken the survey yet, kindly set aside ten minutes and do so.
• If you have taken the survey, thank you. Now, spread the word! If you could post a quick link to any mailing lists, web forums, newsgroups, or other professional communities in which you participate, it will be an enormous help. The more practitioners we have answer, the better the results.

As always, the survey will close a month after it opened; and as always, a detailed report will be published—feel free to peruse the reports from 2007 (PDF), 2008, 2009, and 2010—along with anonymized data sets for independent analysis. Together, they form a picture, but one that is still being drawn. Please help us to add the most essential detail—you!

Just yesterday, I took a screenshot of the title page of Dive Into HTML5 to include in a presentation as a highly recommended resource. Now it’s gone. That site, along with all the other “Dive Into…” sites (Accessibility, Python, Greasemonkey, etc.) and addictionis.org, is returning an HTTP “410 Gone” message. Mark’s Github, Google+, Reddit, and Twitter accounts have all been deleted. And attempts to email him have been bounced back.

This is very reminiscent of Why the Lucky Stiff’s infosuicide, and it’s honestly shocking. If anyone is in direct contact with Mark, please let me know that he’s okay via comment here or by direct e-mail, even if his internet presence has been erased. As much as I hate for the world to lose all of the incredible information he’s created and shared, that would be as nothing compared to losing the man himself.

“Embracing HTTP error code 410 means embracing the impermanence of all things.”

—Mark Pilgrim, March 27, 2003 (diveintomark.com)

Update 5 Oct 11: Jason Scott just tweeted the following:

Mark Pilgrim is alive/annoyed we called the police. Please stand down and give the man privacy and space, and thanks everyone for caring.

The communication was specifically verified, it was him, and that’s that. That was the single hardest decision I’ve had to make this year.

So there you have it. I’m sorry to have helped annoy Mark, am very glad he’s well, and sincerely hope that we can all give him the privacy he desires. And with that, I’m going to sleep now. Thank you, everyone.

Addendum 5 Oct 11: Several people have asked me if I know why Mark took this step. I don’t. I have three comments in the moderation queue all claiming to be from Mark, only one of which even approaches sounding credible, and none of which have any sort of verification. Unless Mark contacts me directly, or changes his server to return an explanatory note instead of or along with a 410, or something similar, I’m as much in the dark as anyone else. If he’d like to talk with me about it, he’s certainly more than welcome to do so, but he’s under no obligation to explain himself to me or anyone else.

Mirrors of Mark’s work have started appearing (see the comments for some of them) and so his legacy, if not his presence, will not be lost. I am assuming that he has simply withdrawn from digital life, his reasons are his own, and that if he feels interested in explaining those reasons he will find a way to do so. Regardless, his path is his own and we should leave him to walk it as he chooses.

I’ll warn you up front that as of this writing the user interaction is not ideal, and in some places the presentation suffers from too much content overlap. This happens in timelines where lots of drafts were released in a short period of time. (In one case, two related drafts were released on the same day!) I intend to clean up the presentation, but for the moment I’m still fiddling with ideas. The obvious one is to rotate every other spec name by -45 degrees, but that looked kind of awful. I suspect I’ll end up doing some sort of timestamp comparison and if they’re too close together, toss on a class that invokes a -45deg rotation. Or maybe I’ll get fancier!

The interaction is a little tougher to improve, given what’s being done here, but I have a few ideas for making things, if not perfect, at least less twitchy.

I should also note that not every module is listed as I write this: I intentionally left off modules whose last update was 2006 or earlier. I may add them at the end, or put them into a separate set of timelines. The historian in me definitely wants to see them included, but the shadow of a UX person who dwells somewhere in the furthest corners of my head wanted to avoid as much clutter as possible. We’ll see which one wins.

Anyway, somewhat like the browser release timeline, which is probably going to freeze in the face of the rapid-versioning schemes that are all the rage these days, I had fun combining my love of the web and my love of history. I should do it more often, really. The irony is that I don’t really have the time.

Put simply: as per the Introduction of the latest CSS 2D Transforms draft, a transformed element creates a containing block for all its positioned descendants. This occurs in the absence of any explicit positioning of the transformed element.

Let’s walk through that. Say you have a document whose body contains nothing except a position: static (normal-flow) div that contains some absolutely-positioned descendants. The containing block for those positioned elements will be the root element. Nothing unusual or unexpected there.

But then you decide to declare div {transform: rotate(10deg);}. (Or even 0deg, which will have the same result.) Now the div is the containing block for the absolutely-positioned elements that descend from it. It’s as though transforming an element force-adds position: relative. The positioned elements will rotate with their ancestor and be placed according to its containing block—not that of the root element.

Okay, so that’s a little unusual but perhaps not unexpected. I could make arguments both ways, and some of the arguments could get pretty complex. To pick one example, if the transformed element didn’t generate a containing block, how would translate transforms be handled?

Either way, here’s where things got really troublesome for me: a transformed element creates a containing block even for descendants that have been set to position: fixed. In other words, the containing block for a fixed-position descendant of a transformed element is the transformed element, not the viewport. Furthermore, if the transformed element is in the normal flow, it will scroll with the document and the fixed-position descendants will scroll with it. You can see my test case, where the red and blue boxes would overlap each other and stay fixed in place, except the second green div has been rotated.

Obviously this makes the fixed-position elements something less than fixed-position. In effect, not only does the transformed element act as if it’s been force-assigned position: relative, the fixed descendants behave as if they’ve been force-changed to position: absolute.

I find this not only unusual and unexpected, but also a wee bit unsettling. Personally, I think it goes too far. Fixed-position elements should be fixed to the viewport, regardless of the transformation of their ancestors. Of course, if you agree with my thinking there, realize that opens a whole new debate about how, or even whether, transforms of ancestors should be carried to fixed-position descendants.

I have my own intuitions about that, but this is definitely territory where intuitions are to be treated with caution. There are a lot of interacting behaviors no matter what you do, and no matter what you do someone’s going to find the results baffling in some way or other.

But since I do have intuitions, here’s what they are: transformed elements in the normal flow or floated do not establish containing blocks for absolutely- and fixed-position descendants. This means that any transforms you apply to the transformed element are not applied to the positioned descendants, because transforms don’t inherit.

What if you want a normal-flow transformed element to be a containing block? Use position: relative, same as you would if there were no transform. And if you want the transforms to be passed on to the descendants even though no containing block is established? The inherit value would work in some cases, though not all. That’s where my approach runs aground, and I’m not yet sure how to get it back to sea.

Okay, so that’s what I think. What do you think?

Yesterday morning, in a small office on the second floor of the Cuyahoga County Courthouse in downtown Cleveland, Ohio, Kat and Carolyn and Rebecca and I finalized our adoption of Joshua. There were a few witnesses to this: the social worker who has handled our case from the outset, as she did Carolyn’s; the lawyer who made sure all of our paperwork was correct; my sister and father and stepmother; our friends Gini and Ferrett and Jim; and the magistrate who conducted the proceedings.

As with Carolyn and Rebecca, I haven’t talked about Joshua being adopted—not that it was any big secret, given our having adopted our other children. Nevertheless, I did this for the same old reasons: for the past seven months, we’ve been borrowing him from his legal guardians, the adoption agency. The usual monthly checkups from our social worker still occurred, and there was still the theoretical possibility of Joshua’s placement being revoked for any reason whatsoever. Or even for no reason at all. I had no way to know if a blog post might somehow make things more difficult, so I left it alone.

All this was always a basically theoretical possibility—there was no real fear of it actually happening—but now, even the theory is undone. Joshua is now legally our son and the girls’ brother just as completely as he has long been both in our hearts. He is now ours—but even more than that, and far more importantly, we are now his.

Over a celebratory lunch, Kat held our sleeping son in her arms and I cradled his head with my hand as we whispered our love for him, for our girls, and for each other.

Now available: the results from the A List Apart Survey for People Who Make Web Sites, 2010. This is the fourth industry snapshot we’ve compiled, and the story that’s emerged over that time is proving to be pretty consistent. You can get a high-level view from the Introduction, and then dive deeper into the results in the following chapters. And, as is traditional, the Addendum contains links to the full (anonymized) data set in three formats for your own analytical investigations. We’d love to see what you come up with!

Something that surprised me quite a bit was that in 2010 we got about half the number of respondents we’ve gotten in past years—not quite seventeen thousand participated in 2010 instead of just over thirty thousand as we saw in previous years. I’m not quite sure what to make of that. Is the industry shrinking? Did we not get the word out as effectively? Was it a bad time of year to run a survey? Are people getting tired of taking the survey? There’s no real way to know.

At least there weren’t any wild swings in the results, which might have indicated we’d lost some subgroups in disproportionate numbers. Whatever caused the drop in participation, it appears to have done so in an evenly-distributed fashion.

Regardless, I’d like to see higher participation next year, so if anyone has good suggestions regarding how to make that happen, please do let me know in the comments.

We plan to run the 2011 survey in the next couple of months (and I’ll post a bit more about that soon) but for now, I hope you find the 2010 results an interesting and useful look at who we are.

To be clear, when I say “Can CSS create art?” I don’t mean that in the sense of wondering if art, or artful designs, can be accomplished with CSS. I think we all know the answer there, and have known at least since the Zen Garden got rolling. What I’m doing here is using some basic CSS to generate art, using web sites as the medium. For the series I linked, I spun all of the elements on a page using transform: rotate() to see what resulted. Any time I saw something I liked, I took a screenshot. After I was done, I winnowed the shots down to the best ones.

As some of you old-schoolers will probably have recognized, I’m absolutely following in the footsteps of Joshua Davis here, and in fact my working title for this effort was “Once Upon a Browser”. I saw Josh speak years ago, and clearly remember his description of how he generated a lot of his art. My process is almost identical, albeit with a bit less automation and computational complexity.

Because this is me, I built a little commentary joke into the first images in the series. It’s not terribly subtle, but with luck one or two of you will get the same chuckle I did.

I’m already thinking about variants on this theme, so there may be more series to come. In the meantime, as I surf around I’ll stop every now and again to spin what I see. I’ll definitely mention any new additions via Twitter, and new series both there and here. And of course if you follow me on Flickr, you’ll see new pieces as they go up.

I hope you enjoy them half as much as I enjoyed creating them. And if anyone wants to use the originals as desktop wallpapers, as Tim proposed, feel free!

• [A]n Event Apart. Not surprising, I co-founded it.

• [B]ruce Lawson’s personal site. I’ve been there most recently thanks to his “HTML5 gurus on Twitter” post. I still feel like a little bit of a poser for being listed, but I appreciate the regard. Bruce is good folks.

• [C]NN. I think half the reason I go any more is to see what manner of goofiness they have in their featured boxes.

• [D]aring Fireball: BBColors. I went there so I could back up my current color scheme and try out rcarmo’s port of Solarized Light, which I’m using now in modified form (I hated the default selected-text highlight).

• [E]conomist.com: Democracy in America. I have fun there, as time permits; there’s a surprisingly strong commenter community that keeps drawing me back. I truly wish the Clausewitz blog had been a contender here, but it seems to be having a lot of trouble getting started. I suppose it’s suffering the friction of warblogging.

• [F]avstar.fm. I like to see who’s favorited and retweeted my stuff for the obvious ego reasons, but more importantly because people who like my CSS and other technical stuff are often people I might like to follow. Similar interests, and all that. The very close runner-up in this category is obviously [F]lickr, and it would probably take top billing some days.

• [G]oogle. Of course.

• [H]iderefer. I hacked WordPress (via a plugin) so links on my Dashboard are routed through Hiderefer. This avoids giving away the location of my WordPress install to malicious sites that manage to get comments into the approval queue. In doing this Letter Sweep, I discovered that I need to update the plugin to use Nullrefer instead, so I just did.

• [I]MDB. I don’t get to watch a lot of movies these days, nor do I actually think I would do so even if the opportunity arose, but somehow I still love them.

• [J]oe Wein’s blog. Specifically, the post “Domain registration scam in China“, which I was reading after getting some suspicious e-mail. The post confirmed my suspicions. Thanks, Joe!

• [K]ottke.org. The only guess the browser had for K was the post “Unicode, all of it“.

• [l]ists.css-discuss-org. Not surprising, I co-founded it.

• [M]eyerweb. Not surprising, I administrate it.

• [N]etflix. I’ve been working my way through “Avatar: The Last Airbender” to see if it would be appropriate for the young’uns.

• [O]pera. Specifically the fantastic “Opera version history“, which I wish every browser vendor emulated in detail.

• [P]enny Arcade. Yo when I hit it I hit L-shift-O to the quote and then dollar…

• [Q]uora. Another one-entry guess list, this time for the question “Given our current technology and with the proper training, would it be possible for someone to become Batman?“. I think that’s one of three times I’ve ever been on Quora, whose popularity I still find a little mystifying. But then I remember and was a fan of alt.destroy.the.earth, so who am I to judge what’s interesting?

• [R]etreats 4 Geeks. Thanks to which I just recently had a ridiculously good time hanging out with twelve awesome people in the mountains above Gatlinburg, TN. Runner-up: the fabulous [R]atfist.

• [S]kynet. That’s my version of localhost, which means clicking the link will do you no good at all unless you did the same thing. (Skynet is also the SSID of my home wifi cloud, which makes a bit more sense.)

• [T]witter. Of course.

• [U]S Bank. My bank.

• [v]isualguidanceltd.blogspot.com‘s post “CSS Married Porn AND had a Baby! OR Eric Meyer: ‘Dirty Thought-CSS’ Diary!“. Yeah, I don’t know either.

• [W]orld Wide Web Consortium (W3C). Of course.

• [X] had literally not a single guess. No, I don’t follow XKCD; I figure the really good ones will get tweeted and copied to hell and gone anyway, so I just rely on the collective to pre-filter for me. Apparently I haven’t been there recently. Make of that what you will.

• [Y]ouTube. Because where else am I going to find Bert and Ernie singing old-school M.O.P.?

• [Z]azzle. Specifically the page for the “CSS IS AWESOME” mug, which I was considering buying because it’s not often you find an unalloyed song of praise to a CSS capability that no other Web technology has yet managed to duplicate. But then I remembered I don’t really drink mug-based liquids, so I passed. (And the T-shirts don’t make the content nearly big enough, so I passed again.)

So what’s your browser guess for you?

Anyway, here’s a sampling of the sites most frequently mentioned and how they’re using HTML5, listed in no particular order.

Using new-to-HTML5 markup (and DOCTYPE)

• MailChimp
• slashdot
• Obama for America
• About
• Unilever
• Myspace
• Sencha
• Nike Better World
• Apple
• The Killers
• The GLobe and Mail
• YouTube – Basically only the video element, and that only if you’ve enrolled in the HTML5 trial.

Using HTML5 DOCTYPE but no apparent new-to-HTML5 markup

• Google
• USA.gov
• Digg
• Yahoo – I’m told that Yahoo! Mail uses HTML5 features but I’m not a user so I can’t verify that.
• Flickr
• Netflix

And then there’s Facebook. Rumor has it they’re using HTML5 features like the History API while still bearing an XHTML DOCTYPE. I was also told they use video but all the videos I saw were Flash-based. It’s possible that more is going on—who knows, maybe Farmville is all HTML5 now—but I was only willing to put up with the user experience for so long.

Some notes:

• I didn’t run a spider script to verify which HTML5 elements, if any, were being used on a site. Instead I surfed around using a user stylesheet that highlights HTML5 elements and looked for dashed red outlines. If they were there, the site got “uses HTML5 markup”. If I didn’t see any, then “no apparent HTML5 markup”. This may mean I miscategorized a site or two, in which case sorry. Even if not, these lists won’t stay current for more than a couple of weeks, so regard this as a single snapshot in time, not the whole movie.
• In my limited and purely anecdotal peerings, far and away the most commonly-used HTML5 element was section. nav appeared to run a distant second.
• Any site that uses font replacement is using HTML5: canvas. I didn’t list such sites, so bear that in mind. (Sorry, Beano.) I just hope such sites change their DOCTYPEs to match.
• I did not list any site that lacked a DOCTYPE. I don’t care if the HTML5 DOCTYPE is optional, that doesn’t mean any DOCTYPE-less page is using HTML5. Or, if it does, my next step is to write a MeyerHTML DTD with an optional DOCTYPE and then charge you all $1 per site for using invalid markup in violation of the terms of the DTD’s license. And then I’m buying an island. Oahu seems nice.

Comments are switched off for once partly because I don’t really want another faceful of politics right now, and partly because attempts to post links to other HTML5 sites will end up in the spam trap and frustrate posters. Feel free to go nuts on your own sites, of course.

The way it works is you input a series of transform functions, such as translateX(22px) rotate(33deg) scale(1.13). The end-state and its matrix() equivalent should update whenever you hit the space bar or the return key, or else explicitly elect to take the red pill. If you want to wipe out what you’ve input and go back to a state of blissful ignorance, take the blue pill.

There is one thing to note: the matrix() value you get from the tool is equivalent to the end-state placement of all the transforms you input. That value most likely does not create an equivalent animation, particularly if you do any rotation. For example, animating translateX(75px) rotate(1590deg) translateY(-75px) will not appear the same as animating matrix(-0.866025, 0.5, -0.5, -0.866025, 112.5, 64.9519). The two values will get the element to the same destination, but via very different paths. If you’re just transforming, not animating, then that’s irrelevant. If you are, then you may want to stick to the transforms.

This tool grew out of the first Retreats 4 Geeks (which was AWESOME) just outside of Gatlinburg, TN. After some side conversations betwen me and Aaron during the CSS training program, we hacked this together in a few hours on Saturday night. Hey, who knows how to party? Aaron of course wrote the JavaScript. Early on we came up with the punny name, and of course once we did that the visual design was pretty well chosen for us. A free TTF webfont (for the page title), a few background images, and a whole bunch of RGBa colors later we had arrived. Creating the visual appearance was a lot of fun, I have to say. CSS geeks, please feel free to view source and enjoy. No need to say “whoa”—it’s actually not that complicated.

So anyway, there you go. If you want to see the matrix(), remember: we can only show you the door. You’re the one that has to walk through it.

For fun, and also to give fans of this or that property a chance to petition for re-inclusion, here are the properties and modules I cut. Think of it as the blooper reel, which can be taken more than one way. I’ve organized them by module because it’s easier that way.

• The backface-visibility property from the 3D Transforms module. This is one I’m already reconsidering, but I haven’t found any indication that anyone besides Webkit will be picking it up in the near future. Still, I did document the rest of the 3D Transforms module so I may add this back in during the tech review stage.
• rotation and rotation-point from the CSS3 Box module. These have been effectively replaced by the 2D Transforms module, but the Box module hasn’t been updated since that happened.
• Everything in the Flexible Box Layout module. There are, as of now, just too many sections bearing notes, warnings, questions, and general feelings of instability and future change for me to feel comfortable including the properties from this module. I’m probably going to catch some flak for that.
• grid-columns and grid-rows from the Grid Positioning Module Level 3, which effectively means means excluding the entire module. Some day maybe I’ll write a separate pocket reference just for the various CSS layout systems.
• font-stretch. Its continued exclusion saddens me, because I am exactly the sort of sheep-stealing lowlife who would programmatically stretch and compress font faces and like it, but so far as I can tell nobody’s supporting the property. Alas.
• Basically, the entirety of the Generated Content for Paged Media module.
• The Behavioral Extensions module, which means the binding property as well as the :bound-element pseudo-class.
• All the properties in CSS Marquee module. I’d love to see someone make a compelling case for re-instating them.
• The following properties from CSS Text Level 3: hanging-punctuation, punctuation-trim, text-align-last, text-emphasis-position, text-emphasis-style, text-emphasis, text-justify, text-outline, text-wrap, white-space-collapsing, and word-break.
• The following properties from the Basic User Interface module, dated 2004: appearance, icon, nav-down, nav-left, nav-right, nav-up, and nav-index.
• The Hyperlink Presentation module, dated 2004.
• The Presentation Levels module, dated 2003.
• move-to and crop from the CSS3 Generated and Replaced Content module, dated 2003.
• The Line module, dated 2002 and bearing my name for no reason I can recall. The one property listed there which I kept is vertical-align, and I just used the CSS2.1 definition.

After all that, I imagine you’re going to laugh uproariously when I tell what I did include: paged and aural properties. I know—I’m kind of poleaxed by my own double standard on that score. I included them for historical reasons (they’ve long been included) and also because they’re potentially very useful to a more accessible future. Besides, if we run out of pages, they’re in their own section and so very easy to cut.

I’m pretty sure I listed everything that I explicitly dropped, so if you spot something that I absolutely have to reinstate, here’s your chance to let me know!

In Webkit and Gecko, hovering the first div causes the span to animate a 270 degree rotation over one second, but when you unhover the div the span immediately snaps back to its starting position. In Opera 11, the span is instantly transformed when you hover and instantly restored to its starting position when you unhover.

In all three (Webkit, Gecko, and Opera), hovering the second div triggers a one-second 270-degree rotation of the span. Unhovering causes the rotation animation to be reversed; that is, a one-second minus-270-degree rotation—or, if you mouseout from the div before the animation finishes, an rotation from that angle back to the starting position. Either way, it’s completely consistent across browsers.

The difference is that in the first test case, both the transform and the transition are declared on hover. Like this (edited for clarity):

div:hover span {
	transition: 1s transform;
	transform: rotate(270deg);
}

In the second test case, the transform and the transition are split up like so:

div span {
	transition: 1s transform;
}
div:hover span {
	transform: rotate(270deg);
}

It’s an interesting set of results. Only the second case is consistently animated across the tested browsers, but the first case only animates one direction in Webkit and Gecko. I’m not sure which, if any, of these results is more correct than the other. It could well be that they’re all correct, even if not consistent; or that they’re all wrong, just in different ways.

At any rate, the takeaway here is that you probably don’t want to apply your transition properties to the hover state of the thing you’re transitioning, but to the unhovered state instead. I say “probably” because maybe you like that it transitions on mouseover and instantly resets on mouseout. I don’t know that I’d rely on that behavior, though. It feels like the kind of thing that programmer action, or even spec changes, will take away.