Posts from February 2012

The moment I hit “Publish” on this post, I will have crossed a major base-ten barrier:  this is the one thousandth post published here on meyerweb.  When I started putting up little missives back in December 1999, the idea was to communicate with my friends and family about what was going on in my life, and to maybe open a dialogue with the few people I hoped might read the forthcoming Cascading Style Sheets: The Definitive Guide.    (We expanded the acronym CSS in the title for fear potential readers might not know what “CSS” stood for — a legitimate concern back in 2000!)  Posts were written in the first-person plural, of all things, and there were no comments or search.  In fact, the whole thing was an unholy agglomeration of XML, XSLT, and shell scripts that somehow spit out HTML into quarterly archive pages — in chronological order, I’ll have you know.

Years later, I migrated to WordPress (mostly because I knew Matt personally, back before he started hobnobbing with Richard Branson and storing fruit in Louis Armstrong’s trumpet and all that), turned on comments, and never looked back.  As more and more sites have disabled commenting, I’ve left that door open and have yet to regret it.  Curating the comments has become easier to manage in the last few years as the number of comments per post has dropped, but I still believe it’s a worthwhile effort.  I was never here simply to talk; a good conversation beats a great soliloquy any day of the week.

It’s also true that, as my life has gotten more complex and my responsibilities have grown, my frequency of posting has dropped in the last few years (I believe that’s at least part of the reason for the drop in comments).  Speaking at an increasing number of conferences, founding and developing An Event Apart with Jeffrey, taking our family’s size from two to five, and trying (trying!) to keep up with the inbox and friends online — all ate into my blogging time.  I allowed it to happen, of course, in the most natural and unconscious way possible: I simply didn’t focus on blogging.  A lot of my focus I let flow into watching social networks stream crumbs of information past me, and occasionally tossing in my own crumbs, partly just to see where they flowed.

I will of course continue to put time and energy into An Event Apart and writing and above all my family, but I am reclaiming in the name of blogging the pieces of my attention I ceded to Twitter and Facebook and all that jazz.  This site, in the last 12 years, has (like an old friend) seen me through failure and success, horror and beauty, war and peace, through death and new life and all the things that greet all of us every day.  It deserves more of my focus, and that’s what I have committed to give it.  I’ll be returning to my old mix of technical and personal material, writing about CSS and standards right alongside child-raising and kitchen faucets.  You can follow along via RSS, or if you prefer a patchier approach you can watch for post announcements on Twitter.  Whatever the balance of content, whatever the post topic, I can most definitely assure you that I will continue to abuse parenthetical asides, lead off paragraphs with “Anyway”, employ British-style punctuation rules, and make jokes so obscure only I get them.

Prior to hitting “Publish” on this post, the archive of “Thoughts From Eric” (the official title of the blog portion of meyerweb) contains 400,409 words, according to WP Word Count.  This post contains 608.  Here’s to the next 598,983.

• Adding a Comma, Expanding a Place was published on Wednesday, February 29th, 2012.
• It was assigned to the Personal category.
• There have been five replies.

Published this morning in A List Apart #344: an interview I conducted with Tantek Çelik, web standards lead at Mozilla, on the subject of Mozilla’s plan to honor -webkit- prefixes on some properties in their mobile browser.  Even better: Lea Verou’s Every Time You Call a Proprietary Feature ‘CSS3,’ a Kitten Dies.  Please — think of the kittens!

My hope is that the interview brings clarity to a situation that has suffered from a number of misconceptions.  I do not necessarily hope that you agree with Tantek, nor for that matter do I hope you disagree.  While I did press him on certain points, my goal for the interview was to provide him a chance to supply information, and insight into his position.  If that job was done, then the reader can fairly evaluate the claims and plans presented.  What conclusion they reach is, as ever, up to them.

We’ve learned a lot over the past 15-20 years, but I’m not convinced the lessons have settled in deeply enough.  At any rate, there are interesting times ahead.  If you care at all about the course we chart through them, be involved now.  Discuss.  Deliberate.  Make your own case, or support someone else’s case if they’ve captured your thoughts.  Debate with someone who has a different case to make.  Don’t just sit back and assume everything will work out — for while things usually do work out, they don’t always work out for the best.  Push for the best.

And fix your browser-specific sites already!

• “The Vendor Prefix Predicament” at ALA was published on Tuesday, February 14th, 2012.
• It was assigned to the Browsers, CSS, Standards, W3C, and Web categories.
• There have been two replies.

Right in the middle of AEA Atlanta — which was awesome, I really must say — there were two announcements that stand to invalidate (or at least greatly alter) portions of the talk I delivered.  One, which I believe came out as I was on stage, was the publication of the latest draft of the CSS3 Positioned Layout Module.  We’ll see if it triggers change or not; I haven’t read it yet.

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.

• Unfixed was published on Thursday, February 9th, 2012.
• It was assigned to the Browsers, CSS, Standards, W3C, and Web categories.
• There have been twenty-one replies.