Today’s comic is one of those little jabs at everyone’s favorite European browser maker. I’ve got issues with Opera that this comic makes light of (while wishing squirrel snogger and Opera employee Bruce Lawson a belated happy birthday). Yes, Opera is a far smoother experience for modern web features than Internet Explorer. That’s not in question. But I’m getting a bit exhausted by the relatively slow adoption speed of CSS3 features by the browser in comparison to the increasingly popular Firefox and Webkit-based browsers.

Rounded corners are, admittedly, largely a non-issue. If visitors using Opera get square corners in a design, I’ve taken steps to ensure it’s at least a good looking square design. It’s an example, though, of a slew of features that Opera’s failing to keep pace with. Due to this lack of universal browser support (in the modern browsers, at least), It is hard for me to sell adoption of these designs to clients when roughly 1% of a customer’s visitors are getting a bad experience as a result.

Take for example, Jonathan Snook’s text-rotation tutorial. It provides a way (via filters) to get even IE to come to the ballgame with producing vertically-oriented text. Everyone, except Opera, can play with this toy. Even if IE couldn’t, thanks to conditional comments, I could provide a fallback solution for that browser. But as Opera lacks such (and I’m not recommending they adopt conditional comments), there’s no way with just CSS to provide an acceptable fallback that makes the browser not create something hideous with the text out of place. (I’ve concocted a JS-based solution, but I don’t want to have to rely on that to get CSS to work).

Opera’s not alone in the modern browser category in being the last to adopt a given feature (I’m looking at you, Firefox), but there’s definitely a lot of seemingly basic CSS3 techniques that the browser’s fallen behind on. Just because you can wait on adoption, gents, doesn’t mean you need to do so. The future isn’t coming any more slowly, and designers will have to jury rig solutions that would be solved much more cleanly with CSS if you’d keep pace.

Or, even worse, there could be more situations such as when I’ve suggested to some people who’s sites don’t have any notable Opera traffic that they just not sweat Opera support at all. With as small a market base as you have, it’d serve you better to keep pace (rather than not sweat the details, as Microsoft can afford due to its market share).

Curious about a browser’s support for various features? Check out When Can I Use.

Go ahead and take a look for yourselves.

I’d think that this was just me overreacting, but when I tweeted on Sunday about my thoughts on the drama in the lists, I got a number of responses that illustrate that I’m not alone in my perception.

Jin Yang indicated that popcorn was a good snack while watching the drama unfold. After I made a bar brawl analogy, David Peterson suggested that whiskey might help them calm down, and that his two year old has progressed farther in the manners department. John Foliot provided some perspective sharing that this “us & them” mentality is a relatively new thing. And Manu Sporny joked that the W3C and WHAT WG originated as community theater groups.

Naturally, his joke was comedy, not fact. But I couldn’t help but think, what if…? So today’s comic portrays Manu Sporny and the Squirrel attending a fateful showing of Our American Cousin.

I want to say that I do see a lot of polite dialogue in the lists. I’m just amazed at how much bad behavior (sometimes well dressed, mind you) makes it into the discussions. Here’s hoping the good outweighs the bad by the time Last Call rolls around.

(As a closing note, I like the term Dundrearyisms.)

Let’s review the facts.

Ian Hickson, editor of the HTML5 spec and top dog of the WHAT WG, is an employee of Google. He also adheres to a policy when dealing with people that can be summed up as: Deny, Delay, Too Late.

It can be argued that HTML5 is an important upgrade to one of the most vital technologies of the 21st century. Billions of people are using the Internet to facilitate communication and business, share their culture, access otherwise censored information when living under harsh regimes, and so forth. Most of the sites they use for these purposes are built in some fashion upon HTML.

At the currently accelerating rate of content creation, it’s safe to say that billions of pages will be built with HTML5. How these pages are designed, and how they’ll meet the needs of people both in the present and in the future rest upon how this standard is outlined. Everything from preserving the portability of microdata, ensuring the accessibility of web users with special needs, and finding ways to share media without the hassle of brand-specific plugin wars (anyone seen a flash site on an iPhone yet?) are determined by this effort.

