I’m glad that Delicious hasn’t gone the way of the dodo (by all accounts a delicious bird that pirates feasted upon), but I’m annoyed beyond all belief that since I’ve upgraded to Firefox 4 that I can’t make use of the add-on anymore.

Manually going to Delicious and doing the bookmarking directly on the site is like being forced to create mayonnaise by scratch for every sandwich. Somewhere, at some point, you just switch to Miracle Whip.

Gentlemen, I hate Miracle Whip.

Seriously, what’s in that stuff?

Today, like most days, I went to hit the Delicious icon to store a lovely page in the cloud for my perusal later. And today, like every day since Firefox 4, I cursed as I remembered I can’t do that anymore. So I went searching in a futile hunt for an update. It’s been weeks. Surely some Yahoo engineer somewhere fixed it already. Right?

Wrong.

But as fortune has it, someone else shared my distaste for waiting, and was more clever than I. Go here for instructions by James Moss on how to make the add-on work in eight easy steps. Thank you, James. You’ve saved my sanity.

As long as you’re not on a legacy browser, to the left you’ll see an image that is rotated 90 degrees.

If you’re using the current version of Firefox (3.6 as I write this), you’ll also notice a rather unpleasant visual effect on the box-shadow, which isn’t properly surrounding the rotated image like it should be.

I came across this by accident while working on some 2d transforms for a series of photos in a client’s project. I didn’t catch it at first because it only happens somewhere between 82 degrees and 108 degrees (and the direct opposite around 262 degrees to 278 degrees). I might be off by a degree or two, but that’s about the range where the shadow sheers off and snaps down to the picture’s height in its original orientation.

I’ve got a test case here. You’ll note Chrome, Safari, Opera and Internet Explorer (yes, even IE) are doing it right in their current versions. Only Firefox isn’t.

Considering how long Firefox has been implementing transforms in comparison to Internet Explorer (infamous inbred step-child of the browser market), this is really disappointing. It’s details like this that are slowly costing me my love for the flaming-tailed fox.

The bug is fixed in the Firefox 4 beta, thankfully. But that begs the question, how much longer do we need to wait for Firefox 4 to release?

Even if haters can’t admit it out loud, they probably need to admit it to themselves deep down inside: Nine is a contender.

For years, Internet Explorer has been out of the game when it comes to any discussion of what constitutes a modern browser. Version 8, as much as it was a drastic improvement over what had come before, was something I viewed more as a correction of 6 and 7′s many errors, and clearly not an effort towards embracing more modern features.

But Nine? Hardware acceleration. A blazingly fast JavaScript engine. Robust CSS3 support (missing things, but includes a decent chunk of what I wanted to see). HTML5 features like <video>, <audio> and even <canvas>. SVG support. On top of it all it’s got a slick, minimalist interface.

Internet Explorer 9 is a modern browser. Period. Dissenters and naysayers are at best nitpicking and at worse lashing out due to old habit.

There are downsides. I wish that they’d made it for XP, but as Microsoft is in the habit of selling operating systems I understand how complex of an issue that might be for their business model. It doesn’t include all the CSS3 I want to see (gradients, anyone?) but they do give a reasonable-sounding reasoning why (ostensibly, they don’t want to add a feature that has to be changed or removed later, and gradients currently have at least two exclusive syntaxes).

But the bottom line is that although IE9 isn’t perfect, it’s also not the flawed, stunted beast of ill-will and developer-consuming horror that its ancestors were. We, as designers, should be grateful that we’ve got another modern browser making our websites look better (and capable of doing more) without requiring us to craft different code for different browsers.

(But feel free to kvetch about the challenge in getting XP users to upgrade to a modern browser. My opinion on that? Tell them to use Chrome or Opera.)

The Orange, Flaming Elephant In The Room

I don’t, as a rule, use Internet Explorer as my daily browser. After all, I want the whole, real web, and historically it was not the best candidate for that. Now that Nine is out, I’ve found in the past couple days that my tolerance levels for my de facto browser, one Mr. Firefox, is suddenly waning.

