Featuring Remy Sharp, Tantek Celik and Bruce Lawson, today’s comic would make the perfect premise for a sitcom. I think “Three Developers and a Squirrel” would have a very nice ring to it. The comic also looks at the stinky mess we’re going to put ourselves into if we fail to recognize the problems of the past so that we can avoid repeating them.

In a move that threatens to undo over a decade of hard work to drag web development out of the horrors of the “Great Browser War” and educate developers to make forward-compatible, standards-compliant websites, the CSS Working Group recently discussed the idea of all browsers adopting -webkit CSS properties. Yep, you heard that right. IE, Opera, Firefox… all using -webkit properties.

This step appears to be intended to guarantee that their browsers will properly render websites being made by short-sighted developers who only bother using -webkit properties for advanced and experimental features in their websites even when the other browsers have their own test implementations such as -o, -moz and -ie.

Short version: They’re considering giving up and handing the browsers of the world over to a bunch of standards-blind morons for short term compatibility gains in exchange for long term problems that will make the current version of Webkit be the IE6 of tomorrow.

I’m not a member of the old guard. In the nineties I was in high school and pretending to be in college while making personal websites that were just short of visually hideous but definitely counted as nauseating. I didn’t know better. But thanks to the efforts of too many dedicated and educating web developers to name I was exposed to the concept of “web standards” and went about the process of learning how to do things properly.

I also landed a sweet job at Mindfly and became a member of the professional web world. All thanks to web standards.

As someone who’s been working on websites professionally for the past five years I’ve had my share of struggles with IE6 compatibility. I hate that browser more than I hate most other things on the planet. Intellectually I know it was the bee’s knees in its era. I don’t care. Its era was a long time ago and being forced to keep sites compatible with it due to the lack of standards in its era is a direct cause of hundreds of hours of suffering on my part. I’m grateful that it is now all but extinct, letting me concentrate on dealing with modern or near-modern browsers with a lot less cussing, sweating and crying.

As it stands now, Webkit is a pretty decent browser engine. Chrome is snappy. I like it. I’m using it right this second. But it’s also only as good as it is today. If we stop bothering to properly style our websites with a forwards-compatible approach, using all available browser extensions for experimental properties as well as the non-extension version of the properties for when they becomes available, then we’re daft. We will be putting ourselves at risk of making today’s Webkit the rotting zombie in the room that we’ll be screaming at in terror ten years from now. We, or developers after us, will be wasting countless hours and drinking more heavily in response to dealing with thousands of poorly-made websites that require compatibility with the -webkit properties we shortsightedly hung everything upon.

We need to stop this.

Need more information? Need inspiration on how to help? Lucky for you I’ve got a list:

• Read Daniel Glazman’s Call For Action. He’s co-chair of the CSS Working Group, and he knows that this is a very bad thing that needs to be stopped. He even suggests how to do it.
• Also read Remy Sharp’s article on the topic and his suggestions on how to help.
• Take direct action and help Chris Heilmann Pre-fix the Web, rooting out Github projects that have gone down the dark side and get them forked back into the light.
• Get Bruce Lawson’s perspective on the vendor prefix issue, taking advantage of the wisdom he’s gained in trying to educate against this exact sort of problem. Also see the first reference of the dreaded vindaloo fart.
• And please read Eric Meyer’s pessimistic, but perhaps realistic, assessment of the issue in Unfixed.

Whatever you do, don’t be apathetic. Don’t think to yourself that -webkit only sites are professional or even remotely acceptable. Because they’re not. It takes very little effort to guarantee forward-looking, cross-browser websites with the vast majority of most modern CSS properties. Doing anything less for the sake of ease is lazy, unprofessional, and going to cost someone a lot of money and effort in the future.

If you do decide to only use -webkit prefixes, watch out, because Bruce Lawson will vindaloo fart on you.

Edit: Roughly twenty minutes after I posted this, the W3C took action on the issue, insisting that the <time> element be placed back into the specification. You can read about it here. But please read on. It’s a good primer for the next time something like this happens.

Contrary to what you may have already heard, the <time> element hasn’t disappeared from HTML.

Yes, officially <time> is currently not part of the HTML spec. (Thanks to the muddle that is “HTML Living Specification” I’ll be honest and admit I’m not sure if is no longer part of HTML5 or it’s in some sort of Schrodinger’s Cat quantum-zombie state of existing in HTML5 but missing in the “ongoing HTML” that the WHATWG is proud to keep rolling down the conveyor belt.)

