JavaScript archives
Compatibility
CSS coaching
Thidrekssaga
QuirksBlog
Donations
Politics
Mobile
About
COH
The JavaScript revolution started on Saturday 11 June at about 3pm (16:00 Central European time) in a fitting setting: a smoky London pub cellar that contained most of the UK's strategic beer reserve. If you weren't there, don't worry, you'll have plenty of chances to join us. In fact, we need you.
What we basically agreed on is that we need to get the word out. JavaScript is ready for its proper role in modern, standards based websites. During the conference we found plenty of evidence that there is much interest in JavaScript, if only people could get more help and more explanations.
Although the revolution officially started on Saturday, the key event took place the day before, at about 10:05 am, or five minutes into Jeremy's presentation. Jeremy asked how many people in the audience felt comfortable with JavaScript, and the response was about 10 to 15 %, slightly less than I'd expected. Then Jeremy asked who'd like to be as comfortable with JavaScript as they are with CSS. The response was stunning, more than 70% of the delegates indicated they'd really like to know more about it.
This trend was confirmed on Saturday. I expected about seven to ten persons showing up for our JavaScript get-together, but instead there were about 25 to 30; including a few who described themselves as non-JavaScript persons.
Right. We've got our work cut out for us.
I'm not going to repeat the conversation flow of the get-together, first of all because I was a bit hazy and beery back then and can't remember exactly who said what, secondly because I'm still working on a general overview which will contain the main points.
Please don't feel excluded; the JavaScript revolution won't succeed without you because we need a lot of helping hands to make it work. I know many of you want more information, but we'd like to beg a week's time to hammer out the basics before we get back to you.
Meanwhile you can read summaries by Jeremy Keith, Stuart Langridge, and Nick Fitz; please add a comment if you know of another one.
We discussed spreading the word throughout most of the afternoon; the three points I put on the official agenda were treated as an afterthought, and the discussion took about ten minutes.
Simon Willison admirably summarized our naming policies:
So if you say "Wow, that DHTML is really neat" you're a bloody wanker, saying "We should do this cool AJAX stuff" is fine as long as you're talking to the people with the money bags, but when you address your peers you say "I'm having a bit of a problem with this DOM script".
As to onload; the DOMContentLoaded event will fire when the document tree is ready, but before the images have been loaded. It works in Mozilla and maybe in Safari. As to IE: you should add a behaviour to the <html> element, check for document.ready and then execute the DOMContentLoaded event handler. All other browsers will have to work with the old load event for the time being.
Dean Edwards provided most of these details, I hope he'll document this useful bit of knowledge in the near future.
We've deferred discussing the use of JavaScript patterns; our main problem is that they're spread all over the 'Net and that there are still too few of them. Besides, creating them will be a part of spreading the word.
Finally we agreed that bagpipers are best enjoyed when they march off a cliff. The little squeak they make when they hit the bottom is especially delightful.
Spreading the word wasn't the only important JavaScript decision we took. As Derek Featherstone's presentation showed, we need to rethink the relation between JavaScript and accessibility from the ground up; see also his presentation slides.
Derek courageously put forward a controversial idea:
If we are doing things right, we should be able to tell users of older screen reader software to turn JS off for more consistent experience.
Please read his clarification before commenting on this idea.
Derek gave a very interesting example. It turns out that Jaws 6 (it was 6, wasn't it?) supports quite a bit of JavaScript. When a link contains a mouseover event handler, Jaws executes it, alerts the user that content has been added to the page and allows the user to easily reach that new content.
BUT this only works with inline event handlers (<a href="somewhere.html" onmouseover="showLayer(true,2,'bloody wankers')>), while modern best practices call for the removal of such event handlers from our XHTML structure layer.
var navLinks = document.getElementById('navigation').getElementsByTagName('a');
for (var i=0;i<navLinks.length;i++)
{
x[i].onmouseover = showLayer;
}
If you use this proper way of defining your event handlers, Jaws won't notice them. So there turn out to be browsers that support JavaScript, browsers that don't support JavaScript, and browsers that partially support JavaScript. This complicates matters.
Furthermore there was a feeling that JavaScript and accessibility discussions have concentrated too much on noscript browsers, and too little on non-traditional browsers that do support it. Although checking your websites with CSS and JavaScript turned off will remain an important best practice, it's not enough to achieve perfect accessibility.
This is a serious problem that should be discussed. Right now I'm plumb out of ideas, but we'll probably see more talk about JavaScript and accessibility really soon.
Another idea of Jeremy's was to use JavaScript for adding non-semantic CSS markup to our pages. Many neat presentational tricks require the addition of a few <span>s or other inline elements to hold background images or other cool stuff. Why shouldn't we add them through JavaScript instead of putting them hard-coded in the structure layer? More food for thought.
Enough for now. The JavaScript highlights have been covered, and it's time to turn to CSS, accessibility and a few interesting remarks. I still haven't really processed my conference notes, though, so I'll postpone the discussion of these subjects to a later date.
This is the blog of Peter-Paul Koch, web developer, consultant, and trainer.
You can also follow
him on Twitter or Mastodon.
Atom
RSS
If you like this blog, why not donate a little bit of money to help me pay my bills?
Categories:
Comments are closed.
1 Posted by Dimitri Glazkov on 14 June 2005 | Permalink
Crap, I thought I started the revolution. Oh well :)
2 Posted by Dean Edwards on 14 June 2005 | Permalink
It was a pleasure to meet you PPK!
I'll now get to documenting the window.onload stuff I rambled on about when the beer started to kick in. ;-)
3 Posted by Dimitri Glazkov on 14 June 2005 | Permalink
Just to be clear: I am, of course just jealous that you guys had such a good time. Wish I was there. Can you do this in the US next time? :)
4 Posted by Dean Edwards on 14 June 2005 | Permalink
BTW. I don't think there is anything wrong with the term AJAX. AJAX is about using JavaScript to perform data exchange. DOM Scripting is about modifying document content to give (usually) a visual effect - what we used to call DHTML.
The real reason us developers dislike the phrase AJAX is because we didn't think of it. ;-)
5 Posted by Derek Featherstone on 14 June 2005 | Permalink
ppk said: "but we'll probably see more talk about JavaScript and accessibility really soon."
You can count on it, my friend. You can count on it.
6 Posted by Mark Woodman on 14 June 2005 | Permalink
What's the solid rationale for dropping well-grokked terms like DHTML and Ajax? Is there more to it than "the cool kids don't want to call it that anymore?"
Do all the 'serious' developers now have to say, "Yeah, I'm writing this Ajax, er, I mean asynchronous-client-server-communication-using-XML-as-the-data-layer application... using DHTML, er, I mean, DOM scripting..."?
7 Posted by Dante on 14 June 2005 | Permalink
I personally hate the term AJAX, but since it has spread like a tumour around the web, there's no stopping it now.
I hope Dean Edwards got the hint about making the DOMloadContent event in IE7 :)
8 Posted by Fuzztrek on 14 June 2005 | Permalink
High time! :)
Personally I don't see anything wrong with either of the buzzwords - infact, I think JavaScript is in the same boat as DHTML. Developers don't like the term DHTML because they think it implies some sort of useless scripted CRAP, and users don't like the term JavaScript because, I don't know, maybe they think it implies popups, popups, and more popups. However, even useless scripted crap is subjective, and surely one can justify proper use of popups!
Many times people have said that good JavaScript is invisible; that you don't notice it. A redefinition or clarification of JavaScript is needed for both developers and users, a process not so different from something one might do to revive the term DHTML.
Regardless, it would be really nice if the person who comes up with buzzwords would spend a LOT of time thinking about them :P Once it gets out, it spreads like wildfire...
9 Posted by ppk on 15 June 2005 | Permalink
Dean, I wish you'd said all that at the meeting. You're certainly right in a way.
The naming system Simon proposed was maybe a 'social' naming system, ie. words to use when not speaking about technical details but about JavaScript as a whole. As such it's quite workable.
What you're after seems to be a more technical naming system that fits with things like data retrieval (AJAX) and page changes (DOM). That's fine, too, but as far as I'm concerned it has a different purpose.
Anyway, this is not as easy as it seems.
10 Posted by mib on 15 June 2005 | Permalink
I don't like the term AJAX because of the part "... and XML". I'm using quite a bit of asynchronous javascript for data-retrieval, but I prefer JSON as data exchange-format, so AJAX is definitely the wrong term to use.
Something a bit more generic is needed IMHO!
11 Posted by Koranteng Ofosu-Amaah on 15 June 2005 | Permalink
This recent piece of mine was in the same vein...
On Bleach, Entertainments, Forms, Atom, Kiss and Sexy MFs
http://koranteng.blogspot.com/2005/06/on-bleach-entertainments-forms-atom.html
Some ruminations on pragmatism, Bleached Unobtrusive Dom Scripting (BUDS), Forms, Atom, XForms, Glue, Infopath, "Entertainments", Kisses and the Sexy Mom Factor in Software...
12 Posted by Bruce on 21 June 2005 | Permalink
Hi PPK - good to meet you, and thanks for the Guinness you bought me in Clink's bar.
I'm firmly in Stuart Langridges' category #2 of people (http://www.kryogenix.org/days/2005/06/12/javascriptMeetup) so I'm anxious to learn as much as possible, as are many others. But I'm already a baffled by your sentence "As to onload; the DOMContentLoaded event will fire when the document tree is ready, but before the images have been loaded. It works in Mozilla and maybe in Safari. As to IE: you should add a behaviour to the element, check for document.ready and then execute the DOMContentLoaded event handler. All other browsers will have to work with the old load event for the time being."
Can you elucidate for the info-hungry n00bs?
13 Posted by Philip Hazelden on 21 June 2005 | Permalink
It seems to me that the solution to not having an easy way to turn Javascript off is with some server-side stuff - provide some site options and set a cookie for those who check the 'disable Javascript' box, then make sure not to send it when they come again. You could even have lots of different things that could be disabled individually.
14 Posted by ppk on 21 June 2005 | Permalink
OK Bruce, here we go:
1) DOM scripts should start up only when the page has been loaded completely. The initial script expects to find a few divs, links, images or form fields that it wants to do something with. If it doesn't find them because they haven't been loaded yet, it gives an error message and quits.
2) The load event fires when the page has been loaded completely. Therefore this event is traditionally used as a trigger to start up scripts: everything's ready, proceed.
3) The problem is that the load event waits for all images to load. If a clueless client added a 5M bitmap to the site, this whole image must be loaded for the scripts to start. This takes far too long.
4) What we need, therefore, is a load event that doesn't wait for images.
5) In Mozilla (and Safari?) this is DOMContentLoaded.
6) In Explorer document.ready holds similar information.
7) We still have to write a standard script that uses 5 and 6 to avoid 3.
15 Posted by bruce on 21 June 2005 | Permalink
Gotcha.
Dank u wel!
16 Posted by Scott Schiller on 22 June 2005 | Permalink
Regarding accessing the DOM "post-parse, pre-onload" - the technique of throwing a script element at the end of the document (before /body) is a more hackish way of achieving this, although I'm not sure if all DOM stuff works at this point (eg. document.getElementById() doesn't work in Moz. but does [and shouldn't] in IE, presumably since the body hasn't been closed yet?) - however, getElementsByTagName() does.
That being said, I would really like to see a standard script that allows properly separated (externalised) script to access the entire DOM "cleanly" as mentioned (and not inline as above.)
17 Posted by James Edwards on 7 July 2005 | Permalink
I developed something a few months ago that allows scripts to run before window.onload - http://www.brothercake.com/site/resources/scripts/domready/
It's only half-stable though: it works by checking for DOM elements on a timeout - once the the body exists, you can use DOM methods inside it; if a specific elements exist, you can use that element. But where it fails is on collections - it can test for the existence of a collection, but not whether it's full.
I've yet to work out how to do that ..