Firefox is slow.

Today’s comic makes light of this sad, sad bit of information.

Additionally, when using some newer “HTML5″ JS features (such as localStorage) I’ve found Firefox even locking up on what seems like a quick, trivial task for competitors like Chrome. And the old mainstay of my reason to keep Firefox, the plugins, is no longer as unique a feature as it was. I’ve been trying to stick it out until Firefox 4 is released, but I’m losing confidence rapidly in Mozilla’s formerly delicious love child. When using a laptop or trying to quickly load a page to show a friend a neat bit of code or a cute cat video, I’ve lost my patience with Firefox. I’ll fire up Chrome… or Heaven forfend, I’ve even used IE9 in the past day.

I’m not convinced that Internet Explorer’s plunge in its percentage of browser users is going to change yet, despite IE9. I do think, however, that if current trends continue then Firefox is going to find itself facing a plunge of its own while IE’s fortune improves. Of all the modern browsers out there it currently seems to be lagging the most.

That’s right, I said it. I think Firefox is lagging behind Internet Explorer now in terms of modernity.

It’s all well and good to support gradients and other CSS3 features. But right now with the blossoming trend of web apps and the general push to a web-based computer culture, speed is becoming the king of relevance in making a browser worth using. And at the moment, I’m not convinced Firefox 4 is improving enough to close the gap.

Nine isn’t going to be my browser of choice. It’ll take some time yet before Microsoft can convince me to get back to using the big blue e on a regular basis. But its dramatic improvement has made me strongly examine my current browser of choice. I hear Chrome has Firebug.

Good show, Nine. Firefox, time to pony up.

But some, like Dave “Maximus” Shea, aren’t impressed, as he makes clear here.

I get it. We’ve been hit in the face by Internet Explorer so many times that it’s impossible to think well of it. But the increasing speed at which they’ve started to bring out new versions, and the clear improvements of 8 over 7, have me convinced that what they’re doing is a good thing. Yes, there’s no mention of canvas support. Yes, some of these features were supported years ago elsewhere. But they’re trying hard to improve, and more importantly, they are improving.

So, I for one am glad to see this announcement. It makes me happy. Also, I secretly hope that if the version numbers keep going up on IE, certain stodgy corps will be shamed into updating past IE6.

Hey, a guy can hope. Right?

I realized the mistake in my complacency when I received my first blog comment from a blind user here, where he was testing his ability to post despite the CAPTCHA that was present. At that point I realized that if even one person was visiting my site and incapable of at least knowing what was happening in the comic, they were getting a severely degraded experience, which was a disservice on my part.

My growing awareness of how frustrating such a thing would be is borne out in my Squirrel in the Dark post. As a result of this, I went about adding an aria-describedby attribute to my comic’s image tag. Later, based on feedback from a JAWS-10 user and with another suggestion by John, I doubled up with the addition of the longdesc attribute to the image. In both cases, the value for the attributes is an URL for a separate transcript page.

Thinking all was well, I congratulated myself and went back to poking fun at the HTML5 process and spent a lot of time drawing people in spandex.

Of course, it wasn’t that easy.

First, a new accessibility problem had reared its ugly head. When I built the site’s CAPTCHA, I had actually taken vision-impaired users into consideration and provided description text of each image to allow them to select the proper one for the CAPTCHA (mind you, not including the word that the CAPTCHA asked you to match with the image). However, when someone tabbed through the page’s links and fields, the tabbed indexing would go out of order, going through the other input fields for the comments at a different time than the CAPTCHA itself, making the whole affair confusing.

Secondly, I learned that the aria-describedby element isn’t meant to direct to other pages (which I think is a bit silly of a limitation, but I’m not an expert at these things), but rather should contain the ID of an element on the page containing a description. It’s quite a difference, and one I’ll admit I made by failing completely to do enough homework on the matter in advance.

