Blah. So there was this meetup yesterday in Amsterdam which I attended. For the sake of Google — and other people their page rank — these people attended (and a few more): Peter-Paul Koch, Bobby van der Sluis, Robbert Broersma, Faruk Ateş (his write-up), Jeroen Mulder (his write-up), Gerbert Kaandorp (CTO and founder of Backbase), Tom and Dejan from Info.nl who I also met briefly at reboot 7.0 (Tom’s write-up), someone from Lost Boys Nederland and some freelancers I believe. (There was no wiki page this time so easily copy and paste everyone’s job description and link like I normally do was impossible and I’m not that good at remembering such things.)
It was really quite entertaining. Peter-Paul Koch brought some notes from @media which he wanted to discuss to see if anything could be done to make usability enhancing javascript more popular and easier to start with. There was quite some discussion about web applications as well and if they should actually work at all when javascript is disabled. Personally, I’m under the opinion that everything that should be indexed should work without javascript. As you don’t index applications, you don’t need a javascript off version. However, as Peter-Paul Koch pointed out most screen readers are not very well supportive of scripting so if you want to use an application with such a device that would become near impossible.
“Code to standards, not devices,” was what I should have replied to that, but in the real world that is not very practicable unfortunately. If a customer has invested some time in research and the outcome was that there are quite some screen reader users among the client’s audience you simply need to make it work for those people.
Much more interested I’m in your opinion though. Not just about this particular issue (my standpoint mostly derivates from the WHATWG), but more about javascript in general. Personally I’d like simple design patterns for Whitespace in the DOM and an easier way to select elements. (XPath, anyone? Or getElementsBySelector.)
In my opinion, one should use JS to increment usability, not to exclude parts of your users (e.g. screen-reader users). By this I mean practically, you should give an alternative solution to every JavaScript - or at least to those who are necessary. (Image replacement - if done with JS - is not something necessary imo.)
I also agree with you that the treatment of whitespaces is a quite hm ... "difficult" subject which probably holds down lots of people who are at least partially interested from using DOM and falling back to "good" old JS.
Go XPath! :-)
Actually, I did use Mark's wiki to track this meetup, but it seems his wiki is unavailable right now. I'm getting 502 errors on it :/
Not that it had a complete list of names, though... ^_^'
Anyway, it should be interesting what this course of events will bring us. The discussion has been set in motion now, there are various plans and projects and I think that with the lot of us (not just those present at the meetings, but all our readers, too) we can get some really cool things going, here.
I started to write something about javascript on the horrible way some people use it to directly add style rules to elements instead of switching classNames for that element.
I suddenly realised that I shouldn't care so much about javascript. As a designer I'd rather not blur my professional focus by widing my skill base that I will not be albe to maintain to an acceptable level required by today's standards. I'll always like working with javascript and I will always look for best practices.
With the recent musings of WHATWG and xForms my interest has suddenly taken a nose dive. It's the same old VHS vs. Betamax song again. (actually it was Philips vs. Sony with both their video 2000 and betamax systems that fist battled it out. It was VHS who ran off with the prize in the end.) I just don't feel the need to sit round and watch the derailing of this little train wreck in the making.
The handling of CSS and Javascript for forms is still a joke. This has to become easier and more usefull. In my view the lack of a need for skilled and motivated clientside coders is holding the evolution of the web back more than IE and its outdated / quirky document rendering does.
It's good to see a positive push to get something done.
Faruk, no idea what's up on the wiki. I'll try to move it to some other software this weekend, I've had enough of these issues.
Just wondering: did you also speak about Ajax during your meeting?
Jeroen, the term AJAX was mentioned a few times, yes. It was discussed to great lengths, as it kept resurfacing. Not as "ooh cool novel concept" but more along the lines of "let's come up with some cool implementations that actually make an innovative use of this!"
XML whitespace does suck. I was thinking about using client side XSLT and found one general way and one very general way of doing this.
I've never seen DOM whitespace as a big problem. At first it was frustrating because I didn't know it was there, but that was back when I was just starting to dabble in Javascript, and it didn't take me long to work out how to get around it. The only situation in which I found it to be a problem is when stepping down or sideways in the DOM tree. In both cases you can get around it by having another (conditional) step.
function next_real_sibling(obj) {
if (obj.nextSibling.nodeName="#text")
obj = obj.nextSibling;
return obj.nextSibling;
}
Ok you'd need more than that in a practical situation, for example to stop errors occuring if "obj" is the last element, but I've used scripts similar to that above with no problems.
You could also loop through all "#text" nodes and remove them at the start, but I prefer to leave them intact (it usually makes no difference).
It is still a problem though, and I imagine many JS newcomers are indeed put off by this. Personally, I think the main problem is the lack of help they get - be honest, most (but not all) JS books are rubbish and don't help at all.
The handling of CSS and Javascript for forms is still a joke.
Quite. This needs to be fixed. Perhaps XForms will allow this, but they can't be widely used until there is more support for them.