That doesn’t mean it’s not being used by authors (how’s Drupal builds, 2.6 million WordPress installs and the Boston Globe for you?) nor does it mean that is it not being used by user agents (ever-plucky Opera supports it).

What it means is that a single human being has decided that he doesn’t care for time one wit, and that a rather vague element called <data> can replace it instead.

This human is none other than Ian “The Benign Leviathan Dictator For Life” Hixie, editor for the HTML specification.

I could give you an explanation on how this scenario came to exist, but two Brits who are far more informed than I am (and likely slightly smarter) have made their own summaries. If you like knowing what’s going on (and I do) then go read them. These pair of fine gentlemen, Jeremy Keith and Bruce Lawson, both guest star in today’s comic as the good Doctor thanks to a little spot of regeneration, where they’re fighting the good fight against Hixie’s <data>leks.

Virtually every problem I have with a single person wielding so much power over such a fundamentally important pillar of the web as HTML can be summed up in this incident. <Time> is officially out, despite the lack of merit or consensus in that decision. And it took just one man to make that happen. Either through a lack of awareness or a genuine disregard for what authors are already doing, Ian has claimed incorrectly that <time> isn’t seeing adoption, isn’t useful, and should be canned. And because the only balance to his power is a rather tedious process to oust him, there’s no official remedy to bringing <time> back into the HTML fold than trying to convince him that its existence is a good thing.

From what I understand, it’s easier to keep red shirts alive on away missions than it is to change Ian’s opinion on something.

Fortunately, there’s a big difference between having no official remedy and having no remedy whatsoever.

As “authors”, we are the 99% of HTML5. We can follow Jeremy Keith’s sage advice:

We can make a stand and simply carry on using the time element in our web pages. If we do, then we’ll see more parsers and browsers implementing support for the time element. The fact that our documentation has been ripped away makes this trickier but it’s such a demonstrably useful addition to HTML that we cannot afford to throw it away based on the faulty logic of one person.

So as I said, <time> hasn’t disappeared from HTML. It’s still there on millions of sites already. And nothing is stopping us from putting it on millions more. It’s our chance to send those <data>leks packing. As soon as this post is finished I’m going to edit my site’s theme to make use of <time>. Hixie can go stuff it.

Occupy HTML5.

Today the W3C unveiled its new logo for HTML5. As you might notice, it’s quite fancy.

The site’s pretty slick, as well.

Today’s comic relates to this new logo, in a roundabout way, featuring Jeremy Keith, Bruce Lawson (or perhaps it’s Super Bruce) and Remy Sharp (Or is it SuperHTML5Rem?) in their guises as HTML5 Super Friends, attempting to save the web from itself. It also refers to a slippery terminology slope.

The FAQ page for the new logo (yes, it gets its own FAQ) includes a little mention about what the logo represents. Which is obvious: HTML5, right? Well, apparently HTML5 doesn’t stand for Hyper Text Markup Language anymore. But apparently its all for “a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.”

Say what? I’m with Jeremy and Bruce on this one. The logo is pretty, but the intentional use of HTML5 as a blanket term for other modern web technologies is a crock. Newspapers making merry with the term is one thing, but a web standards organization? We rely on these groups to keep our handy developer toys in nice, cleanly demarcated buckets so that we can easily educate ourselves and the next generation of developers on what toy is used for what job and how.

I could rant on this for hours. But I recommend reading at minimum Jeremy’s bit on the topic. He manages to be far more eloquent with his words and has earned his place as a bit of an authority on the topic. So maybe you’ll value his two cents more highly. All I know is that when I used to say “HTML5″ people knew what I meant. At least in my own community of website creators. But now it’s as meaningless as “doohicky.” As in, “Are you talking about the doohicky that I style pages with or the doohicky that I make the structure with?”

TL;DR Version: Love the logo, hate the term-squishing.

As a parting shot, I object to Karl Dubost’s characterization of term-blurring opponents’ commentary as “vapid“. I’m sure Jeremy Keith is capable of a lot of things when writing, but even if you disagree with his viewpoint on the topic, his well reasoned rhetoric doesn’t merit such a label. Shame on you, Karl.

Next week we’ll be concluding my AEA stoyline. Today’s comic, a continuity-free interlude, features Opera Mini. I should say, rather, that it features Opera Mini if it were a moose instead of a browser installed on hand-held devices. A short moose. A midget moose with some sort of glandular problem.

I hope you’re able to follow the metaphor I’ve created, as I don’t think I can devise another way to repeat what I just said above.

Frequent readers may be aware of the fact that I have not been too kind to Opera in the past. Typically, these tussles have dealt with how they’ve handled conflicts with certain competitors. Today, it’s a different story.

