Steve Balmer once said “Developers! Developers! Developers!” Tony Blair once said “Education! Education! Education!” Put the two together and you’ve got the very straightforward raison d’etre for the task force: to educate developers about the mature state of JavaScript and the DOM. DOM Scripting was the missing piece of the Web Standards puzzle: markup for structure, Cascading Style Sheets for presentation and DOM Scripting for behaviour… provided it was implemented with thought and care.

The Web Standards Project was started because browser makers didn’t implement the DOM as a web standard consistently. The DOM Scripting Task Force formed much later to encourage browser makers and developers to manipulate web sites with JavaScript in a meaningful and standards-oriented way — scripting the DOM.

Fast forward to today. JavaScript has come a long way. I wish the DOM Scripting Task Force could take the credit but the real impetus came from the rise of Ajax. The Web has changed in many ways as a result of that scripting technology: some good, some bad. But one unmistakable consequence has been the recognition of JavaScript as a powerful tool for web development.In fact, the technology is in such demand that the members of the DOM Scripting task force have barely had time to devote to furthering its cause. Another change in the market has been the rise and wide adoption of libraries that offer easier access to the HTML content and fix browser implementation bugs of the DOM standard for you.

There is no further need for a task force to promote DOM Scripting. Don’t get me wrong: there’s still plenty of work to be done in the realm of client-side scripting. But it no longer makes sense to treat DOM Scripting as something separate to Web Standards. JavaScript — or, more accurately, ECMAScript — is now an accepted part of the front-end stack along with with (X)HTML and CSS. Rather than keeping discussion of the DOM sequestered in a task force, it will now take place alongside its fellow Web Standards.

The task force has had a good run: my sincerest thanks go out to my fellow task force members. There’s plenty of more work ahead of us. At the same time as we bid farewell to the DOM Scripting Task Force, we greet DOM Scripting as one of the core technologies championed by the Web Standards Project.

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.

The list

Last week, our groups voted for what we each saw as priorities and those votes were tallied to create a final list for me to present in Redmond. Though there is obviously a great deal more we want to see in IE.next, we felt several things were critical and wanted to focus on those as a starting point.

Tied for first place, in order of priority, were some sort of fast, arbitrary node-matching API and better error reporting. In the realm of DOM Scripting, node-matching is key (just look at the number of scripts out there performing node matching based on CSS selectors, etc.), so being able to tap into a native XPath implementation (which we generally favored over the Selectors API) would greatly improve the speed of script execution. As for the error reporting, perhaps Justin Palmer (of JS Ninjas) said it best:

We could possibly find ways to fix all the other problems if we could tell what the hell was breaking and why. Without better error reporting, the remaining stuff on that list is just giving us a bigger gun to shoot ourselves in the foot with.

Next up in our list was a desire for mutable DOM prototypes. This would address the issues that arise from IE’s implementation of DOM objects in JavaScript, where elements of the core DOM are not derived from the standard Object prototype. While not technically a standards-support issue, this request does not conflict with standards and it does provide JavaScript developers with the ability to address some of the issues the IE team may not be able to address themselves in the next release. As Andrew Dupont (another Ninja) remarked, I think it’s reasonable to ask that a DOM implementation in JavaScript behave like it’s part of JavaScript.

Next up was a biggie: bring IE’s event system in line with the W3C event model. This has been an issue for a lot of developers and the code to equalize the two event systems makes up a significant chunk of all of the major JS libraries. Getting IE to implement the W3C event system would be a real boon for standards support and would drop the size of many libraries considerably.

Finally, the last of our top 5 was not a JS issue, but rather a CSS one: implement generated content. I don’t know that I really need to get into the reasons why this would be really nice to have.

Two “honorable mentions” were included in the list as well: fixing the issues with getAttribute() and setAttribute() and starting to implement some of the features of JS 1.7 (such as block-scope variables using let, etc.).

Not willing to let the IE team off that easy, the document presented also highlighted several other issues which really need addressing including (among others)

