Juego de campos Javascript

[Panino5001]

En mi opinión los 3 tienen razón. La primera manera que muestra buzu soluciona varios de los problemas de referenciación, ya que tienen sentido event y this. La segunda no sirve para mucho en ese sentido, ya que para algunos navegadores this tiene otro significado. Lo cierto es que siempre es más complejo trabajar de esa forma y a veces podemos ceder a la tentación de colocar código inline para evitar complicaciones, sobre todo cuando un cliente nos contrató hoy para resolverle un problema para ayer, y al costo de anteayer. Por ejemplo, la simple validación onsubmit de un formulario se complica porque tenemos que limpiar las acciones por defecto y por 2 caminos distintos, como ya sabemos. O aplicar un simple onchange a un campo file para validarlo por ese camino puede ser otra pesadilla. Y los onmouseout y onmouseover pueden también traer algún trastorno. Y, como bien dice David, cuando un usuario te viene con un "me falla el window.open con el body onload" cómo explicarle todo esto sin meterlo en un laberinto del que no va a saber salir? Es cuando uno opta (yo muchas veces y lo confieso aunque sé que está mal) por no contestar o por (yo también muchas veces) por contestarle con código inline, que en definitiva es así como aprendí, y lo que me permitió luego seguir aprendiendo alentado por cada pequeña solución que iba encontrando a los problemas.
En definitiva, una web es tan efímera y todo cambia tan rápido que lo que creo es que, mientras no te aparezca el color rojo en el firebug o el triangulito en explorer y todo funcione siempre igual de rápido siempre, todo está bien, aún a sabiendas de que podría estar mejor.
En tu ejemplo, Buzu, acaso no podría venir a decirte alguien también que ninguna de tus soluciones contempla el problema de pérdida de memoria en Explorer 6ó-?
Lo cierto es que no hay una manera buena y otra mala de trabajar, hay mejores o peores, pero el único parámetro válido es si las cosas funcionan o no funcionan.