CSS gets the most coverage with 7005 tests, 3784 of them developed just since IE8’s “beta 2″ a few months ago. IE8 passes all 7005, including, mysteriously, 52 tests that do not pass on any other major browser.

For HTML5, coverage includes 13 cross-document messaging and 30 DOM Storage tests. For WAI – ARIA they submitted new samples to support their previously-submitted ARIA to MSAA roles, events, and mappings.

While a great resource for the standardization movement in general, it also goes a long way to support their stated belief that “IE8 RC1 has the most complete implementation of the CSS 2.1 specification in the industry.” It will be very interesting to see if any of the other browsers care to comment. I’m hoping for a four-way tie.

Read more:

• IEBlog – Microsoft submits thousands more CSS 2.1 tests to the W3C
• Windows Internet Explorer Testing Center
• ARIA Test Pages
• CSS 2.1 Test Pages
• HTML 5 Test Pages

Congrats, iheni! I hope to see at a conference soon.

Update: I wrote this post in the middle of the night after working entirely too long and late. In my delirium, I misread Henny as Henry and used incorrect pronouns. Further, in the headline I mistakenly typed Swar instead of Swan (though I got it right in the body and in the permalink).

Sincere apologies for my clumsiness. Thanks to Henny for setting me straight!

I believe in low-fidelity sketching at the wireframe stage. Balsamiq makes it easy with its large library of UI control stencils, its auto-complete driven keybroad stencil selection, on-screen snap-to alignment guides, a powerful inspector for precise control when rarely needed, and, more of all, a simplicity that makes it easy to start sketching or tweaking your mockup immediately.

The output is Balsamiq files, PGN or flattened image files, and XML. Because it exports XML it’s possible to use Balsamiq as a programmatic ingredient for downstream engineering systems and tools (such as partially automating the creation of detailed functional specifications, or using it as source for the automated building on the actual interface.

There is a rumor that they’ll be announcing clickable output files shortly, which might allow for the fast creation of clickable wireframes for usability testing (and other) needs.

I haven’t noticed, but it should be possible to customize what’s in the included UI Widget Library to a) take on a different visual skin; b) reflect new or fewer interface widget options.

All and all, I’m pretty intrigued. It seems there’s a market for consumer-friendly ways to design interfaces. Once more people catch on how to much fun we’re having, they’ll want a shot at designing and realizing all the apps they’re dreaming up, too!

I’d love to hear what you think of this approach. Have you tried it? Does it work for your teams”

Songbird is a media player like iTunes. Except that it’s build on top of the awesome Mozilla Firefox foundation. And like Firefox, it has an extensive array of extensions, themes, and assorted addons. Earlier versions haven’t supplanted iTunes for me, but it’s looking like this version may well do that.

I had some trouble imagining what type of addons would make sense, but in this release we’re beginning to see. An early favorite for me is the ticketing integration:

You can read all about the release on their blog, download it here, and see a screenshot below:

This year, my third presenting at @media in London (2006, 2007), Patrick offered me the morning plenary slot. I used the time to talk about a topic of great interest to me: Professional Frontend Engineering.

Over the last three or four years the role of Frontend Engineering has become more important, more respected, more challenging, and more in-demand than ever before, and so I wanted to put a stake in the ground clarifying what we do, how we do it, and why it’s so important to raise it to a professional level. I had four goals:

• Put a stake in the ground.
• Reiterate our values.
• Advocate the discipline.
• Nurture a healthy Web.

The goals were threaded throughout the four sections of the talk:

• Historical Perspective
• Our Beliefs & Principles
• Knowledge Areas & Best Practices
• Why It All Matters

The talk is embedded below (or download: keynote, pdf, quicktime).

I think this topic is critical to the advancement of the Internet. I’ll be writing more about this in these pages in the coming weeks and months, but for now enjoy the slides. And please share your thoughts and feedback in the comments.

| View | Upload your own

As technologists, we want up to date users. Beyond the real user-safety issues, it frustratingly holds us back. The oldest browser is the lowest common denominator and holds us all back. But sneaking new software into the sacred realm of auto-updating flows is unwise. We cannot take advantage of users at the exact moment we want them to trust us blindly and reflexively.

Multiple Apple products are within arm’s reach. My first technology experience several decades ago was on an Apple product. Love ‘em, but they should know better.

I’m glad John wrote his post.

So this morning I asked my twitter followers (follow me!) which services they knew of. Here’s what came back (in a matter of minutes – gotta love twitter!):

• psd2html.com
• w3-markup.com
• xhtml-slice.com
• slicerus.com
• xhtmlit.com
• xhtmlized.com
• xhtmlgenius.com

Then @jasonw22 pointed out that Jonathan Snook (a hero of mine) has a list of about 20 such services, and just this week posted a review of his experience auditioning the psd2html service.

If you’ve used any of these services, I’d love to hear about your experiences in the comments below (and of other services you may know of or recommend).

I’ll report back on my friend’s experience.

(I must mention, in closing, that I’m skeptical of such services. I’ve spent the last several years of my career promoting the professionalism of frontend engineering, and so I have a twang of fear that these services are a step in the wrong direction. Then again, perhaps services such as these — if, in fact, the quality is there — prove that some aspects of “professional grade” web development are now par for the course. Jury’s still out.)

Stoyan (who authors the phpied.com blog) is part of an established tradition of Yahoo! sharing performance research publicly and widely. Stoyan’s teammate Tenni Theurer concluded the official blog post announcing these data and findings by saying, “We share our findings so that others can join us in accelerating the user experience on the web.”

I agree. That’s why I was honored to help disperse their 14 Rules for Faster Web Sites in my presentation at the @Media conference in London last year.

And that’s why it was a special honor to write the foreward to Steve Souders’ High Performance Web Sites book for O’Reilly last year. (Steve used to head up the Performance team at Yahoo!.) In the foreward I tried to express why performance matters to professional frontend engineers:

Here is why it matters. As a frontend engineer, you hold a tremendous amount of power and responsibility. You’re the users’ last line of defense. The decisions you make directly shape their experience. I believe our number one job is to take care of them and to give them what they want—quickly. This book is a toolbox to create happy users (and bosses, too). Best of all, once you put these techniques in place—in most cases, a one-time tweak—you’ll be reaping the rewards far into the future.

Read more about Yahoo!’s Latest Performance Breakthroughs on the Yahoo! Developer Network site.

In the comments you’ll see a few issues pop up (empties, quotes, get-bys), but after further reflection I think they are without merit.

1. Event Opacity
2. Long-Lived Connections
3. Expose [DontEnum] To Library Authors
4. Fast LiveCollection -> Array Transforms
5. Provided A Blessed Cache For Ajax Libraries
6. Mutation Events
7. onLayoutComplete
8. HttpOnly cookies
9. Bundle Gears
10. Standardize on the Firebug APIs

I’ve long felt that the balance of power between web developers and browser vendors is out of whack: for every one developer working on the browser itself there are probably 1000 web developers at companies around the world toiling endlessly, struggling to overcome the shortcomings and weaknesses of the browsers. It’s wrong. It’s wasteful. It’s expensive – a drain on the economy, and serious sand in the gears of what should be the world’s most powerful innovation platform.

And so, from that perspective, I’m very happy to see visible developers like Alex telling the world (*cough* browser vendors *cough) what needs to change. He’s got a good list of comments going over on his blog – I hope you’ll join in the rally.