1. HTML5
2. CSS3
3. speed

Now three “developer previews” in, by all accounts they’re living up to that promise: HTML5 support is increasing rapidly (including support for canvas; as PPK just confirmed, their CSS3 support is nearly complete; and several benchmark tests put them right up there with Chrome in terms of speed.

In playing around with the browser, I’ve been really impressed so far. To me, IE9 really puts the oft-maligned browser on par with the remainder of the browser landscape and even gives them the edge in certain cases. My hat’s off to the IE team, this is great work. I’m excited to see what happens as it continues to develop.

You can download the IE9 preview and check out some of the demos at http://ie.microsoft.com/testdrive/, but keep in mind that you’ll need Vista or Windows 7 to run it.

• the death of hasLayout
• object fallbacks
• stylable legend elements
• generated content (including support for dynamic attribute insertion via attr())
• CSS counters
• support for the quotes property
• outline control
• data URIs
• full access to the style attribute via the DOM
• mutable DOM prototypes
• and much more

This browser is a giant leap forward for standards support at Microsoft, but reviews so far seem mixed. What do you think?

Acid3 is a complex test compared to Acid1 and Acid2. The Web is increasingly becoming a platform for application development, so Acid3 tests many of the DOM2 and ECMAScript specifications, in addition to markup languages, CSS, SVG, and others. A complete list of specifications tested will be available when the test launches, along with a guide to the test.

Due to the complexity of the test, we’re asking for a final round of feedback to ensure its fairness and accuracy. Please review the test and submit your comments here or email them to us.

So what does that have to do with the DOCTYPE switch? Well, the DOCTYPE switch assumes that if you are using a valid DOCTYPE for a “modern” language (e.g. HTML 4), you know what you’re doing and want the browser to render in standards mode.

That assumption could have worked out all right, had it not been for authoring tool makers who—with the best intentions and under pressure from us (the web standards community and WaSP, in particular)—decided to include valid DOCTYPEs in new documents by default, thereby crippling the DOCTYPE switch because it wasn’t an explicit opt-in. Now add to that the fact that IE6 had the lion’s share of the browser market for so long—thereby becoming the primary browser in which many developers tested their work—and you have a recipe for disaster: developers assumed (there’s that word again) the layout they were getting in IE6 was accurate, not realizing they had been opted-in to accept rendering engine upgrades as the browser evolved (all of which was reinforced by the 5 years of stasis in terms of IE6′s rendering).

So along comes IE7 with it’s tuned-up rendering engine and, well, it caused sites to broke.

Not wanting to see that happen again, Microsoft approached us (WaSP) to help them find a better way of enabling standards support through an explicit opt-in. You can read more about the thought process we went through in my article on A List Apart. The issue also features a commentary piece by WaSP alum Eric Meyer (who was not involved in the development of the solution, but was asked for feedback on our work) that takes you on the mental journey he took in reaction to our recommendation. The series for ALA—on what we are calling “browser version targeting”—will wrap in two weeks with a piece by Peter Paul Koch—who, like me, was involved in the development of this technique—that will cover application of the browser targeting mechanism in IE8 and beyond.

This buzz has been translated into Polish.

Her chapter in Friends of Ed’s Web Accessibility: Web Standards and Regulatory Compliance, Understanding Web Accessibility is an excellent practical introduction into the barriers disabled people face when using the web. One point in particular stood out for me: Allowing text to increase in size is not enough, sometimes content can be more accessible when text size is allowed to be reduced. Take for example a person suffering with tunnel vision, the range of view is limited, so a smaller font-size allows more content into their field of vision.

The RNIB Web Access Team are hosting Shawn’s accessibility talk which covers recent developments, current issues, tools, web applications, ARIA, and the WCAG-complementary guidelines ATAG and UAAG.

The talk is on Tuesday 5th June 2007, at the New Cavendish Street campus of Westminster University, London, UK. The nearest tube station is Goodge Street. Starts at 7pm. Book your place now! (hat-tip: Stuart Colville)

Just what the world needs, another JavaScript library.

That hasn’t stopped him from creating Yet Another JavaScript Library Without Documentation™. But this isn’t a big full-featured library along the lines of jQuery or YUI. Instead, this works more along the lines of Dean’s famous IE7 script: it’s a patch for current browsers. For example, it fixes Internet Explorers buggy implentation of getAttribute and setAttribute. It also fixes broken browser implementations of the event handling addEventListener method:

So, as you can see, it doesn’t do much. But what it does, it does consistently across a lot of platforms.

If you’re finding cross-browser DOM Scripting to be a real hassle, this could be just what you need. It creates a level playing field. You won’t get any fancy animations or $ shortcuts but you will get peace of mind for 20K. This probably isn’t a script for beginners but if you’re an advanced developer, you might appreciate the power this gives you.

I don’t think I’d really call this a library. It’s more like a band-aid for browsers. But if you are thinking of putting together your own library or band-aid, Dean has provided rules for JavaScript library authors. In a nutshell, make it small, flexible and standards-based.

In today’s post Eich highlights the advantages, and more prominently the disadvantages, of closed source web applications; Flash is held up as a prominent example, with Microsoft’s platforms not far behind. His ultimate point is that Firefox and its alternative-browser kin are in a position to provide support for platforms that can compete with existing RIA tools.

Eich concedes that single vendor control of application platforms (e.g., Flash) creates a stable environment for developers that is attractive at first glance, but goes on to say that such control eliminates the opportunities that are created when application developers (and even end users) are afforded the opportunity to affect the evolution of those platforms at the most basic levels… which is exactly what happens with Open Source projects.

While the post reads at first like OSS cheerleading, Eich is looking for feedback — he wants to hear from other developers and users how Firefox can best take a leading role as a platform for RIAs (via the canvas object) and other emerging web technologies.

…So I repeat Eich’s closing question: what do you think can and should be done with Firefox for the sake of RIA innovation?

One of the big problems of learning a new JavaScript library is the lack of practical step-by-step guides for that library. The API documentation barely scratches the surface of what’s needed. The API is just a dry snapshot taken at a point in time – a roll-call of methods and properties.

A step-by-step developer’s guide should demonstrate the features of the library and show how its methods and properties work together to solve common development problems. What I’m looking for is a book that could be titled: ‘Develop web applications with XYZ library in a weekend’, that contains a series of working examples, using the features of a library as well as explaining those features.

Perhaps its also worth creating a gallery of typical web applications (for example, a blog reader/editor, a calendar, a collapsible tree) and show how these applications are built and developed using the various JavaScript libraries. That gives us a chance to focus on the practical aspects of libraries, as well as identifying and comparing the strengths and weaknesses of libraries.

Chris lists other frustrating pain points including the lack of unobtrusive examples, libraries that break accepted conventions, lack of consistent terminology, and the lack of accurate and realistic evaluation of browser support.

We’ve got a lot of work to do to make JavaScript libraries usable by web developers. It shouldn’t be this painful.

In the interest of time and keeping the process streamlined and organized, we’ve opted to make the wiki invitation-only, but we do need your input. Please have a look at what we’ve put together so far and leave your thoughts/ideas/recommendations in the comments below. We don’t know how soon we’ll need to get this list over to the IE team, so please don’t wait to long.

We will work to incorporate any relevant ideas into the final list, prioritize it, and pass it along to the IE team. Once the list is out the door, we will need to develop test cases for each item on it (some of which we’ve already begun), so if you are interested, please let us know that as well.

Note: We’re not guaranteed to get everything we ask for, but they are listening.

The course takes you through the theory of the DOM, how browsers implement it and what the problems with the DOM and the implementations are.

Each are half an hour long, and – having been in the training myself – I must say they taught me more about JavaScript and the DOM than a lot of books and hours of researching why something just didn’t work.

• Theory of the DOM Part 1 (31 minutes)
• Theory of the DOM Part 2 (21 minutes)
• Theory of the DOM Part 3 (26 minutes)