Mi rincón en Internet

A veces nos surge la necesidad de forzar que un enlace se abra en una ventana nueva o “popup”. El problema es que debemos mantener el HTML válido para que estos enlaces sean seguidos por motores de búsqueda o puedan ser utilizados por navegadores sin Javascript.

En todos los sitios se ve el típico tutorial que dice “… utiliza el window.open() de Javascript …“. Efectivamente, hay que usarlo, pero sin obstruir ni hacer HTML chapucillas.

Vamos a presentar 3 formas de abrir un “popup”, una “mala” y dos mejores.

1. Con HTML “guarrete”:

   <a href="#" 
       onclick="window.open('http://davidasorey.net',
           'popup1', 
           'height=800,width=600,resizable=1,scrolling=1')">Enlace 1</a>

   Fatal. El destino de este enlace está “falseado”. A veces también nos podemos encontrar algo como:

   <a href="javascript:void(0)">

   Esta forma de hacer los “popups” puede ser aceptable sólo si explícitamente queremos que este enlace no se siga.

2. Un poco mejor, dejando un href correcto:

   <a href="http://davidasorey.net" 
       target="popup2"
       onclick="window.open('', 
           'popup2', 
           'height=800,width=600,resizable=1,scrolling=1')">Enlace 2</a>

   Aquí jugamos con el atributo “target“. El evento “click” abre una ventana “vacía” pero con un identificador “popup2“. Cuando el navegador va a abrir el enlace, ya encuentra una ventana con este identificador y abre el enlace en esta nueva ventana.
   Es una mejora, desde luego: el enlace ya es un enlace “real” e indexable.

3. Una solución sin Javascript “inline”:

   <a class="popup3" href="http://davidasorey.net">Enlace 3</a>

   Obviamente, esta es la solución más limpia, pero requiere un poco más de trabajo adicional.
   Con jQuery (se puede hacer con cualquier otra librería o “framework”) hay que “capturar” todos los enlaces con la clase “popup3″ y alterar su comportamiento:

   $(document).ready(function (d) {
   	$('a.popup3').click(function (e) {
   		e.preventDefault();
   		var href = $(this).attr('href');
   		window.open(href, 
                              'popup3', 
                              'height=800,width=600,resizable=1,scrolling=1');
   	});
   });

   En pocas líneas alteramos el comportamiento de todos los enlaces con la clase ‘popup3‘. Nos ahorramos andar escribiendo el código Javascript en el evento onclick y todo el código y control de este comportamiento está en un sólo punto.

¿Qué versión os gusta más?

El uso de selectores CSS en los “frameworks” para JavaScript más conocidos ha permitido lo que hace unos años era impensable: los diseñadores entienden el código de los programadores y los programadores pueden comprender el CSS de los diseñadores.

jQuery es especialmente adecuado: no distingue entre selectores “por id” ni selectores por “clase” (Prototype tiene dos funciones diferentes, $() y $$(), para estas tareas).

$('.lateral a.externo').click(function(ev) {
    // Código  a ejecutar
})

Este sencillo código es fácil de entender y un diseñador al verlo rápidamente intuye que en todos los tags A dentro de la “capa” lateral que tengan la clase externo se hará algo al hacer click.

.lateral a.externo {color: red; padding: 5px; margin: 0;}

Este fragmento de CSS afecta a los mismos elementos que el javascript anterior. Un desarrollador enseguida ve también a qué elementos afecta.

Lo bueno es que si el diseñador y el programador hablan en el mismo lenguaje (selectores CSS), el desarrollo es muy fácil y se puede trabajar en paralelo fácilmente.

En la siguiente dirección, la gente que desarrolla el motor de JavaScript para el navegador Chrome tiene una serie de pruebas para medir el rendimiento de JavaScript de un navegador.

Como es previsible (es parte interesada, ¿no?), Chrome obtiene la mejor puntuación y el nuevo Safari 4 también obtiene una muy buena puntuación.

Lo curioso es que el resto de navegadores sacan mucha peor puntuación, como un orden de magnitud menos. A ver si busco más “benchmarks” de JavaScript y paso otra batería de pruebas.

También he incluido una captura de los IE 7 y 8 a título anecdótico. Se cuelgan en el test.

Actualizacion: he pasado el conjunto de “tests” que proponen en la web de Dromadeo con algunos navegadores. Ahora es Safari 4 el que gana, despues, Chrome.

Actualización II: Firefox 3.5beta gana bastante en rendimiento.

La aparición de estas librerías o “frameworks” para programar JavaScript han supuesto un ahorro de tiempo importante para los desarrolladores. Ya no hay que estar tan pendiente de las incompatibilidades entre navegadores, simplifican mucho el trabajo con el árbol DOM, etc.

Empecé a trabajar con Prototype un poco por “imposición técnica” y ya me pareció una maravilla el poder abstraerme de los XmlHttpRequest y demás. Desde hace un tiempo estoy empezando a profundizar más en jQuery, y, en mi opinión, me parece más cómodo y sencillo.

• En jQuery los selectores utilizan la sintaxis de CSS y son uniformes, es más claro — p. ej.: $(’#titulo’) ó $(’div.resaltado’) en Prototype serían $(’titulo’) y $$(’div.resaltado’).
• En jQuery las operaciones típicas como ocultar/mostrar un elemento o conjunto de elementos son más sencillas: da igual que nuestro selector nos devuelva un sólo elemento o un conjunto de ellos, el método es el mismo — p. ej.: $(’#titulo’).hide() ó $(’div.resaltado’).hide()
• Generalizando mucho, podemos decir que jQuery es más conciso y Prototype más explícito.