ItsAllEasy

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.

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.

jQuery has really, really nice documentation.

The LavaLamp jQuery plugin provides a really nice effect for menus…and another reason for me to go get and play with jQuery.

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.

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).

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?

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)

Here I thought I was a ‘unique and beautiful snowflake’. Was all proud of the javascript inheritance scheme I thought NOBODY was doing. Well…KevLinDev SMOKED me. He had his inheritance tutorial up since back in April of 2002. And apparently his tutorial is the reason the approach is used in YUI.

He seems to be a pretty smart guy though and he works on Aptana, so I take some solace in knowing that we think alike And I still haven’t seen a better callSuper implementation (even though I still think its an unnecessary feature). Anyway, way to go Kev, that’s awesome.