Resumen

  • El primer borrador público del W3C, en diciembre de 2012, planteó eventos independientes del hardware para ratón, lápiz y tacto, con un puente para las páginas escritas en torno al ratón.
  • La Recomendación de febrero de 2015 describió los eventos de puntero, pointerType, touch-action para gestos del navegador y la captura que mantiene un arrastre ligado a su elemento.

En el club del ratón, un botón conocía el clic y una barra deslizante seguía el cursor. Un dedo se presentó en la puerta y el portero le entregó, metafóricamente, bigotes postizos: para conservar las páginas antiguas, algunos navegadores emitían eventos de ratón por una acción táctil. Era útil hasta que el código tenía que saber quién había entrado de verdad.

El primer borrador público de Pointer Events del W3C, de 11 de diciembre de 2012, explicó el coste de añadir puertas separadas. Una aplicación escrita para Mouse Events debía repetir lógica para tacto y lápiz. Los eventos de ratón compatibles podían esconder el origen físico del gesto. El borrador propuso un puntero: una manera común de representar un contacto que señala una posición en la pantalla.

La palabra común no borra las herramientas. PointerEvent puede llevar pointerType, presión, tamaño del contacto e inclinación. Una noticia con un enlace solo necesita responder a la pulsación; un lienzo de dibujo puede aprovechar la presión del lápiz. El autor escribe primero el comportamiento compartido y consulta el detalle del dispositivo donde ese detalle mejora la tarea.

La Recomendación del W3C de 24 de febrero de 2015 fijó una familia con pointerdown, pointermove, pointerup y pointercancel, además de eventos al entrar y salir de una zona. Los nombres resultaban familiares para quien conocía los del ratón. Un identificador permite seguir el contacto correspondiente cuando hay más de uno. El salón siguió siendo reconocible, pero las nuevas personas encontraron su sitio.

El puente con el pasado también quedó descrito. La Recomendación contempla eventos de ratón compatibles para páginas que todavía los escuchan. Son una ayuda para que el contenido antiguo no se quede inmóvil ante una pantalla táctil. Al mismo tiempo, un Mouse Event puede ser la sombra de un dedo; pointerType permite que el código nuevo deje de adivinarlo.

Una discusión más difícil surge al mover el dedo. ¿Está arrastrando una tarjeta que diseñó la web o desplazando el documento que controla el navegador? Si el navegador espera a que un script decida cancelar cada movimiento, el desplazamiento puede sentirse pesado. touch-action permite declarar los comportamientos táctiles predeterminados que una región admite. Así el navegador puede decidir su propio desplazamiento con antelación.

La captura del puntero resuelve otro tropiezo. Una persona sujeta el tirador de un control y, mientras arrastra, sale de su pequeño rectángulo. El elemento puede seguir recibiendo los eventos de ese puntero hasta terminar la interacción. La norma de 2015 describe cómo tomar y soltar la captura y los avisos gotpointercapture y lostpointercapture. Un gesto no tiene por qué romperse porque el dedo trace una curva alegre.

El modelo conserva la textura de cada instrumento. Un dedo ocupa un área, un lápiz puede inclinarse y variar su presión, el ratón tiene botones. Los eventos compartidos reducen el código duplicado; las propiedades específicas siguen ahí para el trabajo que las necesita. Una aplicación de dibujo no tiene que renunciar a su lápiz para admitir también un ratón.

El historial de publicación del W3C para Pointer Events 1 sitúa el primer borrador público en diciembre de 2012 y la Recomendación en febrero de 2015. Es la historia documental de una solución a un problema cotidiano: páginas construidas para el ratón encontrándose con manos que tocaban y dibujaban directamente en la pantalla.

Para el lector, el acuerdo funciona cuando un botón responde, la página se desplaza con soltura y un arrastre no se pierde al cruzar una frontera invisible. El ratón conserva su asiento. Ya no dirige solo la lista de invitados.