Anyway, the second episode, starring Steve Champeon, was recorded and released last week.  Hear about SGML and HTML, progressive enhamcement, the inside and little-known story of the WaSP’s success, and more.  I learned at least one thing I had never heard before, and Steve’s just a fun guy to talk to regardless of topic, so hopefully you’ll find it as interesting as I did.

Next week, we’ll be recording our third guest, Dave Shea, on the afternoon of Wednesday, October 17th (a week from today!).  In addition to being a pretty darned fantastic designer, Dave is of course the mastermind behind the groundbreaking CSS Zen Garden.  We’ll spend our time talking about that and other products of Dave’s brilliance, like CSS Sprites and Chalkwork Icons, as well as find out what he’s been doing of late.  Jen and I hope you’ll join us!

First component is the pricing of the pre-books.  Roughly speaking, each pre-book will be priced according to its length.  The assumed base for the electronic version is $2.99, and $7.99 for the print version, with significantly longer pre-books (say, one where two chapters are combined) priced somewhat higher.  How much higher depends on the length.  It’s possible that prices will drift a bit over time as production or printing costs change, but there’s no way to guarantee that.  We’re basically pricing them as they come out.

At the end of the process, when all the chapters are written and bundled into an omnibus book edition, there will be discounts tied to the chapters you’ve already purchased.  The more chapters you bought ahead, the deeper the discount.  If you bought the pre-books direct from O’Reilly, then you’ll automatically get a discount code tailored to the number of pre-book you’ve already bought.  If you bought them elsewhere, then O’Reilly’s customer service will work to create a comparable discount, though that will obviously be a slower process.

The second component is: how much will the codes cut the price of the final, complete book?  That I cannot say.  The reason is that I don’t know (nor does anyone) what minimum price O’Reilly will need to charge to cover its costs while taking into account the money already paid.  I’m hopeful that if you bought all of the pre-books, then the electronic version of the final book will be very close to free, but again, we have to see where things stand once we reach that point.  It might be that the production costs of the complete book mean that it’s still a couple of bucks even at the deepest discount, but we’ll see!  One of the exciting things about this experiment is that even my editor and I don’t know exactly how it will all turn out.  We really are forging a new trail here, one that I hope will benefit other authors—and, by direct extension, readers—in the future.

As announced last week on the O’Reilly Tools of Change for Publishing blog, the next edition of CSS:TDG will be released chapter by chapter.  As each one is finished, it will go into production right away instead of waiting for the entire omnibus book to be completed.  You’ll be able to get each standalone as an e-book, a print-on-demand paper copy, or even as both if that’s how you roll.  I’ve taken to calling these “pre-books”, which I hope isn’t too confusing or inaccurate.

There are a lot of advantages to this, which I wrote about in some detail for the TOC post.  Boiled down, they are: accuracy, agility, and à la carte.  If you have the e-book version, then updates can be downloaded for free as errata are corrected or rewrites are triggered by changes to CSS itself.  And, of course, you can only buy the pre-books that interest you, if you don’t feel like you need the whole thing.

I should clarify that not every pre-book is a single chapter; occasionally, more than one chapter of the final product will be bundled together into a single pre-book.  For example, Selectors, Specificity, and the Cascade is actually chapters 2 and 3 of the final book combined.  It just made no sense to sell them separately, so we didn’t.  “Values, Units, and Colors”. on the other hand, is Chapter 4 all by itself.  (So if anyone was wondering about the pricing differences between those two pre-books, there’s your explanation.)

If you want to see what the e-book versions are like, CSS and Documents (otherwise known as Chapter 1) has been given the low, low price of $0.00.  Give it a whirl, see if you like the way the pre-books work as bits.

My current plan is to work through the chapters sequentially, but I’m always willing to depart from that plan if it seems like a good idea.  What amuses me about all this is the way the writing of CSS: The Definitive Guide has come to mirror CSS itself—split up into modules that can be tackled independently of the others, and eventually collected into a snapshot tome that reflects a point in time instead of an overarching version number.