So why is it that the person who is the center of this process is allowed to be a man who rejects consensus, actively denies issues (based on his own admitted policy) and substitutes expert advice in important areas like accessibility with analyzing data from the Google Index and parsing numbers? Numbers that we cannot have a third party confirm because every request to do just this is ignored?

There is no doubt in my mind that Ian is brilliant. However no man, no matter how brilliant, should be allowed to be so influential on a spec when he is bringing all this baggage to the table with him.

The biggest problem for me is as follows: Google. Ian’s work is highly influenced by data harvested by Google. I am positive Google has some spectacular views of the web, resulting in some highly accurate views of the current state of the Internet. I’m also sure that this doesn’t matter one bit if we have to take their word for it, because we can’t view it ourselves.

Most people search the web through Google. I get mail through Google, site analytics through Google, news through Google, and sometimes even browse with a browser used by Google. It’s impossible to throw a rock at the Internet and not somehow hit Google. It’s to the point where even the US government is getting a bit itchy and considering taking antitrust actions against them.

I don’t want to sound paranoid, but perhaps we shouldn’t craft HTML5 solely on Google’s say-so. If the data-harvesting Ian performs can’t be independently verified, then perhaps we shouldn’t accept it as fact. It’s just not prudent. We definitely shouldn’t use it as a substitute for actual experts in discussions like accessibility (which I spoke about last week). If Ian can’t accept that limitation or provide access to the raw data, then we need to consider whether a conflict of interests exists and whether he should remain as the editor. With him doing such a poor job of playing well with others (whether they be individuals, experts, or other WC3 working groups) while relying on private information from his employer, how can he be expected to create a HTML5 that meets not just his needs, or Google’s needs, but everyone’s needs?

I’m not convinced he can.

(For those of you from hotter climes, I’m aware how weak this must seem. My town of origin, Redding, CA, easily tops 110 during the height of summer. However, it’s really hot compared to the local average.)

So perhaps I was suffering from heat stroke when I thought I heard a co-worker championing in conversation the use of blue, underlined text for all hyperlinks on all web sites. Anything else, they assured, was difficult, if not impossible, for your average Internet user to see or use. Without the vibrant blue (always backed up by purple for visited links) and the noble underline, these commoners of the web would be lost, incapable of navigating from page to page.

Balderdash. Poppy cock. Bullcrap. Etc.

Somewhere near the dawn of time, when the World Wide Web was a mewling infant homunculus suckling at the breast of Sir Timothy Berners-Lee, I’m sure all twelve people capable of browsing the twenty pages available on the web were barely able to comprehend the idea of a hyperlink. Blue, underlined text on a stark white background was likely the only thing saving their minds from imploding in horror at the thought of some elder gods prowling the phone lines and dragging their souls through the 14.4k modems they’d spent hundreds of dollars to purchase.

I’m positive, however, that in the years since then that the average netizen has come to expect a richer media experience. They may have even “tweeted” (and giggled when it first happened) about a funny thing they saw, and uploaded a picture from their phone of this very event. They’ve watched cats play on pianos via YouTube and wept in silent awe as they realized that they lived in the best of possible worlds.

If a hyperlink had the audacity to be a shade of orange, I think they might just be able to pick it out of the surrounding text enough to click on it. If, instead, the bright blue links were bold instead of underlined (on a page where only links received such treatment) users of the web just might posses the ability to tell that clicking on aforementioned text would result in them navigating to a new page instead of providing them with a can of tuna.

I choose to believe this because I have the honesty to admit that most people are in fact not total idiots. Yes, we wail and gnash our teeth at trying to help clients understand what a paragraph tag is. Sure, we’re hard-pressed to not swallow our own tongues when explaining for the fifth time to our grandparents how to send email. But to claim that there is only one way to mark a hyperlink in a way that a peer of the web is capable of recognizing is exactly like saying that every non-developer is a complete moron who is incapable of telling that a peach is a fruit because it doesn’t look exactly like an apple.