I’d thank Henri Sivonen for his “bug report” on the aria-describedby issue, but he chose to use the issue to draw a comparison to the Super Friends‘ list of concerns (and its initial posting to a blog instead of the WHATWG mailing list) and neglected to mention it to me directly. So instead I’ll thank Laura Carlson for drawing my attention to my error, Arve Bersvendsen for sharing his opinions on alternate techniques, and Steven Faulkner for suggesting a way to use aria-describedby to link validly to off-page content. I know others contacted me about the error, but I’m sorry to say I don’t remember all the names at the moment.

My solution, therefore, was what Steven suggested in the W3C mailing list. The aria-describedby attribute on the image tag now has a value that is the ID of an anchor on the page. That anchor then links to the comic’s transcript page. The anchor is hidden by CSS to avoid distracting sighted users. You can examine a recent comic, like this one on the Super Friends, to see it in effect (if you’re on a normal browser you won’t notice much unless you view the page source).

The CAPTCHA’s messed up tabbing issue turned out to be an easy fix as well. Stéphane Deschamps pointed out in a comment that there was tabindexes on the form’s fields, which was causing the tab order to go screwy. I didn’t know these existed, having failed to examine the blog software’s default fields very much. Now that he’s pointed it out, I’ve taken them off, hopefully making the CAPTCHA less burdensome.

As I’ve stated in the past, I’m a non-expert at pretty much everything that doesn’t involve vector squirrels. However, I have an appetite for absorbing as many web-related skills as possible to help better the web through direct effort or comic-related advocacy. One of these areas of the web that I realize that I need a great deal more knowledge about is accessibility, and it’s a deficit that I seem to share with almost every designer or developer I meet.

Having admitted my deficiency, I’d like feedback on this issue, if you have it. Does the updated aria-describedby technique for serving the transcript actually use the attribute properly? Is the CAPTCHA usable by vision-impaired visitors with approximately the same level of annoyance all people feel when they use a CAPTCHA? Is there another feature on the site that causes accessibility issues that I haven’t mentioned or considered?

To those who contact me with these problems, thank you. I’m in your debt.

When I was first hired by Mindfly in 2007 I was not what you’d call “web standards aware”. Upon seeing the table-based layouts, font tags, and massive collection of inline-styles that stampeded through my pages like wild buffalo, grown men would gnash their teeth and wail in torment and mothers would hide their children.

It only took a few crying infants for me to realize something needed to change if I wanted to keep this career. My infovore nature led me to consume as much information on the topic I could muster, starting with Andy Clarke’s Transcending CSS and continuing through dozens of online tutorials and references. Learning the errors of my past, I spent a bit of time quietly taking my old sites out to the woods, instructing them to dig their own graves, then whacking them with a shovel before burying them for all time.

After the evidence had been destroyed, I went about trying to make compliant, pretty sites using the best practices in HTML and CSS. By 2008, I had friends who thought making website was the bee’s knees, but they didn’t know where to look for learning CSS, etc. At that point my bookmarks of handy sites had grown enormously, so I heartily recommended several.

One that I mentioned time and again was the Sitepoint CSS Reference, which was (to my knowledge at the time) a very complete, useful reference to the wonderful world of CSS. It even included tasty tidbits about CSS3 support. The main reason I sent each person who asked to this reference was explained in Sitepoint’s announcement:  “…the reference contains a bunch of features that make it stand out from the pack — things like cross-browser compatibility charts and user feedback to ensure that it is accurate, up to date, and best-practice. If you’re building sites with CSS, this is a reference you’ll keep coming back to again and again.”

With the speed at which this industry changes, who wouldn’t want access to a constantly updated reference that even incorporated outside feedback?

There is a problem, unfortunately. As near as I can tell, the reference isn’t updating. Since its launch, it seems to be sitting still, failing to modernize its information as browsers march on. Every single browser on their compatibility list has had major updates since its launch, putting much of the CSS3 support information well out of date. Never mind that Google Chrome has been out for quite a bit of time now (as the Internet sees such things) and has no compatibility information present despite it’s higher browser share than Opera in most markets.

