DOM Scripting: A Web Standard
By Jeremy Keith | February 20th, 2008 | Filed in DOM Scripting TF, General, WaSP Announcement
Skip to comment formFollowing @media 2005 — the first Web Standards conference in Europe — a group of front-end coders gathered in a pub in London to discuss JavaScript. JavaScript had a problem. Its reputation was tarnished, to say the least. The common perception of client-side scripting was frozen in the late ’90s era of browser-specific DHTML. Most people thought it unusable and inaccessible. In truth, the Document Object Model had better cross-browser support than CSS. This misperception needed to be addressed and the gang of geeks gathered on the banks of the Thames were just the bunch to tackle it. That’s how the DOM Scripting Task Force was born.
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.
Your Replies
- #1 On February 20th, 2008 6:55 pm pauldwaite replied:
-
I’m curious to know what Blair Ballmer would look like.
On second thoughts, maybe I don’t want to know.
- #2 On February 20th, 2008 10:17 pm Michiel van der Blonk replied:
-
Isn’t it time for a standard API for JavaScript libraries? It would make life so much easier if UI elements and the complete ‘windowing’ system could be made a standard. We could start with bridge tools, and eventually all library writers would comply. Look at all the common elements: Event, Window, Document, Class, Element, Drag, Slider, Tooltip, Ajax, Date, Calendar…
- #3 On February 21st, 2008 1:39 am Mark Wales replied:
-
A task-force is perhaps not needed, but there still needs to be a general education about not using inline JavaScript so that behaviour is separate from structure. I started reading PPK’s book on JavaScript yesterday and it makes many important points. Yet when you go to websites there is almost no JavaScripting examples that don’t use inline event handling. As a result the one JavaScript on my website is still using inline event handling, because until I finish reading PPK’s book I can’t work out how to do it properly.
- #4 On February 21st, 2008 7:36 am Jeremy Keith replied:
-
Michiel van der Blonk wrote:
Isn’t it time for a standard API for JavaScript libraries?
I certainly think that would be a good idea and at the @media Ajax conference last November, I know that John Resig and Alex Russell were discussing this. If enough of us keeping nudging them (and other library authors), maybe this idea would get some legs.
Mark Wales wrote:
A task-force is perhaps not needed, but there still needs to be a general education about not using inline JavaScript so that behaviour is separate from structure.
I couldn’t agree more. And is this is a discussion that occurs at the intersection of JavaScript and markup, I think it’s one that will be better tackled by the WaSP as a whole rather than a JavaScript-only task force.
- #5 On February 21st, 2008 6:58 pm Sander Aarts replied:
-
Da’ ge bedáánkt zèt da wittû! (thanks!)
- #6 On February 22nd, 2008 3:19 pm Keith Bowes replied:
-
Yeah, JavaScript and DOM have come a long way. I remember the old DHTML days, especially Netscape 4′s awful model. Evangelism still needs to be done, however; we need consistency between implementations.
- #7 On February 28th, 2008 9:22 am Dave replied:
-
Nice touch if everyone got together one more time in a pub to discuss and maybe plan another project.