Today’s comic places Jakob Nielsen in a hypothetical scenario that illustrates my disdain of the position that he’s advocated in the past on this issue: If you want it to be usable, it needs to be blue (or purple if visited) and underlined. Period.

There’s a special kind of hubris associated with this sort of statement. I’ll accept that blue, underlined hyperlinks are easy to spot. I’m also going to say that green, underlined hyperlinks (on a page that lacks green, underlined text elsewhere) would also work as effectively. Or perhaps blue, bold text. I’m guessing that underlines generally help, but I think ultimately any combination of highly visible traits that exist only on the link text and stand out from the non-link text is going to do the job.

Why does this issue rile me up so badly? Because I’m tired of old wives tales of Internet wisdom on how a page must be made. Especially when these limit our ability to explore the cornucopia of designs or features that we can make on the modern web. Such wives tales that annoy me include:

“Your site’s content? Well, it’d better be short, because people won’t read long texts on a screen.” Tell that Amazon as they laugh like madmen while they sell Kindles like hotcakes.

“Text needs to be near-black on a white background.” Right, except when the opposite is easier on the eyes for certain applications (like Mozilla’s online editor Bespin.)

Someone’s going to be a wit and jump on the fact that this site’s links are blue and underlined. I chose the color because it matches the sky in the header, and I liked the feel I got from tying that color into the rest of the site. But take a look at Twitter or YouTube and tell me that you can’t find the links even though they lack underlines. Go to Apple’s site and tell me the menu isn’t clearly a menu even though it’s not blue. A well conceived design can communicate to the “average” person without having to assume it’s being used by idiots.

The web has grown up. Its users are growing with it. Let’s put aside the juice boxes and start treating them like adults.

Chris Wilson (W3C HTML WG co-chair and Microsoft employee) posted an e-mail to a HTML5 discussion that made reference to the “W3C HTML5 Spec”.

Mark Pilgrim (Google employee and WHATWG Blog author) in the WHATWG IRC channel then implies that HTML WG co-chair Sam Ruby would have been attempting to be divisive had he written that e-mail, but since it came from the other chair, Chris, he was in fact being stupid.

Shelley Powers (computer book author, software developer and technology architect) expresses utter frustration in a blog post about the future of HTML5 by pointing out this incident and many others that indicates a “Hatfield-McCoy feud” (in her words) between the W3C and WhatWG that is miring the whole process down. Gems in her post include an IRC discussion (starts here, ends here) between HTML5 editor Ian Hickson and Microformats champion Tantek Celik where Ian shows his bias in the microdata issue (read that: whether to include RDFa in HTML5) by asking Tantek to vet the use-case submissions. The “vetting” quickly devolves to the pair saying “Use microformats for everything” or if such a situation isn’t possible, to simply create a custom microformat for your own use.

Yes, that’s it, let’s make dozens of one-shot formats to solve the many microdata issues we’ll doubtlessly be facing in the next several years. That can’t possibly create any sort of data-harvesting compatibility issues. If I can see the shortsightedness of this issue (and I fail to wear coats on cloudy days because “it’s not raining yet”) then you can bet this isn’t a tenable, long-term solution.

They take some time to attack Creative Commons while they’re at it.

These aren’t the only times these sort of offensive public conversations have occurred, where WhatWG members have publicly derided, insulted or challenged the intelligence of the individuals they’re politely talking to in other conversations about topics they’re mutually involved in (such as HTML5). Mr. Last Week in HTML5 is a great (albeit foul-mouthed and somewhat spiteful) source of links to these conversations occurring all the time.

Ian responded to Shelley’s post, taking umbrage (as Shelley put it) at her “insulting accusation”. Shelley’s response cut to the core of the matter, exposing the main issue at hand here, and one that needs some serious addressing. In her words: “Don’t you get it? Don’t you see what Last Week in HTML5 is trying to demonstrate? You talk respect in my comments, or Sam’s comments, and elsewhere, but you show disrespect to me, to Sam, to others, in the IRC, and it completely undermines everything that you do. ”