In a book, this situation is a necessary reality. Books, by their static nature, are out-of-date typically before they’ve even been published, requiring later editions, etc. But for a web-based reference, which claims specifically to have the benefit of staying up-to-date and incorporating user feedback, this isn’t terribly cool.

For me, the situation is exasperated by their promise to incorporate feedback (or even claiming to do so) when they (at least in situations I’ve experienced) clearly are not. To back my claim, I’d like like to direct you to my own experience I’ve had, which I’ll call Exhibit A. If you examine the page on CSS3 Attribute Selectors, you’ll find that it erroneously claims that Internet Explorer 7 completely fails to support these little gems.

I’m no IE fan, but I can tell you my friends, that this is a falsehood. And because I was foolish enough to take that advice at face value (who doesn’t trust Sitepoint?) I created IE-specific workarounds in a project where I first included these selectors, workarounds which ended up costing me a decent chunk of time. It was only later that I decided the best experience is personal experience and I actually tried the selectors in IE7, only to discover that they work perfectly fine. I’d wasted time (translate that: money) fixing a nonexistent problem they claimed existed.

Not being the type to hoard information, I shared the fact that they were mistaken in a comment on May 2, 2008, complete with a link to a test page to confirm that I wasn’t full of hot air. (The old test page has disappeared, so you can see what I’m talking about if you check this test page in IE7). Eventually they marked that they’d incorporated my comment into the article… only they hadn’t. It still incorrectly stated IE7 support didn’t exist. Sometime much later (aka, this year), I commented in annoyance at the mistake again on Twitter. They responded multiple times over Twitter to me, asking for clarification (which I gave) and then promised to update their Reference (which they didn’t).

That was a couple months ago.

Today’s comic shares my view on the so-called Reference, albeit in a somewhat abstract sense. So let me make it clear: I don’t think the Reference is what they claim: a reference. Rather, much like René Magritte’s unpipe it is not what it appears, merely the image of it. The unreference, if you will, is something that claims authority and completeness but increasingly lacks both as time moves forward.

One erroneous page isn’t worth tearing down their entire reference. However, with a complete lack of modern CSS support information on every major browser, Sitepoint’s “up-to-date” CSS Reference has become largely useless as a source for web designers living and working in 2009.  I’m upset at this, because I sent literally everyone I knew with an interest in learning CSS to their site, saying “Hey, these guys know their stuff.”

Now… well, now I tell people to avoid it. I’ll repeat that for anyone reading: Don’t bother. They mean well, but they’ve failed to live up to their mandate of keeping updated. In March, when I’d commented (again) on my disgruntlement with the lack of updates, I received the following pair of tweets from Kevin Yank (@sentience).

April 6, 2009 4:19pm: “What erroneous compatibility info did you find? We are planning to refresh the Reference for the latest crop of browsers in May.” (after which I gave a summary).

April 6, 2009 4:50pm: “Thanks! Will get that corrected ASAP.“

It’s July now. I think we may have different definitions for “corrected” or “ASAP”.

To get a better view of what I’m speaking about (assuming you’re not already familiar with it), go check out the post I wrote at Mindfly about this very issue: Web Developer Weems and the Case of the Multiclass Bungler (AKA IE6).

I also saw Star Trek. It was good. It was better than good. Go watch it, you’ll love it. I promise.

As it stands, I’ll take a swing or two in his place. First, let me direct you to today’s comic featuring Andy Clarke, wherein a couple of cheap shots are made at Opera’s expense. Then, continue reading.

First, I’m aware that browser usage statistics are like a dark art, much akin to necromancy and astrology, where accuracy isn’t really achievable. But the fact is (and take a look at Wikipedia’s page on the topic) that Opera according to some of these browser usage sources does in fact have less users than Netscape.

