As a web developer for a relatively large company that provide basic societal services with a wide ranged target group, accessibility has always interested me. I’ve been to a few workshops regarding web accessibility and I try to, at least to a lesser degree, make our web sites accessible to visitors using various types of accessibility tools like screen readers and so on.
Creating accessible web sites isn’t that hard as long as they are static. But the web isn’t static any more! As the web technology evolves we tend to make more dynamic web sites that are becoming more and more state full than the old and boring state less web. We do this with the help of JavaScript and AJAX to update a part or section of the page if the user clicks this or that button or what ever. And this makes it way harder to create accessible web sites for visitors not using a mouse to navigate or who can’t see the actual page.
But as the “regular” web technology evolves with HTML5 and such, so does the accessibility part of the web as well. I just stumbled upon this great talk from Google IO 2011, and I think this is something that every web developer who likes to call her or him self a web developer should see. At least I know what I will do the next couple of weeks! With some really small efforts we can make the web much more accessible for people with various impairities.
Nowadays web sites and web applications tend to be more and more JavaScript driven which results in humongous JavaScript files. It’s not uncommon to have several 100 of bytes of JavaScript on a site. Of course web browsers cache stuff like JavaScript so that it only is requested from the server once. But judging from the visitor logs at work most people only visit our site once a month or so which means that cache will expire and all those scripts has to be requested upon the first visit.
Now, there are several ways to compact JavaScripts: Packer, YUI Compressor, Shrink Safe, jsmin and many more. Some of these just remove redundant white space and comments, some obfuscates the code and shortens variable and function names and what not. Many of these scripts and programs are very fine but they require you to manually minify your scripts, and that’s just a hassle!
But since we use Roxen CMS at work things get much easier if you write your own Roxen filter module which automatically minifies JavaScripts on the fly, given they meet certain criteria. And so I did!
I ported the original jsmin code written in C to Pike. Then it was just a matter of creating a simple filter module for Roxen. And then it was all done.
You can use two criteria to determine if a script should be minified or not:
Path glob: In the module settings you can specify any number of directory globs or full paths. If a requested JavaScript either is in a directory matching a glob or is a direct match it will be minified.
Query string variable: In the module settings you can define a variable name that if exists as a query string variable in the request the JavaScript will be minified. So:
The other day I needed an URI class for JavaScript. I was doing some stuff where I needed to alter certain parts of an URI. I bet there’s a couple of URI classes for JavaScript out there but I can be a bit nit-picky about code and how it’s written
Anyway, I had a URI parser regexp lying which I wrote for a Vala class (before I found the Soup.URI class) and I thought that since that’s reusable I could hack up a JavaScript URI class myself. So I did!
Here’s some examples of usage:
5 lines of JavaScript
var uri =new URI("http://poppa.se/blog/javascript-uri-class/");