I can’t state it better. These people aren’t average developers trading insults about trivial code snippets on small-scale projects. These are industry movers-and-shakers who are supposed to be working together to help create the standards that will define how we use HTML and other web technologies for years to come. I expect professional disagreement to occur (I’d be worried and concerned if that didn’t happen). But to start insulting one another personally in a public discussion (or frankly, privately) is shameful to the entire process and the entire community that is depending on them to do a good job.

Shame on you, sirs.

I’ll leave you with the following quotes from this IRC discussion including Doug Schepers, Ian Hickson, and a person named ‘roc’ (I don’t know his real name) [edit: As I've been informed in the comments, roc is Mozilla's Robert O'Callahan]:

shepazutoo (Doug): wow, Hixie, “contradicting other specs has never stopped the SVGWG before” (q.v. xlink, css, etc)… first, those were almost certainly mistakes rather than purposeful contradictions, and second, you’re acting like the current SVG WG is the same set of companies and individuals that wrote the SVG 1.1 spec, which you know to be false… can you please drop the political histrionics? we’re acting in good faith to correct some past errors, and to work with other WGs and with browser vendors to make all the specs align usefully

Hixie (Ian): i think you may have missed the smiley

roc (Robert): a smiley is not a “get out of jail free card” to be annoying

What is the password anti-pattern? In short, it’s the behavior of teaching people that it is safe to enter their password information from one website on a different website. In the modern digital world of phishing attacks and identity theft, it’s a very dangerous habit to help people form.

How dangerous? Well, how attached are you to your personal information?

The specific issue that Jeremy is bringing up involves the “Twitter this” widget that Get Satisfaction has on their site. By entering your username and password for Twitter, you can re-tweet the topic or page that you’re located on for your Twitter followers to see.

The behavior may seem innocent enough on the surface to you all. After all, you’re initiating the tweeting that occurs, and Get Satisfaction has a certain reputation of trustworthiness. Also, what harm exists in giving out your Twitter info?

Well, there’s a number of issues. First, the folks at GS don’t need your login information in order to provide this function. There’s other ways to do it (Jeremy suggests one in his post on the topic). Secondly, some people have a tendency (bad though it may be) to recycle usernames and passwords, so their Twitter login may match their bank’s login, or something of equal importance. Lastly, behaviors can be habit-forming, and even if GS isn’t going to do anything harmful with your info, some other site later down the road might, so it’s very poor form to be teaching someone that it’s safe to do something that could cost them their identity or money.

So it shouldn’t be surprising that there’s a lot of developers out there like Jeremy that are against this bad practice. What is surprising in this case is that many of the Get Satisfaction employee responses to this issue was to push back against the suggestion that they change their approach? With arguments ranging from “we’re not full of thousands of developers” to “It’s just Twitter, not your bank,” many of them (granted, not all) seem to have missed the point altogether.

The anti-pattern is bad because it teaches bad behavior. Period. It helps form a habit that will eventually cost end-users their identity if they continue it. As a website devoted to user satisfaction, it is shocking that they wouldn’t grasp this concept and embrace it.

If you make a website, you have a responsibility to your users not to screw them, directly or indirectly, with this sort of design “feature.” Either work around it (as Jeremy Keith suggests to GS in this case), or eliminate the feature altogether if you can’t work without it. Our identities are getting increasingly digital as the seconds pass, and it’s sheer folly to be helping people commit virtual suicide.

After all, the road to Hell is paved with…

Jeff Croft noticed something in the article that stoked his ire (warning: naughty language).

What about HTML5 could be provocative?

It’s Ian’s timetable for the specification, which started in 2003 and he hopes to have finished by 2022.

No, that’s not a typo. For those of you with mathematics disorders, that’s nineteen years total, with the whole shebang completed fourteen years from now.

I’ll be forty-five.

I’m sorry, but that’s bananas! I don’t care that the last ten years of that schedule is debug/feedback time. I find it inconceivable to think that something else wouldn’t have come along by then, rendering HTML5 irrelevant, as today’s comic posits.

Fourteen years ago the best way to view the web was Mosaic. Remember that?

I do. From high school. I was also playing video games on the Super Nintendo and Lucasarts was producing games that didn’t just involve Indiana Jones or Jar Jar Binks.

A Star Wars prequel trilogy still seemed like a good idea back then.

The fact is that with the pace of software and hardware innovation it seems absurd to assume anything about what the web will be like in another fourteen years. I hope that HTML is a memory by the time 2022 rolls around, replaced by something exciting and unexpected that turns the Internet upside down in the same way the WWW did when it was first conceived. Despite all the foot dragging that software giants have caused in the implementation of standards in the past several years, we can’t allow ourselves to grow complacent and assume that we’ll be using the same playbook after enough time has passed for America to finally get off its lazy butt and return to the moon.

Like Croft says in his post, specs aren’t a bad thing. However, I agree with him that it’s definitely absurd to assume that HTML5 will be relevant by the time they hit the end of their projected road.

I’m excited for HTML5, but by the time they put the stamp ‘done’ on it, I predict it’ll be an artifact of Internet history. But then, that seems to be how the W3C works, rather than creating standards they’re just putting the seal of approval on what’s already happened.

That said, some wit has made a convenient countdown clock for those of you that want to keep dibs on the spec’s progress.

As I was crafting a response, I discovered that I had more to say on the topic than could be rationally contained in a simple comment.

First, some facts: I don’t dislike Opera. I dislike hypocrisy. Also, I don’t like Internet Explorer. I hate Internet Explorer, and I would prefer to see Microsoft adhere to modern web standards with the same fervor as the other major browser makers.

However, the responses to my earlier posts made by Opera employees and by others on behalf of the browser maker, amount to the following two statements.

1. Microsoft needs to adhere to Mr. Lie’s list of rules they should play by because Microsoft is a monopoly. Opera does not need to do this because it is not.

2. Opera is justified in delaying implementations of “new” features because they’re focusing on backwards compatibility and not breaking the web.

Each is interesting, but ultimately unconvincing.

First, I don’t believe that implementing web standards and new site features is solely the responsibility of a company that is a monopoly. In his well publicized list of rules for Microsoft, Mr. Lie agrees with me. I’ve already quoted the fifth point (relating to adding a new standards-related feature to a browser if two major browsers have already implemented it), and have pointed out useful features that at least two browsers have implemented that aren’t live yet on Opera. I want to emphasize where Mr. Lie states these rules aren’t just for Opera:

“Microsoft will surely claim that it’s impossible for them to develop a browser that complies with the proposed requirements. However, other browsers have played by these rules for years. If Microsoft can’t live up to the standards of the web, I suggest they leave the browser business.”

His assertions are twofold, first that other browser makers do play by these rules (including Opera I presume, which exclusively makes a browser), and that failure to adhere by these rules is enough reason for a company to leave the browser business.

I agree with him completely. I find it comical that some of Opera’s employees apparently do not, and have yet to hear a compelling argument as to why they should be disregarding their CTO’s wisdom. This ties directly into point #2, which is that implementation of new features must be delayed as a necessary sacrifice to maintain backwards compatibility and not break the old web.

Backwards compatibility with the soccer mom-built sites of the world is the same boogeyman that Microsoft has been waving on a flagpole since at least Internet Explorer 6. The world of web developers have yet to give Microsoft any mercy for that, and often cry for blood when feature implementation or standards compatibility is sacrificed on that altar (such as the well documented IE8 meta-tag explosion). I’ve yet to hear a compelling argument as to why any smaller browser maker can justify their own delays at implementing “new” stuff with the same smoke and mirrors and not deserve the same treatment.

In the end, the simple fact is this: I expect better of Opera. I expect them to be better than Microsoft. This means I’m not going to accept Opera using the same excuses as Microsoft, and somehow get away with it due to their size.

So, chop chop. Back to the grindstone, boys.