That’s right, there’s still people using Netscape. How scary is that? I wonder if they think grunge is alive and watch reruns of Family Matters while downloading websites on 14kbps modems. And just to reiterate, there’s more of these people (according to some sources) than there are people using Opera.

Beyond that, Google Chrome is the new hot browser in town and has already exceeded Opera’s user base in less than a year. That’s right, less than a year.

Look, I’m not saying it’s the number of users that count. After all, IE6 is utter rubbish and it’s still being used by too many people out there. What I am saying is that instead of wasting your company’s public image whining about the fact that Microsoft is doing us all a favor and forcing IE8 updates over their update system, you could be spending time looking at your own browser and figuring out why among other things a browser that has been dragged along for a decade by AOL then finally shot in the head (aka, Netscape) still has more users than your product.

Instead of making absurd suggestions that your competition serve your product via their update service, maybe you could look at Google Chrome and devise how it so rapidly out-paced you in such a short period of time?

Microsoft’s browser, even its newest version, isn’t even close to the coolest browser on the market. I don’t like Internet Explorer, and I only use it to check website compatibility in my job. But I don’t use Opera either, and that’s because (among other reasons) it has thus far convinced me (and the rest of the world) that it’s not worth the effort of installing and using rather than Firefox, or Safari, or the other web standards-compliant browsers on the market. It’s enough to make me wonder why we consider Opera part of the Big Four (now the Big Five). At this rate, with even terminated browsers giving Opera a run for the money, should we expand that name to the Big Six?

Is Opera a good browser? Yes. If that’s not the reason that it’s being ignored, than what is? Perhaps a lack of add-on support. I’ve always felt that Opera’s too busy telling people how to surf the web, and not spending enough time figuring out the features people want. Firefox isn’t popular on accident.

But I’ll tell you the number one reason why I don’t use Opera. It’s because of the company’s public behavior with their legal actions and petulant whining. The rank-and-file employees are talented people creating a worthwhile (albeit, not standout) product. But the big shots on top cost the company their credibility every time they make a cheap, transparently spiteful shot at the current market leader.

And lest I let the others off the hook, shame on Mozilla and Google for getting involved with the EU nonsense. Focus on your products, not on begging the government to get people to install your browsers for you.

I seriously doubt that Ian Hickson would ever kick Manu Sporny into a deep well (as today’s comic implies). For that matter, I’m not convinced he’d run around in only a cape, sandals and shorts, but I don’t know him as a person so I could be wrong on that point.

However, everything I’ve read, from the W3C’s mailing list archives, to blog posts by various people ranging from ARIA to RDFa, to Ian’s own words have convinced me that Hickson has fallen deep into a self-important gatekeeper mentality on the HTML5 spec, and anyone else’s opinions be damned. Although I will rant a bit on the topic, I’ll start by directing you to the following blog post/chronology by Sam Ruby that discusses this (albeit without the rhetoric I’d be more likely to fall into). The whole thing is a good read, but if you’re impatient you can jump to the end and check out his conclusion. He discusses the need for consensus over dictatorship in the open web again here (I get the impression he discusses that a lot, this is just a sample. I also don’t think he uses the word “dictatorship.”)

It’s become clear to a good deal of people more involved in these circles than I that a Not Invented Here attitude has tainted the HTML5 group, as discussed by Jeremy Keith here in a post about ARIA and HTML5. I’m guessing it’s an easy enough trap for any group of experts to fall into, but it still creates a situation where an otherwise open process becomes a closed loop. Case in point? Well, if ARIA isn’t enough for you, how about the attempts to get RDFa into the HTML5 spec?

RDFa has been facing a Hixie-manufactured road block for months now on inclusion into the HTML5 specification for what on the outside appears to be no better reason than its origination outside of his inner circle. Ian claims he’s seen insufficient use-cases and that he is “confused” by how RDFa is used, despite constant feedback by the RDFa proponents such as Manu Sporny providing both use cases and tutorials. Considering his technical expertise, I find the confusion claim by Hickson more than a bit perplexing. My own technical pedigree doesn’t come close to Ian’s, and yet I was able to successfully use valid RDFa syntax after less than a hour of reading the convenient RDFaWiki. Heck, if reading isn’t your strong point (which would be an unusual situation for a web professional) you can even watch videos they provide.