• fixing CSS bugs (including collapsing adjoining margins and z-index);
• various form control fixes (including implementations of the button element, labels, and the disabled attribute);
• correcting its support for object;
• adding support for the q element (which should be a breeze once generated content is enabled); and
• fixing attribute issues (such as alt being used for a tooltip, cite not being supported on q and blockquote, and summary not being supported on tables).

The meeting

In Redmond, I met with Pete LePage, a Product Manager at Microsoft Web Platform and Tools, and several other key members on the IE team. We discussed the list and its implications in great detail for nearly two hours. While I am not at liberty to discuss all of the details of the meeting, I can say for certain that the group I met with was keenly aware of the issues we brought up and are eager to address them. One team member even said that he could have easily guessed our top 5.

The one concern they have—especially with regard to the event model and getAttribute()/setAttribute()—is that any adjustments they make to bring IE in line with the standards not “break the web” for the large number of sites using the proprietary IE event model, etc. We discussed this particular topic at length as it is a valid concern and I’m happy to say that I think we’re close to a solution on that front.

I came away from this meeting with a real sense of hope about where IE is going and am really encouraged by their willingness to engage the standards community (and web developers as a whole) in dialog like this. We did not resolve every issue in our two-hour talk, but I was assured that this was only the first of many steps toward improving IE.next. The IE team wants to continue this conversation and to continue to elicit feedback from the web community as a whole as things progress.

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)

Check out this quick example of event handling versus event delegation to see how it is done and what the benefits are.

We have heard a lot of requests to improve our Jscript engine, especially now that AJAX
sites are becoming more prevalent on the web. I want you all to know that we have been
listening and have recently made some great fixes to our engine to improve the garbage
collection routine and to reduce unbounded memory growth.

This was confirmed by tests performed by the qooxdoo developers:

In fact many demos of qooxdoo
run much faster now in IE7 compared to IE6. And they are even faster than in Firefox 1.5 in many cases.
This is a huge jump in performance. Microsoft did not tell about their exact modifications, of course.
Anyway, they have fixed the major problem of large JavaScript-based web applications. This problem,
despite having a catchy name, was mentioned many times before like
here,
here and
there:
If you have many objects created, which are simply accessible in the current scope, all
methods and features of JavaScript slow down dramatically.

It would be great if these bugs were fixed so I emailed
Chris Wilson for comfirmation. He replied:

Yes, it is true we’ve done some dramatic improvements to JavaScript
performance. I wouldn’t say we’ve fixed everything, but we’ve addressed
a bunch of memory leak problems and most significantly, taken a
different strategy for the Jscript garbage collector. This last one
makes a huge difference in many current JavaScript-heavy pages.

Good news indeed.

This was by no means the first time it has been done, but it is an incredibly solid implementation and a great tool to have in your utility belt alongside CSS Drop Columns and Browser Size-Dependant Layouts. Lawrence & Christian offer a few suggestions for how to use it, including

• turning a horizontal menu bar into a vertical single list when the font is too large;
• replacing a graphical button with a normal submit on large fonts;
• applying different style sheets to the document according to font size. You could also automatically switch to a zoom layout at a certain stage;
• removing elements when a certain size is reached;
• showing more elements when a certain size is reached (in case the user zooms out instead of in);
• pulling in longer text passages via Ajax when the screen space allows for longer texts;
• increasing the width of a sidebar when the font size changes to keep a consistent line length; and
• centering an element that is defined in em on the screen.

But I’m sure you can come up with more.

The first Web Standards Group event in London was held last Friday. The sold-out event was organised by Stuart Colville and featured two presentations. Andy Budd talked about web standards and the history of the screw (I guess you had to be there). Christian Heilmann talked about maintainable JavaScript. Both talks were recorded and are available via podcast.

The subject of maintainable, well-written code seems to elicit some strong reactions. Seasoned developers respond scornfully by saying that this kind of advice is obvious and goes without saying. If it’s so obvious, why is the advice to rarely put into practice?

In my opinion, this kind of straightforward, practical advice can’t be repeated often enough. That’s why I recommend you read Christian’s article in Think Vitamin. It’s packed full of good advice.

There’s more JavaScript goodness to be found in Christian’s new book, Beginning JavaScript with DOM Scripting and AJAX.