Every pre-book is a significantly updated version of their third-edition counterparts, though of course a great deal of material has stayed the same.  In some cases I rewrote or rearranged existing sections for greater clarity, and in all but “CSS and Documents” I’ve added a fair amount of new material.  I think they’re just as useful today as the older editions were in their day, and I hope you’ll agree.

Just to reiterate, these are the three pre-books currently available:

• CSS and Documents (free) — the basics of CSS and how it’s associated with HTML, covering things like link and style as well as obscure topics like HTTP header linking
• Selectors, Specificity, and the Cascade — including all of the level 3 selectors, examples of use, and how conflicts are resolved
• Values, Units, and Colors — fairly up to date, including HSL/HSLa/RGBa and the full run of X11-based keywords, and also the newest units except for the very, very latest—and as they firm up and gain support, we’ll add them into an update!

As future pre-books come out, I’ll definitely announce them here and in the usual social spaces.  I really think this is a good move for the book and the topic, and I’m very excited to explore this method of publishing with O’Reilly!

Hailing from Sydney, Australia, John by himself has seen and done more on the web than most web teams put together.  First encountering the web in the early 1990s, he built one of the very first CSS tools, Style Master, and a number of other web development tools; published a wealth of information like support charts and free courses; wrote the deeply insightful and far-seeing article “A Dao of Web Design”; influenced the course of the Web Standards Project; and founded a successful international conference series that continues to this day.

We’re incredibly excited to have John as our inaugural guest, and hope you’ll join us for the live recording this Thursday, September 20th at 6pm Eastern/3pm Pacific.  That’s also Friday, September 21st at 8am Sydney time, and 2200 UTC if you want to calculate your own local offsets.  The time zone dance is the reason we’re recording the first show at that particular time.  Moving forward, the plan is to record on Wednesdays, usually mid-afternoon (US Eastern) but sometimes in the morning—again, depending on the time zones of our guests.

Be able to say you were there when it all started:  please join us for the live recording, and subscribe to get the finished podcasts as they’re released.  We already have some great guests lined up for subsequent shows—more on that as we firm up dates and times—and some interesting plans for the future.  We really hope you’ll be there with us!

To me, history is vital.  As a species, we’ve made a plethora of mistakes and done myriad things right, and the record (and outcomes) of those successes and failures can tell us a great deal about how we got to where we are as well as where we might go.  (Also, from a narrative standpoint, history is the greatest and most authentic story we’ve ever told—even the parts that are untrue.)  The combination of that interest and my ongoing passion for the web is what led me to join the W3C’s recently formed Web History Community Group, where efforts to preserve (digital) historical artifacts are slowly coalescing.

But even more importantly, it’s what has led me to establish a new web history podcast in association with Jen Simmons of The Web Ahead.  The goal of this podcast, which is a subset of The Web Ahead, is to interview people who made the web today possible.  The guests will be authors, programmers, designers, vendors, toolmakers, hobbyists, academics: some whose names you’ll instantly recognize, and others who you’ve never heard of even though they helped shape everything we do.  We want to bring you their stories, get their insights and perspectives, and find out what they’ve been doing of late.  The Mac community has folklore.org; I hope that this podcast will help start to build an similar archive for the web.  You can hear us talk about it a bit on The Web Ahead #34, where we announce our first guest as well as the date and time for our first show!  (Semi-spoiler: it’s next week.)

Jen and I have took to calling this project The Web Behind in our emails, and the name stuck.  It really is a subset of The Web Ahead, so if you’re already subscribed to The Web Ahead, then episodes of The Web Behind will come to you automatically!  If not, and you’re interested, then please subscribe!  We already have some great guests lined up, and will announce the first few very soon.

I haven’t been this excited about a new project in quite some time, so I very much hope you’ll join Jen and me (and be patient as I relearn my radio chops) for a look back that will help to illuminate both our present and our future.

If you’re inclined to join us in 2013, and I really hope you are, here are the cities and dates:

• Atlanta – February 18-20
• Seattle – April 1-3
• San Diego – May 20-22
• Boston – June 24-26
• Washington, DC – August 5-7
• Chicago – August 26-28
• Austin – September 30-October 2
• San Francisco – December 9-11

Back to San Diego—hooray!  I looove to visit San Diego.

As was the case this year, all eight of 2013’s shows will feature a mix of new and familiar speakers presenting all-new talks shedding light on old problems and new ideas.  Thus not every show’s lineup is yet complete:  while we already have some speakers confirmed and announced for every event, we’re leaving the later shows in the year open so we can add fresh speakers and timely content.

Since all eight shows went on sale last month we’ve already had a bunch of people register, so you should definitely get those approval processes moving now if you want to avoid being shut out.  We had lengthy waiting lists at every 2012 show, and there were very few cancellations.  It never feels good to turn people away, but the venues’ capacities are what they are!

Being a part of An event Apart has been an amazing experience for me and for so many people, and our overriding goal is to make 2013 even better.  I hope you’ll join us!

If you really want the TL;DR version, the results are largely the same as they’ve been in the past.  The gender ratio, for example, is still in the vicinity of 5-to-1 male-to-female, with half a percent answering Other (a new option in the 2011 survey).  Most respondents are in the age range 19-44 and live in the United States.  And so on.  That might sound like I’m bored by the results, but their very consistency even as the number of respondents has dropped over five years fascinates me.

It did take quite a while to publish the results.  I feel personally very bad about the delay, because I run the numbers and it just took me a long time to get them run.  Partly, I admit, I put it off because some of the numbers in previous years were a royal pain to generate, thanks in part to the way the data is formatted and in part because of the fine slicing that was done.  This was finally addressed through various means, and now the report is done.  I can’t thank Sara Wachter-Boettcher enough for her keen editing eye and firm strategic oversight, not to mention writing all the commentary text to accompany the charts.  If not for her, the report might still not be done.  And of course without the unwavering support and dedication of Jeffrey Zeldman, the survey might not have existed at all.

So we’ve done this five times, and the results are consistent.  What now?  There is much to discuss, and the answers aren’t yet clear; but I do know that this project brings me more professional pride than almost anything I’ve ever done.  It tells us a lot about ourselves—and in a profession that is often characterized by single-person “web teams” and distributed offices, one which may never have a certification process or other form of registry, that’s something valuable.  Thank you for helping us see ourselves a little bit more clearly.

What?

As a recap, the Cicada Principle states that if you pick a few simple patterns that repeat at prime-number intervals, you can create complicated patterns that only repeat at intervals that are the product of the individual intervals.  For example, if you have patterns that repeat every 3, 5, and 7 pixels (respectively), the combination of the three will repeat every 3×5×7 pixels, which is to say every 105 pixels.  Bump up the intervals, and you get some truly staggering numbers.  For example, shift up to 7, 11, and 13 pixels and their combination repeat every 1,001 pixels; combining 11, 13, and 17 gets you 2,431; combining 13, 17, and 23 yields 5,083.

The examples presented in the original article use semi-opaque PNGs to achieve this effect.  All I did was replace their images with images of my own; to wit, CSS gradients.  (Yes, gradients are images, every bit as much as any PNG.  They’re just described differently.)  In doing so, I not only reduced server hits, but I also saved a fair number of bytes.  In the first case, I did so while achieving pixel-perfect fidelity to the original.  In the second case, I didn’t make it exactly the same as the original, but I got fairly close in 0.63KB (2.81KB with prefixes).  I could probably get closer to the original with a little more effort—a couple of my gradients are a little too smeary—but that will probably wait a while, if I ever get to it at all.  But, again, the final result is a kilobyte or two; the original example was 23KB plus extra server hits.

That was the real reason for my efforts, aside from the simple pleasure of doing it: to find out how much more efficient a gradient could be than a raster image in appropriate situations.  I had expected some savings with gradients, but I was frankly astounded by how much was saved.  You can do a lot more with gradients than sunset backgrounds and lickable button highlights.

