itsalleasy
RWE Quotes – Day 1
Leave a Comment
Memorable Quotes from Day 1 of the Rich Web Experience (some paraphrased):
Stuart Halloway:
“XSLT is the worst thing to happen to functional programming in 25 years”
“Given the state of testing, its shameful to release a toolkit with no tests”
“There are good programmers and not good programmers. Anyone that has to qualify that with a particular language is not a good programmer.”
Dean Saxe:
“Crypto Fairy-Dust”
Douglas Crockford:
“Write Once, Run Away Screaming”
“Wow, that has rounded corners!”
“Lets get rid of CSS”
Rich Web Experience – Day 1
Leave a Comment
Today was day 1 of The Rich Web Experience conference. My head is still spinning a bit. Its surreal to see and meet the people I feel like I’ve known for so long from having read their work and their blogs for so many years now.
For me, the day can be summed up as: Rich Web is here, now we just need to make it work. Sure, we’ve put together some nice libraries and built and learned new, rich paradigms and even have them in production web applications. But its HARD, fragile, slow, insecure, hard to test, and ultimately needs to change. Thats not to say we’re going down the wrong path…we’re trying to find the right one. There is some really cool work going on in the space, and we are evolving and improving the human/computer interaction every day. That evolution will come along for the ride and eventually have a place in the future of Rich Web(s).
Script-Assuming Styles
Leave a Comment
Recently, the topic of script-assuming styles came up again. With all the ajax and RIA flying around, its easy to forget that some folks fly with javascript disabled. This trap may lead to the developer creating styles that will assume script is enabled (since our heads are in script-land SO much) and wind up being useless to those without javascript. For example, a slideshow widget may have the style for the images set to hide them by default, then use javascript to display the images in-turn. Users that don’t have javascript will be looking at a page full of hidden images. No big deal to fix though, just make them visible by default and then have javascript hide them when the widget loads. The problem with this is that there will be a visible flicker when the page loads. The images will be visible for a split second, then they disappear.
The noscript tag could work here also (and without the flicker). Basically, have a noscript tag that would load a stylesheet specifically to ‘fix’ the widget to be usable when javascript is not enabled. This currently works, but there is some talk of the noscript tag not being included in XHTML5 and its a bit annoying to have that much distance between what is effectively the same logical group of styles just to cover the 2 modes. It would be especially annoying if this were a ’3rd party’ widget or tool being dropped into a page.
I’ve talked about how it’d be nice if there was a :scriptEnabled pseudoclass available, but there (still) isn’t. The workaround is to have javascript code set a class on a root element that will just cascade and hide the images for you. Until today, I thought the body element was the best candidate for that: just add a ‘scriptEnabled’ class to the body element (document.body) and then the styles will cascade. The trick was getting the script so that it would reliably be run AFTER the body was available. Without using a ‘dom ready’ approach, the best I’d could muster was to just have the script in line as the first child element of the body. It was a trade-off that I could live with.
Then I read this thread and I felt like a noob. In it, Simon Pieters describes the same approach, but used a much more appropriate element…and one that was much easier to get at without all the timing concerns. The root element itself: the html element (document.documentElement). The scriptEnabled class can be set on the document.documentElement and then the styles that want to assume that script is enabled would just be prefixed with .scriptEnabled. I had never thought about styling with the html element. I’ve used it (the html>blah css hack), but I’d never thought about using it for non-hackery. The nice part is, the code can be anywhere…the documentElement is (obviously) available when script is executing.
document.documentElement.className += " scriptEnabled";
On a related note: I now have a ‘noob’ category.
Police Looking at Firebug
Leave a Comment
I’ve been keeping my eye out for javascript and ajax news from around the web, and this one came across my reader this evening: Police search for suspected firebug in Ajax. I chuckled.
Visual jQuery
Leave a Comment
jQuery has really, really nice documentation.
LavaLamp Menu Effect
Leave a Comment
The LavaLamp jQuery plugin provides a really nice effect for menus…and another reason for me to go get and play with jQuery.
JavaScript Developer Tools
Leave a Comment
There is a new release of the Ajax Toolkit Framework for Eclipse. This version includes the JavaScript Development Tools which provides:
# code completion
# fully configurable formatting and syntax highlighting
# code refactoring
# smart error detection and completion
# auto-complete of brackets, parentheses and indentation
# extract function/change function signature
# open declaration/type hierarchy/call hierarchy for a given method/object
This is good news for web application developers that use Eclipse. I’m interested in seeing how it compares to Aptana.
XRAY and MODiv2
Leave a Comment
Just found out about XRAY via Ajaxian. At first I thought it was just like the Mouse Over Dom inspector (MODiv2): both are bookmarklets, both show you the structure of the DOM and attributes of elements you point to, and both work cross browser (after xray’s update). After a closer look though, the XRAY guys display style information as well (and it looks nicer too).
Null Coalescing Operator
Leave a Comment
Recently, Adam showed us an interesting bit of syntax for C#:
a = b ?? c;
which is equivalent to:
if(b != null){
a = b;
}else{
a = c;
}
I was reminded of it again today when I learned it is called the “Null Coalescing Operator”. Javascript has something similar with:
a = b || c;
I’ve used the hell out of it in javascript so it was cool to see it available elsewhere. Will it come to java?
Selling Accessible Web Applications
Leave a Comment
Roger Johansson talks about one of the key elements in writing an accessible website: JavaScript interaction must be input device independent. He talks about some low-hanging fruit for how to take steps to follow the rule and allow non or limited mouse users the ability to use your site. I try to push accessible, unobtrusive javascript as much as possible on the projects I’m on, but the pushing gets more difficult when the project is an (increasingly more and more rich) web application. I never seem to have enough ammo to convince the customer of the need (even with the Target lawsuit).
Should I need to do the convincing though? Is it something the customer would just expect out of the rich web application they are having built? Maybe it should be a basic assumption, but cost comes into play. It is more expensive to code an app so that it’s accessible or so that it will degrade gracefully without javascript. Therefore it is something the customer should probably buy off on if it wasn’t part of the initial bid. So, I do make sure the topic comes up with the customer, but apparently my sales skills need some work. Roger gave a good list of users that don’t use a mouse (some of them not-so-obvious)…maybe that’ll help my next pitch 
* Mobility impaired people who cannot use a mouse at all
* People with motor impairments who can use a mouse but lack fine motor control
* Screen reader users who do not use a mouse, or even a monitor
* People using mobile phones
* Laptop users, since most laptops have really bad trackpads or other means of positioning the cursor (ever tried using a hierarchical dropdown menu with a trackpad while riding on a train?)
* Speed typers who have learned to use keyboard navigation efficiently and are slowed down when they have to switch to their mouse (if they have one)