As near as I can tell, the only reason that he’d be “confused” by both the problems RDFa is designed to solve and how to implement it is because he wants to ensure that it doesn’t make it into the HTML5 spec, and he’s simply counting down the timer. Ian’s guide to handling people starts with Step 1: “There is No Situation” and concludes with Step 4: “Something could have been done, but it is too late.” Considering the stalemate for the past few months as he says repeatedly “There aren’t enough use-cases” or “I’m confused”, one could guess that he’s holding out until October, which according to his often derided timetable is when the Last Call Working Draft is supposed to occur.

Ultimately, though, the problem is more deeply routed than stubbornness. It seems, by all accounts, an unwillingness to play well with others. Quoted in a comment to Sam Ruby’s post Half Full, Ian said “The HTML5 work isn’t using the traditional W3C approach, and will never use a consensus approach so long as I am editor. Consensus simply isn’t a good way to get technically solid specifications, and is in any case basically impossible to achieve in a group with hundreds of participants such as this one.”

Someone with that mentality shouldn’t be allowed to steer the ship for a standard that will define how millions (if not billions) of web pages are made over the next few years. We’re all going to be impacted by HTML5, so even though we don’t need to all agree (an impossibility considering human nature) at least attempting a consensus of those involved is desirable. Even if I’m frustrated by glacial pace of CSS3 implementation, I prefer the W3C’s attempt at a participatory process to some sort of autocratic decision-making on how I’ll be coding for next few years.

For more views about the challenges of trying to be involved in the HTML5 process, peruse these bits about the RDFa/HTML5 conflict by Shelly Powers. Also, I reccomend checking out the advocacy of rev=”canonical” by Jeremy Keith here and here. These posts are notable because they illustrate issues with how the HTML5 group is impacting web development (without hitting the topic over the head as I’d be inclined to do) from the angle of an easy to state problem: the prevalence of URL shortening, the potential for link-rot, and a proposed solution that includes using rev, an attribute that the HTML5 WG has already decided to remove from the HTML5 spec.

What can be done? Well, you can do as Keith proposed for rev=”canonical”, and use it, validation be damned. If, for example, RDFa or ARIA is used enough by authors, then a time will come that no option will exist other than it be included in the spec. It’s a brute-force approach, but it’s a democratic one, which is far preferable to letting one Google employee decide what’s best for us.

A while back, I found a way to make my inline-block spacing issues go away by getting tricky and using word-spacing to remove the gap, as discussed and tested here. I failed to check the results in a webkit browser, though, and recently discovered a slight problem.

Mainly, they don’t support that.

For whatever reason, IE, Firefox and Opera all apply word-spacing styling to inline-blocks, either adding to or removing the whitespace between the elements depending on your style. Safari and Chrome, however, do not. Mind you, they both have whitespace between the elements. They simply don’t allow the use of word-spacing to modify that space.

Here’s an example page showing the use of word-spacing with inline-blocks and normal sentances. Take a look in a webkit and non-webkit browser to notice the difference. (I didn’t bother to do IE 6&7 correction, so those browsers won’t show the lists side-by-side. Upgrade your browser already!)

As you’ll see, the webkit browser isn’t removing the whitespace.

So, the question is this: Does the w3c spec say what behavior is supposed to occur? Is the webkit result a bug/out-of-spec, or are the other browsers providing a result that isn’t required by the spec? It seems to me that the non-webkit result is the proper one. If you’re going to make blocks behave like words with spacing, you should be able to modify them in the same fashion. But then, there’s a lot about CSS that doesn’t always work like you think it should. (point in case: vertical-align. Probably the worst style ever.)