Playing nice with others in javascript

Andrew Dupont has written a very interesting article on Prototype, and the recent $() extensions that allow things like $(someelement).hide() and so on.

This is actually a really nice solution. It's syntactical sugar without actually extending the element itself. Andrew argues that as an object oriented language, its reasonable to want to be able to extend objects like HTMLElement in javascript. I know where he's coming from, but out in the wild - in a world where my code has to co-exist with that of other authors (co-workers, customers, and potentially end-users via GreaseMonkey and similar) these core objects and data-types are a shared property and not to be taking liberties with.

A portal is the extreme case, where the portal framework ("style") has its client-side scripts, and included portlets can have their scripts. Portlets might be by the same author or vendor as the portal, or not. The potential for collision and overlapping is huge. This is made worse when you consider that portlets using the same libraries might co-exist on the same page; do we download Prototype.js twice? What if the portlet code was developed against a different version of the same library? And finally, to make a difficult problem basically impossible, its theoretically possible (I gather) to place the exact same portlet (id and all) twice on the same page.

Much of this is just hypothetical. In practice the portal owner has to take some responsibility for what goes on a page, and should enforce some basic conditions like requiring portlets to not tromp around in the window object and global namespace (and not mess with the fundamental data types that other scripts have to share). And in truth - how much scripting is really necessary on these kinds of portal pages? Most functionality will be a click away when the user actually selects a link from the portal and goes there. But there are some interesting use cases where you'd legitimately want to bubble up richer interactions to the aggregated portal page: how about client-side form validation, tooltips, context-menus, productivity (e.g. select all/none) controls.

The Dojo Toolkit goes some way to addressing these issues. It minimizes its footprint in the global namespace - with just the dojo object itself, and a djConfig object. It also has checks in place to safeguard against the unexpected properties of objects that can show up when the core data type object prototypes have been extended (such as Array, Object, Function).

Note, none of this is new or unique to Ajax and the wave of more responsive UI we're seeing recently. The issue existed long before in even the simplest client-side scripting, as well as CSS (most pronouncedly when a stylesheet defines styles directly on an element such as P, TD, UL etc.) The advent of richer browser-based UI does quickly bring the problem to the fore though...

WCAG 2.0 (as compared to section 508)

I've been really impressed with the WCAG 2.0 guidelines. This is a big improvement in the way the guidelines are presented and worded that I think will make adoption much much more likely. This here page answers the inevitable question: how does WCAG 2.0 line up against section 508? On one hand it adds specifics and details: sucess criteria and techniques for achieving success. On the other WCAG 2.0 doesnt assume the use of HTML to present web-based content - so some detail that is explicit in section 508 has been moved to other sections within the document that provide technology-specific details.

Accessible maps at ALA

This is a nice write-up of making a point-map (a map with information relating to points on that map) in a semantic and accessible manner. I read a lot of articles, and rarely feel compelled to blog them. I was impressed with this one though. It doesnt shy from diggging right into the details, and does an admirable job of working through some complexity to present a real, viable solution. So many introduce a single technique and leave "the rest" as an exercise to the reader. The author also using a definition list, which is one of my favorite constructs. My only hesitation is that DTs dont feature in the Heading heirarchy, and so as semantically appropriate as they are, you lose that implied structure in most UAs.