CSS Print Tests or How to Go Crazy after a Few Hundred Revisions

I have been building tests for CSS 2.1 and CSS 3 print conformance since last October, in partnership with Revenution and HP. It’s been a terrific learning experience. Previous to going out on my own, I worked at a world-class web development consultancy, where I’d developed much of our approach to CSS and browser conformance, so I felt confident in my ability to churn out these tests by the dozen. It hasn’t been so.

It’s easy enough to build pages in CSS and to work around browser bugs. You code, load in a browser, tweak, refresh, etc. Take the user agent out of the equation and things become difficult. Not only is it tough to check your work after you build something, but it’s hard to conceive of an approach to the task when you’re trying to build a test for a CSS property that doesn’t exist, especially if you haven’t ever run into a situation where you thought, “Know what I wish CSS had?” (Actually, those situations are even worse, because I can never remember what I was doing to get to that point, so I wind up still having to come up with a test with the bonus of a scratching feeling in the back of my noggin.)

Not that I’m totally alone: the W3C representatives are fantastic. I used to think I was thorough: when you come into a meeting with a client who wants to build an app and start getting feedback like, “We hadn’t even thought of that,” you’re covering your bases.When you break a big application down into a 100+ use cases, you know how to get to the details. This is a level-of-magnitude difference. It makes you frustrated with the nuance and vagueness in language. Early on I would get upset when tests came back just because of the instructions, feeling it should have been obvious what I meant. Doubly frustrating because my high school freshman English teacher (think Dead Poets Society without any self-murder) had spent time teaching us how to be clear: one of our first assignments was to write the instructions for tying your shoe. He then performed everyone’s assignment in the class. We went 0 for 8, but created some fantastic knots. Obviously, the word “obvious” has no place in instructions.

My other companion in the journey is Prince; not a short man from Minnesota, but an application that simulates a CSS2.1/ CSS3-compliant (if unsexy) user agent. Given I’m still building tests to show how a  CSS2.1/ CSS3-compliant user agent should work and given the spec still changes occasionally, Prince can’t get everything right. Which means it’s like a travel guide from a logic problem in To Mock a Mockingbird (“if you’re traveling with a man who always lies and his brother who never lies … “). I bought that book thinking it was about how to mock objects in unit tests. When I found out it was a book of logic problems that made me feel stupid, I had flashbacks to one of our last assignments in that freshman English class: LSAT word problems. While it taught us (or at least me) a good deal about how to wring meaning from obscurity (poetry), I always felt it was less-than-coincidental our teacher left for law school after that one year.

Either way, thank you Steven Muller for making me a better test case writer. Sorry I never got around to just being the writer you were hoping for (note the dangling participle and consider the day you had us rip the entire grammar section out of our text book).