Note on JavaScript prototypes and object variables

This makes complete sense, once you think about it, but I didn't at first and it bit me.

>>> function Obj() { }
>>> Obj.prototype.position = { "x" : 0 , "y" : 0 };
Object x=0 y=0
>>> var a = new Obj();
>>> var b = new Obj();
>>> a.position.x = 10;
10
>>> b.position.x
10

This Firebug console output shows writing a simple object, Obj, and setting a prototype variable position to an object literal having two member variables, x and y, both initially set to 0. Since object instances simply reference their prototype variables when set to objects (Array, Object, Function, etc.), updating instance a's x position will update instance b's x position as well.

In order to get around this, while still setting aside a spot for the position variable in the Obj prototype, assign the value in the constructor like this:

>>> function Obj() { this.position = { "x" : 0 , "y" : 0 }; }
>>> Obj.prototype.position = null;
null
>>> var a = new Obj();
>>> var b = new Obj();
>>> a.position.x = 10;
10
>>> b.position.x
0

It doesn't look as nice, and requires that you call the parent constructor when you extend the object (always a fun process with OO JavaScript), but it works much better this way.

WAI-ARIA makes life much easier

I decided to re-post here my comment to the A List Apart article, Accessible Web 2.0 Applications with WAI-ARIA, as it seemed from most of the other comments that people don't really see just how much WAI-ARIA will help both developers and users.

In the current methods of adding screen reader support (see an example at Juicy Studio with excellent descriptions), it takes a lot of scripting in order to dynamically inform a screen reader that things have changed. These methods also rip the user out of whatever they’ve started reading or writing at that time, and drop their cursor wherever the change occurs. The later versions of Jaws don’t quite do that, but in order to support a broader user base, you need to do it that way...Jaws costs a lot of money for an individual to keep paying for every year.

With WAI-ARIA, this gets handled just by adding an attribute of aaa:live, and you can fully control the urgency with which the screen reader will read the updated DOM elements! This not only keeps the user in their current context, but allows “polite” live elements to wait for the user to complete their current task before the user needs to hear it. Errors and other urgent information can either user “assertive” or “rude” in the worst case scenarios.

This doesn’t even touch on some of the benefits of the other attributes available, but just the aaa:live attribute itself makes screen reader support infinitely easier to implement and much, much more flexible.

You can see some good examples on the Firevox (open source, cross platform Firefox screen reader) site.

Yes, this very new working draft has some time and work before it exists as a specification. But it needs support from developers in order to take off some of its rough edges, and for the more widely-used screen readers to start paying closer attention. WAI-ARIA can only help developers and we have every reason to help push this project forward.

Note: I edited the comment to use actual links and markup...and to fix some spelling errors.

PHP object oddity

While writing about abstraction, I realized that since $variable->$something works, why shouldn't it work when $something=42? Well, logically, because $variable->42 won't work. It triggers a "Parse error: syntax error, unexpected T_LNUMBER, expecting T_STRING or T_VARIABLE or '{' or '$'" when attempted. However...

$a=1;
$b=new stdClass;
$b->$a='a';
var_dump($b);

...results in:

object(stdClass)#1 (1) {
  ["1"]=>
  string(1) "a"
}

Which, I suppose makes sense that PHP, in its type-cast-happy wisdom, would simply make it a string key. But it does create object variables only accessible through abstracting the variable key with another variable by using $b->$a. It will also cast an array to a key of "Array" without any of the array values, and it also triggers a notice about the Array to String conversion.

Just something I did not expect...

Then again, I also didn't expect the following to work in PHP 5.2.1:

function あ() {
 $い = 'あ';
 echo $い;
}
あ();