Of course, gradients are not right for every situation: the third example in “The Cicada Principle”, for example, should only be done with gradients as an example of how not to do it.  Possibly also as a public declaration of deep masochistic tendencies.  Either way, you’d probably crash browsers, and that’s currently the job of radial gradients.

I’ll be very interested to see if people come up with their own cicadient examples.  If you do, let us know about them in the comments!

To take those two things in reverse, I got word from my editor that color is definitely an option for the book, though the exact form it will take is not 100% certain.  The options range from an insert of color plates to printing color on a per-page as-needed basis, and it’s hard right now to know what will make the most sense for the book and its price.  We’re hoping for the per-page approach, but it will depend on just how fast color prices plunge in the near(ish) future and what the book requires.  The glorious, glorious upshot is that I can abandon all thought of grayscale requirements and only concentrate on avoiding light yellows, which I guess print badly.

As for visualizations, I created another to go with the HSL-16 and HSL-147 visualizations I mentioned in an earlier post:

• Getting HSL from RGB — a look at how the arrangement and fading of the three primaries yields the complete hue wheel.  Its point is a little less obvious than the others, but (I hope) only by a little.  If you’ve ever wondered how RGB and the hue part of HSL relate to each other, this visualization should help answer the question.

I think I’m done with visualizing colors for now, but I think I said that before, so you never know.  I mean, you know, colors, man!  What do they mean?

First, I couldn’t just drop them in as add-ons; the whole section had to be partially rearranged, and chunks of the text rewritten or replaced.  Okay, yes, I admit, that’s par for the new-edition course, and I’m not complaining so much as describing.  The far more troubling challenge: how to explain HSL in a grayscale book.

(I should note that I’m hoping to convince O’Reilly to make the move to color, even though that likely means reshooting damn near every figure in the text.  Even if full color for 600-700 pages is not economically viable, which has always been the problem in the past, then I’m hoping for at least a set of color plates.  We’ll see!  At present, though, I have to assume we’ll be committing grayscale to paper.)

Partly the challenge here is one of clear explanation and illustration, which is never easy even in the most ideal of environments; but the other part is that I’ve never really been comfortable with HSL.  I know it’s held to be far more intuitive than RGB, but I have 30 years of RGB experience and next to no HSL experience.  I can’t help but have that color my perception (ah HA ha).

In an effort to overcome my discomfort, I started messing around with the relationships between HSL and more familiar colors, starting with keyword sets.  I’ve spun two visualizations out of that effort:

• HTML4 Color Keywords in HSL—wherein I map the sixteen color keywords defined in HTML4 onto an HSL color wheel and grayscale bar.  What I really like about the end result is the clear evidence of careful color selection.  It’s a balanced set, at least mathematically, and seeing the relationships between the colors and thus how to present them helped me develop a fair amount of HSL intuition.

  This was also an excuse to attempt cleverness with CSS Transforms.  The results please me.

• SVG/CSS3 Color Keyword Distribution—mapping out how the full set of 147 SVG/CSS3 (neé X11) color keywords are distributed around the hue wheel.  Not very well, as it turns out.  I don’t know that this taught me very much about HSL itself, but I did get a firmer grip on the interplay between saturation, lightness, and luminance, all of which helped a great deal in the arrangement of the ‘spikes’.

  This one turned into an excuse to play with canvas drawing, after Mårten Björk responded to a Twitter request with a huge head start on the problem.  Originally, this was going to be another Transformapalooza, but I’m glad it went in this direction instead.

Thanks to these visualizations and (more importantly) the programming and thinking I did to create them, I’m now much more comfortable with HSL.  As a result, the “HSL and HSLa Colors” section of chapter 4 is a lot better than it would have been.  I even came up with what I think are some pretty good ways for illustrating HSL in a grayscale environment and ways to link it to the RGB model for the benefit of people like me.  The book will be a lot better for it when it finally comes out.  In the meantime, I hope you enjoy the visualizations!

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!

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.

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!

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.