What Matters With Mobile: Speed

I own an iPhone, a device that comes pre-installed with Mobile Safari. Safari is a great modern browser that renders most (non-Flash) websites beautifully and accurately. And when I’ve got a decently strong connection, it even does it in a time-frame approaching (but not reaching) quickly.

The fact is however that my phone’s provider is AT&T. And when I’m at home, my WiFi access is through Comcast. Despite their many bold claims and lovely commercials stating otherwise, neither vendor provides what I’m going to refer to as a fast connection. Quite the opposite, I’m positive that there are several times in any given day where a 28.8k modem would more quickly deliver me the information I am seeking to consume.

Tell me, why as a society is it acceptable to charge people for a speed that they might, but usually won’t, receive from any given service, rather than the speed that they actually are receiving?

Regardless, these modern day robber barons aren’t making my service any better anytime sooner, so experiencing the web through Safari on my iPhone is similar to experiencing a milkshake through one of those really tiny coffee stirring straws. Yes, sooner or later you’ll get the shake, but it’s not exactly at a speed that’s enjoyable.

This is where Opera Mini comes in. Yes, it’s a less-capable browser in the rendering sense. But if I want to wait for a minute or longer per page, I can certainly do so for my rounded corners. Usually when I’m on a mobile browser, I want data quickly. Very quickly. So Opera Mini serves me just fine. Better than fine, in fact. It’s very fast. Which makes surfing the web effortless again. Which I dare say is how it is supposed to feel.

Addendum: Privacy & Security

A few days back, I made the following pro-Mini tweet: “Speed matters. Especially on mobile. And that is exactly why I’m using Opera Mini more than Safari, despite the rendering deficiencies.”

Ben Adida offered the following question as a counter: “Does privacy matter? Cause Opera Mini proxies all of your connections, even SSL, via its servers.” It’s a valid question, especially considering his expertise in the field of privacy and security. Not being an expert on how Opera does things, I poked at both Bruce Lawson and Molly Holzschlag, both Opera employees.

Both of them said “If you don’t trust us (Opera), then don’t use the service,” and then each followed up with more details.

Molly backed up the security conversation with this gem: “Regarding proxy serving in Opera Mini? We are a public company in Norway, which has some of the most stringent privacy rules.” as well as the very honest tweet: “As such if you cannot trust based on the integrity of a product or its company, no matter who, then don’t use that product!”

Well said.

Bruce gave us reasons to trust Opera with two security-related links. First, he indicated that Opera Mini is actually more secure on public WiFi than other browsers (with this link to back his claim) as well as linking to a post about how well Opera scored with security according to Symantec (here’s the abridged version: very well.)

So is Opera Mini fast? Yes. Is it secure? Yes.

That’ll do, moose. That’ll do.

Today’s comic does not precisely plumb the depths of the web standards world. There’s no CSS compatibility joke, no HTML5 politics, and not even a dig at Opera. Which, I know, is a major drag for you all.

It serves two purposes. The first is to look back at the fun I had participating in SitePoint’s podcast “HTML5 is a (Beautiful) Mess“, and pay homage to the gentlemen I had the pleasure to speak with: Canadian Kevin Yank (as one of the fellow speakers put it, is there a Kevin Canuk in the US somewhere?) and Brits Ian Lloyd & Bruce Lawson. Such fun, idyllic moments like debating HTML5′s wrecked politics are too delightful to go unchronicled.

The other purpose relates to Kevin’s first joke in the podcast. He asserts (falsely) that we’ve gathered to discuss the recent troubles plaguing NBC’s late night line up, in particular the Leno vs O’Brien issues of the Tonight Show. This joke threw Ian and Bruce, who aren’t plagued daily with American late night talk shows, but it sparked in me the remembrance of a tweet I once received from one @GeekGamerGirl that made my heart sparkle: CSSquirrel is The Daily Show for web designers. Don’t stop, we need you to make up for all the bitchy little girls out there.

So today’s comic is more of an announcement. I am in the process of devising a “late night” talk show that the Squirrel will host, featuring interviews with cartoon representations of various web designers/developers/standardistas. It’ll draw from the mighty traditions of the Tonight Show, The Daily Show and Space Ghost: Coast to Coast, and in theory will be a plug-in free experience brought to you in part by HTML5, JavaScript and vector tree-climbing rodents.

So, screw Leno or Coco. I’m with Squirrel. (For those who miss the reference in the last panel, it’s a play on the “I’m With Coco” badge by artist Mike Mitchell).

Yes, the shameless self-promotion is concluded. Enjoy your day.