Jeff Croft

I’m a product designer in Seattle, WA. I recently worked at Simply Measured, and previously co-founded Lendle.

Some of my past clients include Facebook, Microsoft, Yahoo, and the University of Washington.

I’ve authored two books on web and interactive design and spoken at dozens of conferences around the world.

I’m currently accepting contract work and considering full-time opportunities.

Filter content

Items tagged webstandards

  • Blog entry // 08.02.2010 // 1:09 PM // 44 Comments

    On the term “HTML5

    Yesterday, Jeffrey Zeldman linked up a very cool project entitled It’s very well-done, and incredibly useful. You should check it out.

    Today, the always-insightful Tantek Çelik responded to Jeffrey’s post, accurately noting that many of the items the so-called “HTML5 Test” was checking are not actually part of the HTML5 specification at all (for example, Microdata, Geolocation, and more.) Tantek goes on to say, “We as a community that is learning/relearning/teaching all this stuff need to vigilantly clarify what’s what rather than calling things “HTML5? that are not actually HTML5.”

    I say: Why?

  • Blog entry // 09.30.2008 // 4:39 PM // 82 Comments

    When can we stop talking about “supporting” certain browsers?

    Even at a progressive, Web Standards-friendly agency like Blue Flavor, the topic of which browsers to “support” comes up. Clients ask us, “Will our site be supported by IE6?,” for example. And even in the Web Standards community, there’s still a lot of talk about “dropping support” for IE6, and the like.

    But doesn’t this whole idea of browser “support” kind of go against what Web Standards is all about in the first place? Because of the way we build sites (and by we, I mean me, Blue Flavor, and most readers of this site), our projects inherently “support” every browser, from Lynx to Mosaic 1.0 to Netscape to IE to Safari to the no-name browser on your crappy flip phone.

    And yet, we still talk about browser “support.” What we really mean when we ask if a site will “support,” say, IE6, is “will the site look the same in IE6 as it does in the latest and greatest browser?” But we all know this is a silly question. Of course it won’t. And what’s more, it shouldn’t.

  • Blog entry // 09.11.2008 // 8:43 PM // 136 Comments

    Two thousand twenty two

    Today, it was brought to my attention that HTML 5 Editor Ian Hickson, in an August 27 interview with TechRepublic outlined a timetable for the “new” spec, which began life back in 2003. Hixie suggests HTML 5 will reach the “Proposed Recommendation” stage sometime in 2022. Go ahead, read it again. It’s not a typo. Two thousand twenty two.

    I immediately stopped reading. Didn’t even bother with the rest of the interview. Why? Because it just doesn’t matter. The whole concept of web standards, which I once strongly advocated for, has now become so incredibly ridiculous as to be not even worth the time and attention of serious web designers and developers.

    As I pointed out on Twitter today (much to the dismay of certain standardistas, who have previously asked me to name names instead of referring to a “shadowy cabal”): it ultimately doesn’t matter if HTML 5 is available next month, next year, or fifty years from now. Those of us who do real work in this industry know that the only thing that really matters is what specs and technologies are supported by the browsers real people use.

  • Blog entry // 05.07.2008 // 8:51 PM // 18 Comments

    Boagworld interview

    The wonderful Paul Boag from Headscape interviewed me for the latest episode of Boagworld, almost certainly the best web design podcast on the planet. We talk about my “controversial” views on web standards, Blueprint CSS, and more.

    Unfortunately, I hate my voice, and it sounds even worse when propped up against Paul’s sexy British accent. Oh well — I think it came off pretty decent, anyhow.

  • Blog entry // 02.24.2008 // 8:24 PM // 94 Comments

    Your markup validator

    Your markup validator, whether it’s the one on the W3C site or one built into your favorite coding tool, is a debugging tool. It should be used as such. Its job is to find errors in your code, so that you can fix them (or at least be aware of them).

    Your markup validator, whether it’s the one on the W3C site or one built into your favorite coding tool, is not a measuring stick for greatness. It’s not to be used on other people’s code for the purpose of pointing out their shortcomings as a markup coder so that you can make yourself feel better than them. The fact that your code passes a validator does not make it better than the next guy’s code. There is almost never a good reason for you to be validating someone else’s code. Usually, if you’re validating someone else’s code, it’s because you’re being an asshole.

By content type
Other tags in these items