UT4 — Integración de contenido interactivo¶

Índice¶

1. UT4-1: Elementos interactivos
2. UT4-2: Comportamientos interactivos. Comportamiento de los elementos
3. UT4-3: Ejecución de secuencias de comandos
4. UT4-4: Verificación del funcionamiento en distintos navegadores y dispositivos
5. Glosario rápido
6. Repaso: preguntas para autoevaluarte
7. De dónde sale esto (fuentes de la carpeta)

De qué va esta unidad¶

Hasta ahora, en el módulo, has aprendido a maquetar una página, a vestirla con CSS y a meterle imágenes, sonido y vídeo. Esta unidad da un paso más: hacer que la página reaccione a lo que hace la persona que la visita. Que un botón cambie de color al pasar el ratón, que un vídeo se reproduzca cuando alguien pulsa "play", que un formulario avise si te has dejado un campo vacío antes de enviarlo, que una tarjeta se levante un poco cuando pasas por encima... Todo eso es interactividad.

La unidad mezcla varias piezas que tienen que encajar: los elementos HTML5 que ya llevan interactividad "de fábrica" (como <video> o <audio>), las reglas CSS que simulan comportamiento sin necesitar ni una línea de programación, y JavaScript, el lenguaje que de verdad "escucha" lo que hace el usuario y reacciona mediante eventos. También veremos que hay que configurar bien el navegador (o prever que el usuario tiene el suyo configurado de una manera concreta: sin JavaScript, sin autoplay, con poca cobertura de códecs...) y que, al final, todo eso hay que comprobarlo en varios navegadores y dispositivos, porque lo que funciona perfecto en tu Chrome de escritorio puede fallar en el Safari del móvil de tu clienta.

Es una unidad corta en número de sesiones pero densa en contenido, porque mezcla HTML5 multimedia, CSS3 (transformaciones, transiciones y animaciones) y los fundamentos de JavaScript orientado a eventos. Como hilo conductor usaremos el proyecto del módulo, la web del Café Central: le añadiremos un vídeo de presentación, un reproductor de audio con la música ambiente del local, y algunas interacciones (menús que reaccionan al pasar el ratón, un formulario de reservas que valida antes de enviar, un botón de "play" propio).

Qué deberías saber hacer al terminar (resultados de aprendizaje)¶

El resultado de aprendizaje de esta unidad es el RA4: Integra contenido multimedia en documentos web valorando su aportación y seleccionando adecuadamente los elementos interactivos. En cristiano, al terminar deberías ser capaz de:

• Reconocer y explicar qué tecnologías se usan para meter contenido multimedia e interactivo en una web (HTML5, CSS3, JavaScript, formatos de audio/vídeo, WebVTT...).
• Saber qué necesita un navegador para reproducir bien el multimedia de tu página: códecs compatibles, políticas de autoplay, etc.
• Manejar herramientas gráficas (editores de vídeo/audio, generadores de animaciones CSS) para producir contenido interactivo, y entender el código que esas herramientas generan, no solo copiarlo y pegarlo a ciegas.
• Añadir elementos multimedia (vídeo, audio, subtítulos) a un documento web con el marcado correcto.
• Añadir interactividad real a los elementos de una página: comportamientos con CSS y con JavaScript, usando eventos del DOM.
• Verificar que todo lo anterior funciona en distintos navegadores y dispositivos, y saber qué hacer cuando no funciona igual en todos.

1. UT4-1: Elementos interactivos¶

Qué es un elemento interactivo¶

La definición que da el material de la unidad es sencilla y muy útil: un elemento interactivo es aquel que cambia cuando el usuario interactúa con él. Con esa definición tan amplia, resulta que ya conocías muchos elementos interactivos sin llamarlos así:

• Los enlaces (<a>): cambian de color según su estado (sin visitar, visitado, con el ratón encima, activo) y, al pulsarlos, deberían provocar algún cambio en la página.
• Los elementos de un formulario: cajas de texto, botones de opción (radio), casillas de verificación (checkbox), áreas de texto (textarea), listas desplegables (select) y botones. Todos cambian de aspecto o de contenido según lo que hace la persona usuaria.

Enlaces y elementos de formulario son los "ladrillos" básicos con los que se construyen cosas más complejas: foros, blogs, sistemas de comentarios, encuestas... Todos ellos son, en el fondo, combinaciones de elementos interactivos básicos.

Ejemplo propio — Café Central. El formulario de reservas del Café Central ("Nombre", "Nº de comensales", "Fecha", botón "Reservar") es un elemento interactivo compuesto: cada campo cambia cuando escribes en él, y el botón confirma la acción.

Los elementos multimedia como elementos interactivos avanzados¶

Además de los elementos "clásicos", HTML5 incorporó dos etiquetas que son, hoy, el corazón de la interactividad multimedia en la web: <video> y <audio>. Antes de HTML5 (con el material más antiguo de la unidad, de hacia 2013, como referencia histórica), el vídeo y el audio se incrustaban con <object> y <embed>, normalmente tirando de plugins como Flash o Silverlight. Esa solución funcionaba, pero daba problemas de seguridad, de accesibilidad y no encajaba bien con HTML/CSS. Hoy Flash está descatalogado (todos los navegadores dejaron de soportarlo) y no debe usarse: lo mencionamos solo como contexto histórico, para que entiendas por qué existen <video> y <audio> como alternativa nativa.

Un ejemplo mínimo de vídeo:

<video src="rabbit320.webm" controls>
  <p>
    Tu navegador no soporta HTML5 video. Aquí está el
    <a href="rabbit320.webm">enlace del video</a>.
  </p>
</video>

Lo importante:

• src: la ruta al archivo, igual que en <img>.
• controls: sin este atributo el usuario no tiene manera de controlar la reproducción (empezar, parar, subir/bajar el volumen). El material insiste en que esto es especialmente importante para personas con epilepsia, a quienes un vídeo que se reproduce solo y sin control puede sentarles muy mal.
• El texto o marcado que se pone dentro de <video>...</video> es el contenido de reserva (fallback): se muestra solo si el navegador no soporta el elemento.

Varias fuentes para que el vídeo funcione en todos los navegadores¶

Aquí aparece uno de los quebraderos de cabeza clásicos del vídeo web: no todos los navegadores admiten los mismos formatos. Un archivo de vídeo o audio va empaquetado en un formato contenedor (MP4, WebM, Ogg...) que agrupa una o varias pistas (vídeo, audio, subtítulos) codificadas cada una con un códec concreto. Según la documentación de MDN de la unidad:

Si al usuario le falta el códec adecuado, el vídeo no se reproduce, así de simple. La solución no es elegir "el formato bueno", sino ofrecer varios con el elemento <source>, para que el navegador escoja el primero que sea capaz de reproducir:

<video controls>
  <source src="rabbit320.mp4" type="video/mp4" />
  <source src="rabbit320.webm" type="video/webm" />
  <p>
    Su navegador no soporta vídeo HTML5. Aquí hay un
    <a href="rabbit320.mp4">enlace al video</a>.
  </p>
</video>

El atributo type de cada <source> es opcional pero muy recomendable: contiene el MIME type del archivo, y permite al navegador descartar de inmediato los vídeos que no podría reproducir, en lugar de tener que descargarlos para comprobarlo.

Figura: un archivo contenedor (aquí WebM) puede llevar dentro varias pistas de audio (idiomas distintos), varias pistas de vídeo (ángulos distintos) y varias pistas de texto (subtítulos en distintos idiomas). Origen: WEB - MDN - Contenido de vídeo y audio.pdf.

Figura: así se ve un <video controls> básico en el navegador: fotograma, botón de play y barra de controles nativos. Origen: WEB - MDN - Contenido de vídeo y audio.pdf.

Otros atributos útiles de <video> y <audio>¶

• width / height: tamaño del vídeo (solo aplica a <video>; <audio> no los admite porque no tiene componente visual).
• autoplay: hace que el vídeo empiece a reproducirse en cuanto es posible. El propio material recomienda no abusar de él, porque a la gente le resulta molesto que un vídeo empiece a sonar sin avisar.
• loop: repite la reproducción al terminar.
• muted: reproduce sin sonido por defecto.
• poster (solo <video>): imagen que se muestra antes de que arranque la reproducción, a modo de miniatura o cartel.
• preload: sugiere al navegador cuánto debe precargar antes de reproducir. Admite none (no precargar nada), metadata (solo duración y datos básicos) o auto (todo el archivo). El valor por defecto varía según el navegador; la especificación recomienda metadata.
• playsinline: pide que el vídeo se reproduzca dentro de su propio recuadro en la página, en lugar de a pantalla completa (relevante sobre todo en móviles).
• crossorigin: controla si se usa CORS para pedir el vídeo, algo necesario si luego quieres manipular el vídeo desde un <canvas>.

Configurar el navegador para multimedia: códecs y reproducción automática¶

Uno de los criterios de evaluación de esta unidad (b) habla explícitamente de identificar las necesidades de configuración de los navegadores para soportar contenido multimedia e interactivo. Dos aspectos concretos:

Códecs. Como hemos visto, si el navegador no trae el códec necesario, no reproduce el archivo. Por eso se recomienda ofrecer varias fuentes (<source>). El propio material de MDN explica por qué existe esta fragmentación: formatos como MP3 o H.264 son de excelente calidad y muy compatibles, pero están (o estuvieron) protegidos por patentes —la de MP3 hasta 2017 y la de H.264 hasta 2027, según cita el documento—, lo que llevó a algunos navegadores a preferir formatos abiertos como Vorbis o VP8/VP9.

Reproducción automática (autoplay). Los navegadores actuales bloquean por defecto el autoplay de cualquier medio que tenga sonido, precisamente porque resulta molesto que una pestaña empiece a sonar sola. Según la guía de autoplay de MDN incluida en la unidad, el audio solo se reproducirá automáticamente si se da alguna de estas condiciones:

• el audio está silenciado (muted) o su volumen es 0;
• el usuario ya ha interactuado con el sitio (clic, toque, tecla...);
• el sitio está en una lista blanca del navegador (automática, si detecta que el usuario suele consumir medios ahí, o manual, por preferencias);
• se ha concedido permiso explícito de autoplay mediante la cabecera Permissions-Policy: autoplay=(self) (también aplicable a un <iframe> con el atributo allow="autoplay").

La combinación recomendada para un vídeo de fondo que arranca solo es añadir muted (y, en Safari, también playsinline):

<video src="/videos/cafe-ambiente.webm" controls autoplay playsinline muted></video>

Para saber, desde JavaScript, si el autoplay está permitido, existe el método navigator.getAutoplayPolicy(), que puede devolver "allowed", "allowed-muted" o "disallowed"; y si se usa play() para arrancar la reproducción por script, el método devuelve una Promise que se rechaza si el navegador ha bloqueado el autoplay, lo que permite mostrar un botón de "reproducir" alternativo.

Ejemplo actual — vídeos de fondo silenciados. Fíjate la próxima vez que entres en la web de una marca de moda, un hotel o un restaurante con una gran cabecera de vídeo: casi siempre arranca sin sonido (muted) y con un icono para activarlo. Es exactamente la técnica que acabamos de ver, aplicada porque el navegador no dejaría reproducir audio sin que hayas interactuado antes con la página.

En las noticias — códecs modernos. En los últimos años, YouTube y Netflix han ido adoptando de forma progresiva códecs más eficientes como AV1 (sucesor libre de derechos de H.264/VP9) para ahorrar ancho de banda, según se ha informado en distintos medios especializados. Es el mismo problema que describe el material de la unidad —códecs distintos, soporte distinto según navegador y dispositivo— solo que unos años después.

Subtítulos y pistas de texto: <track> y WebVTT¶

Para que un vídeo llegue a más gente (personas sordas o con dificultades auditivas, personas en un entorno ruidoso o silencioso, personas que no hablan el idioma original), HTML5 permite añadir pistas de texto sincronizadas con el formato WebVTT y el elemento <track>. Un archivo .vtt tiene este aspecto:

WEBVTT

1
00:00:22.230 --> 00:00:24.606
Este es el primer subtítulo.

2
00:00:30.739 --> 00:00:34.074
Este es el segundo.

Y se enlaza así, dentro de <video> (o <audio>) y después de todos los <source>:

<video controls>
  <source src="example.mp4" type="video/mp4" />
  <source src="example.webm" type="video/webm" />
  <track kind="subtitles" src="subtitles_es.vtt" srclang="es" />
</video>

El atributo kind distingue el tipo de pista de texto:

• subtitles: traducción del diálogo, para quien no entiende el idioma original.
• captions (leyendas): transcripción del diálogo y descripción de sonidos relevantes, para quien no puede oír el audio.
• descriptions: descripciones pensadas para convertirse en audio, útiles para personas con discapacidad visual.

El atributo srclang indica el idioma en el que está escrita esa pista. Como propina, el material señala que las pistas de texto también ayudan al SEO, porque los buscadores "leen" ese texto y hasta pueden enlazar directamente a un punto concreto del vídeo.

Ejemplo actual — subtítulos por defecto. Netflix, YouTube o Disney+ ofrecen subtítulos en decenas de idiomas usando, en el fondo, la misma idea que <track> y WebVTT: archivos de texto con marcas de tiempo. Muchas plataformas educativas (Coursera, LinkedIn Learning) generan además subtítulos automáticos por reconocimiento de voz.

El elemento <audio>¶

<audio> funciona igual que <video> salvo por dos diferencias: no admite width ni height (no hay componente visual) y tampoco admite poster (por el mismo motivo). Por lo demás comparte atributos (controls, autoplay, loop, muted, preload) y el mismo patrón de varias fuentes:

<audio controls>
  <source src="viper.mp3" type="audio/mp3" />
  <source src="viper.ogg" type="audio/ogg" />
  <p>
    Su navegador no es compatible con audio HTML5. Aquí hay un
    <a href="viper.mp3">enlace al audio</a> en su lugar.
  </p>
</audio>

Figura: reproductor de <audio> con controles nativos del navegador: play, barra de progreso, volumen. Origen: WEB - MDN - Contenido de vídeo y audio.pdf.

Ejemplo propio — Café Central. Para la música ambiente de la web del Café Central podríamos usar <audio controls loop> con dos <source> (mp3 y ogg) para cubrir el mayor número de navegadores, dejando el volumen bajo por defecto y sin autoplay con sonido (que además, como hemos visto, el navegador bloquearía).

Y las imágenes, de paso¶

Aunque el foco de esta unidad es el vídeo, el audio y la interactividad, uno de los PDF de la carpeta repasa técnicas modernas para que la carga de imágenes no perjudique la experiencia interactiva de la página (se solapa en parte con la unidad de multimedia): el atributo srcset para servir la imagen adecuada según la resolución de pantalla (image.jpg, image@2x.jpg, image@3x.jpg), el elemento <picture> para elegir una imagen distinta según el ancho de la ventana, y las etiquetas <link rel="preload"> / <link rel="prefetch"> para indicarle al navegador qué recursos cargar antes. No son contenidos propios de esta UT, pero conviene tenerlos presentes porque usan la misma lógica que el vídeo con varias fuentes: ofrecer alternativas y dejar que el navegador elija la mejor.

<picture>
  <source media="(min-width:650px)" srcset="cafe_grande.jpg" />
  <source media="(min-width:465px)" srcset="cafe_mediano.jpg" />
  <img src="cafe_pequeno.jpg" alt="Terraza del Café Central" />
</picture>

Ideas clave de esta sección¶

• Un elemento interactivo es el que cambia cuando el usuario interactúa con él: enlaces, campos de formulario, y también <video> y <audio>.
• <video> y <audio> sustituyen a las viejas soluciones basadas en plugins (Flash, <object>/<embed>), hoy obsoletas.
• Como no todos los navegadores soportan los mismos formatos, se ofrecen varias fuentes con <source> (típicamente MP4 y WebM para vídeo).
• El autoplay con sonido está bloqueado por defecto en los navegadores modernos; la combinación segura es autoplay muted playsinline.
• <track> + WebVTT añaden subtítulos, leyendas o descripciones sincronizadas.

2. UT4-2: Comportamientos interactivos. Comportamiento de los elementos¶

Una vez que sabemos qué elementos pueden ser interactivos, toca dotarlos de comportamiento: que reaccionen de verdad ante lo que hace el usuario. El material de la unidad plantea dos caminos, complementarios entre sí:

1. Las reglas de estilo (CSS), para comportamientos vistosos que no necesitan programación.
2. Los lenguajes de programación dinámicos (JavaScript), para comportamientos que necesitan lógica real (lo veremos en el contenido UT4-3).

CSS como simulador de interactividad: las pseudoclases¶

Ya conoces de la unidad de estilos las pseudoclases :link, :visited, :hover, :active y :focus. Aplicadas con criterio, permiten simular interactividad sin una sola línea de JavaScript. Algunos usos clásicos que recoge el material:

/* Ejemplo propio, inspirado en las tarjetas de la carta del Café Central */
.tarjeta-plato:hover {
  transform: translateY(-4px);
  box-shadow: 0 8px 16px rgba(0, 0, 0, 0.2);
}

El material también recupera el término DHTML (HTML dinámico): la combinación de HTML estático + CSS + JavaScript + el modelo DOM. Es un término de los años 2000 que hoy casi no se usa como tal, pero la idea de fondo —combinar estas tres tecnologías para crear comportamiento— sigue siendo exactamente lo que hacemos ahora.

El salto moderno: transformaciones, transiciones y animaciones CSS3¶

Aquí es donde el material más reciente de la unidad amplía mucho las posibilidades respecto al material antiguo (que solo hablaba de pseudoclases). CSS3 incorporó tres herramientas relacionadas pero distintas para dar movimiento y cambio a los elementos:

• Transformaciones (transform): cambian un elemento (lo desplazan, lo rotan, lo deforman, lo escalan...) pero no implican movimiento en sí mismas; puede aplicarse y aparecer directamente el resultado final, sin animación.
• Transiciones (transition): el elemento pasa de un estado a otro de forma fluida. Solo se especifica el estado inicial, el final y una "función de tiempo", y el navegador calcula automáticamente los pasos intermedios. Se usan para cambios sencillos (color, tamaño, posición).
• Animaciones (animation + @keyframes): además del estado inicial y final, se pueden definir estados intermedios. Permiten animaciones bastante más complejas y detalladas que una transición.

Transformaciones:

.tarjeta {
  transform: rotate(20deg); /* gira */
}
.tarjeta {
  transform: skewY(20deg); /* sesga, estira */
}
.tarjeta {
  transform: scaleY(1.5); /* escala */
}

También existen transform-origin (para cambiar el punto desde el que se aplica la transformación) y transform-style (que define cómo se representan los elementos anidados en 3D: flat o preserve-3d).

Transiciones:

.boton {
  transition: background-color 0.3s ease-in-out 0s;
  /* transition: propiedad duración función-de-tiempo retraso */
}
.boton:hover {
  background-color: #c0392b;
}

Figura: propiedades que componen transition en CSS3. Origen: MULTIMEDIA - Animacion WEB.pdf.

Animaciones:

div {
  width: 100px;
  height: 100px;
  background: red;
  position: relative;
  animation: mymove 5s infinite;
}

@keyframes mymove {
  from { left: 0px; }
  to { left: 200px; }
}

Figura: propiedades de animation (name, duration, timing-function, delay, iteration-count, direction, fill-mode, play-state) y ejemplo con @keyframes. Origen: MULTIMEDIA - Animacion WEB.pdf.

Si no se especifica la duración de una animación, se entiende que es 0 y, por tanto, no se reproduce — un fallo típico de quien empieza con animation y se le "olvida" el segundo valor de la propiedad abreviada.

Transición frente a animación, en una frase: una transición va de un estado A a un estado B; una animación puede definir todos los estados intermedios que quieras, y también puede arrancar sola en cuanto carga la página (sin depender de un :hover o similar).

Figura: ejemplo visual de cómo transform-origin y transform-style cambian la posición y representación de elementos transformados. Origen: MULTIMEDIA - Animacion WEB.pdf.

Cuándo (no) usar animaciones¶

El material dedica un apartado entero a esto, y merece la pena resumirlo porque es consejo de diseño, no solo de código. Usadas bien, las animaciones pueden:

• evitar que el usuario abandone la página;
• crear una buena primera impresión;
• llamar la atención sobre algo concreto;
• reforzar la idea que se quiere transmitir;
• "guiar" el recorrido del usuario por la web;
• dar sensación de dinamismo y modernidad;
• comunicar un cambio de estado (por ejemplo, que algo se ha guardado);
• incitar al scrolling;
• hacer soportable una espera (indicadores de carga);
• evitar que el usuario piense que la página se ha "colgado".

Usadas mal, consiguen justo lo contrario: despistan, cansan la vista, generan rechazo en vez del efecto "wow" buscado, consumen recursos, ralentizan la carga, se ven mal en móvil y perjudican el SEO. La recomendación del material es clara: nunca animar "porque queda bonito"; preguntarse siempre por qué se anima, y no abusar.

Respecto a cómo hacerlas hoy, el material lista: HTML5 + CSS3 (lo que hemos visto), JavaScript/jQuery (manipulando elementos o el <canvas> de HTML5), imágenes animadas (GIF, pero también SVG o PNG animado) y, de nuevo como aviso histórico, Flash, que el propio material señala entre signos de exclamación como algo que "ni se os ocurra" usar hoy: penaliza el SEO y consume muchos recursos. Antes de usar cualquier librería de animación conviene comprobar que el navegador objetivo la soporta, y —salvo que sea imprescindible— es mejor apoyarse en librerías existentes que programar animaciones complejas desde cero.

Ejemplo actual — microinteracciones. El efecto de "elevar" una tarjeta de producto al pasar el ratón en tiendas online (Amazon, Etsy), los skeleton loaders (barras grises animadas mientras carga el contenido, muy usados en LinkedIn o YouTube) o el "like" que se anima al pulsarlo en Instagram son, en esencia, transiciones y animaciones CSS combinadas con algo de JavaScript.

En las noticias — View Transitions API. Chrome y otros navegadores basados en Chromium han ido incorporando, en los últimos años, la View Transitions API, una tecnología pensada para animar el cambio entre dos estados de una página (o incluso entre dos páginas) sin tener que programar a mano toda la coreografía. Según se ha informado en la documentación de los propios navegadores, es una evolución natural de la idea de "transición" que hemos visto en esta sección, llevada ahora a cambios de página completos.

Ideas clave de esta sección¶

• El comportamiento interactivo se puede dar con CSS (pseudoclases, transformaciones, transiciones, animaciones) o con JavaScript.
• transform cambia un elemento sin animarlo por sí solo; transition anima entre dos estados; animation (con @keyframes) permite estados intermedios y animaciones complejas.
• Las animaciones deben usarse con criterio: bien usadas mejoran la experiencia; mal usadas, la empeoran y penalizan rendimiento y SEO.
• Flash queda descartado por completo; es solo referencia histórica.

3. UT4-3: Ejecución de secuencias de comandos¶

Cuando el comportamiento que necesitamos ya no se puede resolver con CSS —por ejemplo, validar un formulario, reaccionar a una tecla concreta, o construir un reproductor de vídeo propio— entra en juego JavaScript, el lenguaje de guiones (scripts) que se ejecuta en el navegador de la persona usuaria.

Dónde escribir el código: en línea, incrustado o enlazado¶

Igual que ocurre con CSS, JavaScript se puede incluir de tres formas:

• En línea, mezclado directamente en un atributo del HTML. Es la forma más antigua y el material es tajante: no debe usarse. Ejemplo (histórico, para que reconozcas el patrón si lo ves en código antiguo):

<!-- Ejemplo histórico, no recomendado -->
<input type="text" name="fecha" onchange="validateDate(this);" />

• Incrustado, escribiendo el script dentro de una etiqueta <script> en el propio documento.
• Enlazado, en un archivo .js externo, vinculado en la cabecera:

<script src="miJavascript.js"></script>

El motivo para preferir el archivo externo es el mismo que con CSS: separar contenido (HTML), presentación (CSS) y comportamiento (JavaScript) hace el código más mantenible, y sobre todo evita problemas de accesibilidad: si un usuario tiene JavaScript desactivado, al menos el HTML y el CSS seguirán funcionando. Este principio se conoce como JavaScript no obstrusivo (unobtrusive JavaScript): el comportamiento se añade "por fuera", sin mezclarse con el marcado, de forma que si el script falla o no se carga, el resto de la página sigue siendo utilizable.

Eventos: la base de toda interactividad con JavaScript¶

Un evento es una señal que lanza el navegador cuando ocurre algo relevante: el usuario hace clic, pasa el ratón por encima, pulsa una tecla, se envía un formulario, un vídeo termina de reproducirse, la página acaba de cargar... Para reaccionar a un evento, se le asocia un detector de eventos (event listener), que llama a una función (manejador de eventos, o handler) cuando el evento se produce.

La forma recomendada hoy de registrar un manejador es el método addEventListener():

<button id="btn-color">Cambiar el color</button>

const btn = document.querySelector("#btn-color");

function random(number) {
  return Math.floor(Math.random() * (number + 1));
}

btn.addEventListener("click", () => {
  const rndCol = `rgb(${random(255)} ${random(255)} ${random(255)})`;
  document.body.style.backgroundColor = rndCol;
});

addEventListener() recibe dos argumentos: el nombre del evento a escuchar ("click", "mouseover", "keydown", "focus", "blur", "dblclick"...) y la función que debe ejecutarse. Su gran ventaja frente a otras formas de registrar eventos es que permite añadir varios manejadores al mismo evento sin que se pisen entre sí:

myElement.addEventListener("click", functionA);
myElement.addEventListener("click", functionB);
// Ambas se ejecutan al hacer clic

Y se puede quitar un manejador con removeEventListener(), siempre que se le pase una referencia a la misma función que se usó para añadirlo.

Existen otras dos formas de registrar eventos, que conviene conocer pero evitar:

• Propiedades de manejador de eventos (btn.onclick = miFuncion;): más simples, pero solo permiten un manejador por evento (el segundo onclick que asignes sobrescribe al primero).
• Atributos HTML de manejador de eventos (<button onclick="miFuncion()">): el método más antiguo, hoy considerado mala práctica por el mismo motivo que ya vimos con el onchange en línea: mezcla HTML y JavaScript, es difícil de mantener a partir de unos pocos elementos, y muchas configuraciones de servidor lo bloquean por seguridad.

El objeto evento y el DOM¶

Cuando se ejecuta un manejador, el navegador le pasa automáticamente un objeto evento (normalmente llamado event, evt o e), con información sobre lo ocurrido. Su propiedad más usada es target, que siempre apunta al elemento sobre el que se produjo el evento:

function bgChange(e) {
  const rndCol = `rgb(${random(255)} ${random(255)} ${random(255)})`;
  e.target.style.backgroundColor = rndCol;
}
btn.addEventListener("click", bgChange);

Para localizar elementos del documento y acceder a sus propiedades, JavaScript usa el DOM (Document Object Model): el modelo que representa cada etiqueta HTML como un objeto, organizado en una jerarquía (Navegador → Ventana → Documento → elementos). Cuando un elemento tiene un id único, es fácil acceder a él:

document.getElementById("contenido");

Cuando hay varios elementos del mismo tipo (por ejemplo, varios <div>), se puede acceder a todos ellos como una colección y recorrerla:

document.getElementsByTagName("div")[1]; // el segundo <div> del documento (empieza en 0)

Hoy, además de estos métodos clásicos, es habitual usar querySelector() y querySelectorAll(), que aceptan selectores CSS y son más flexibles:

const buttons = document.querySelectorAll("button");
for (const button of buttons) {
  button.addEventListener("click", bgChange);
}

Algunos eventos, como click, están disponibles en casi cualquier elemento; otros son específicos de ciertos elementos. Un caso muy relacionado con el contenido de esta unidad: el evento play solo tiene sentido en elementos con capacidad de reproducción, como <video> o <audio>. De hecho, los elementos multimedia HTML5 disparan una batería completa de eventos propios que puedes aprovechar para construir un reproductor a medida: play, pause, ended, timeupdate (se actualiza el tiempo de reproducción), volumechange, loadedmetadata, canplay, error...

// Ejemplo propio: reproductor a medida para el vídeo del Café Central
const video = document.querySelector("#video-cafe");
const btnPlay = document.querySelector("#btn-play");

btnPlay.addEventListener("click", () => {
  video.paused ? video.play() : video.pause();
});

video.addEventListener("ended", () => {
  btnPlay.textContent = "Volver a reproducir";
});

Validar formularios: el caso de uso más habitual¶

La validación de formularios es, según el material, uno de los usos más frecuentes de JavaScript: comprobar que los campos obligatorios están rellenos y que los que siguen un patrón (una fecha, un correo electrónico) son correctos, antes de enviarlos al servidor. Esto mejora la experiencia porque el usuario recibe el aviso al instante, sin esperar a un viaje de ida y vuelta al servidor.

<form action="#">
  <div>
    <label for="fname">Nombre: </label>
    <input id="fname" type="text" />
  </div>
  <div>
    <label for="lname">Apellido: </label>
    <input id="lname" type="text" />
  </div>
  <div>
    <input id="submit" type="submit" />
  </div>
</form>
<p></p>

const form = document.querySelector("form");
const fname = document.getElementById("fname");
const lname = document.getElementById("lname");
const para = document.querySelector("p");

form.addEventListener("submit", (e) => {
  if (fname.value === "" || lname.value === "") {
    e.preventDefault(); // evita que el formulario se envíe
    para.textContent = "¡Debes completar ambos nombres!";
  }
});

preventDefault() es el método que se llama sobre el objeto evento para cancelar el comportamiento por defecto de un evento —en este caso, el envío del formulario—. Es importante recalcar una advertencia que hacen ambos materiales, el antiguo y el actual: la validación en el cliente nunca sustituye a la validación en el servidor. Un usuario con JavaScript desactivado (o con malas intenciones) puede saltarse por completo la comprobación del navegador, así que el servidor siempre debe volver a comprobar los datos.

Ejemplo propio — Café Central. El formulario de reservas podría validar, antes de enviarse, que la fecha elegida no sea anterior a hoy y que el número de comensales sea mayor que 0, usando exactamente el patrón submit + preventDefault() de arriba —y, por supuesto, repitiendo esa comprobación en el servidor.

En las noticias — accesibilidad y JavaScript. En los últimos años se han multiplicado las demandas y quejas por accesibilidad web (por ejemplo, bajo leyes como la ADA en EE. UU. o el Real Decreto de accesibilidad en España) contra sitios cuyas interacciones solo funcionaban con ratón y no con teclado. Un manejador de eventos que solo escucha click y no keydown/keyup deja fuera a quien navega solo con teclado: un buen motivo práctico para pensar la interactividad más allá del ratón.

Ideas clave de esta sección¶

• JavaScript se debe enlazar en un archivo externo, no mezclarlo en línea con el HTML (principio de JavaScript no obstrusivo).
• addEventListener() es la forma recomendada de manejar eventos; permite varios manejadores por evento y se puede revertir con removeEventListener().
• El objeto evento (event/e) da acceso, entre otras cosas, al elemento que originó el evento (e.target).
• document.getElementById, getElementsByTagName o querySelector permiten acceder a elementos del DOM para leer o cambiar sus propiedades.
• La validación de formularios en el cliente mejora la experiencia, pero nunca sustituye a la validación en el servidor.
• Los elementos <video>/<audio> disparan eventos propios (play, pause, ended, timeupdate...) muy útiles para construir reproductores personalizados.

4. UT4-4: Verificación del funcionamiento en distintos navegadores y dispositivos¶

Ya tenemos vídeo, audio, animaciones CSS y JavaScript funcionando en nuestro equipo. El último paso —y el que cierra el círculo de esta unidad— es comprobar que todo eso sigue funcionando fuera de nuestro ordenador. Es lo que se conoce como pruebas entre navegadores (cross-browser testing): la práctica de asegurarse de que una web funciona en distintos navegadores y dispositivos.

Por qué falla lo mismo en sitios distintos¶

El material identifica varias causas típicas de que algo funcione en un navegador y en otro no:

• Bugs o implementaciones distintas de la misma característica en distintos navegadores. Hoy es mucho menos habitual que en los años 90 (cuando Internet Explorer 4 y Netscape 4 competían implementando las cosas a propósito de forma distinta), pero todavía ocurre.
• Distinto nivel de soporte de una tecnología: algunas funcionalidades muy nuevas ("bleeding edge") aún no están implementadas en todos los navegadores, o hay que dar soporte a navegadores antiguos que se quedaron "congelados" antes de que esa función existiera.
• Limitaciones del propio dispositivo: una web pensada para escritorio puede verse diminuta en un móvil, o un montón de animaciones pesadas pueden ir fluidas en una tablet potente y a trompicones en un dispositivo de gama baja.

No es realista (ni necesario) que una web se vea y se comporte exactamente igual en absolutamente todos los navegadores y dispositivos: lo importante es que la funcionalidad principal sea accesible de alguna manera en todos ellos, aunque el "envoltorio" visual varíe. Conviene, además, acordar con quien encarga el proyecto qué rango de navegadores y dispositivos se van a soportar: no tiene sentido (ni es viable en tiempo/coste) intentar cubrirlos todos.

El flujo de trabajo de las pruebas¶

El material propone un flujo de cuatro fases que se repiten tantas veces como haga falta durante el desarrollo:

Planificación inicial → Desarrollo → Pruebas/descubrimiento → Corrección/iteración

1. Planificación inicial: junto con quien encarga el proyecto, se decide qué debe incluir la web y, muy importante para esta unidad, qué navegadores y dispositivos usa el público objetivo. El propio material pone como ejemplo una tienda online que da servicio a clientela de Norteamérica: debería, como mínimo, funcionar en las últimas versiones de Chrome (y navegadores basados en el mismo motor, como Edge y Opera), Firefox y Safari, además de cumplir el nivel de accesibilidad WCAG AA. Para consultar qué navegadores soportan una tecnología concreta, el propio material recomienda dos fuentes: la documentación de MDN y la web caniuse.com.
2. Desarrollo: dividido en módulos manejables (cabecera, ficha de producto, carrito, formulario...), probando cada parte antes de darla por cerrada, no dejándolo todo para el final.
3. Pruebas/descubrimiento: primero un chequeo rápido en un par de navegadores estables (Firefox, Safari, Chrome o Edge), algo de accesibilidad básica (navegar solo con teclado, probar con un lector de pantalla) y una prueba en una plataforma móvil (Android o iOS). Después se amplía la lista de navegadores y dispositivos objetivo.
4. Corrección/iteración: una vez localizado un fallo, hay que acotarlo (¿en qué navegador, versión, dispositivo ocurre?), comprobar si el fallo es del propio navegador (y, en ese caso, si ya está reportado o corregido en una versión más reciente) o si es responsabilidad de nuestro código. Si el problema solo aparece en un navegador concreto, se recomienda aislar el arreglo (por ejemplo, con detección de características) en vez de cambiar el código para todos.

Cómo probar en la práctica¶

El material distingue varias formas de organizar las pruebas, de menos a más recursos necesarios:

• Hacerlo tú mismo/a (con el equipo, si trabajas en grupo), preferiblemente en dispositivos físicos reales.
• Emuladores y máquinas virtuales, cuando no tienes a mano todo el hardware necesario (por ejemplo, Windows no permite tener varias versiones instaladas a la vez en el mismo equipo, así que las máquinas virtuales son casi la única opción ahí).
• Grupos de usuarios: amistades, compañeros de otro departamento, o servicios de pruebas con usuarios reales pagados.
• Herramientas de automatización, cuando el proyecto crece: frameworks como Selenium permiten cargar la web automáticamente en varios navegadores y comprobar, por ejemplo, que un botón hace lo que debe o comparar capturas de pantalla entre navegadores. Existen también servicios comerciales especializados en esto, como Sauce Labs o BrowserStack, que suelen integrarse en flujos de integración continua (el código se prueba automáticamente antes de aceptarse en el repositorio).

El material también menciona que es buena idea probar en versiones preliminares de los navegadores cuando se usan tecnologías muy recientes: Firefox Developer Edition, Microsoft Edge Insider, Safari Technology Preview, Chrome Canary u Opera Developer. Y, si al final el fallo resulta ser del propio navegador, lo correcto es reportarlo (Firefox tiene Bugzilla; Chrome, Safari y Opera tienen sus propios canales).

Conectando con lo anterior: probar también el multimedia y la interactividad¶

Este contenido cierra el círculo de la unidad porque hay que verificar, específicamente, todo lo que hemos ido montando en las secciones anteriores:

• ¿Se reproduce el vídeo/audio en todos los navegadores objetivo? (recuerda la tabla de contenedores y códecs de la sección 1: si solo ofreces un <source> en WebM, Safari se quedará sin reproducirlo).
• ¿Se comporta igual el autoplay en cada navegador? (las políticas de autoplay no son idénticas en todos).
• ¿Se ven los subtítulos con <track>?
• ¿Funcionan las animaciones y transiciones CSS igual, o hay que añadir alguna alternativa para navegadores más antiguos?
• ¿Responden los manejadores de eventos igual con ratón, teclado y pantalla táctil?

Ejemplo actual — el fin de Internet Explorer. Microsoft retiró definitivamente el soporte de Internet Explorer 11 en junio de 2022, lo que simplificó mucho la matriz de pruebas de la mayoría de equipos de desarrollo web: durante años, IE fue el navegador que más "excepciones" y parches necesitaba, precisamente por implementar muchas cosas de forma distinta al resto.

En las noticias — caniuse.com y las nuevas funciones CSS. Cuando en 2023 los navegadores fueron incorporando el selector CSS :has() (el llamado "selector padre"), muchos equipos de desarrollo consultaron precisamente caniuse.com —la herramienta que recomienda el material de esta unidad— para saber a partir de qué versión de cada navegador podían usarlo con seguridad en producción.

Ideas clave de esta sección¶

• Las pruebas entre navegadores no buscan que todo se vea idéntico en todas partes, sino que la funcionalidad esencial esté disponible en todos los navegadores y dispositivos acordados con el cliente.
• El flujo recomendado es: planificar → desarrollar → probar → corregir, repitiéndolo por cada parte del proyecto, no solo al final.
• Se puede probar a mano, con emuladores/máquinas virtuales, con grupos de usuarios o con automatización (Selenium, BrowserStack, Sauce Labs...).
• MDN y caniuse.com son las referencias que cita el propio material para consultar el soporte de una tecnología en cada navegador.

Glosario rápido¶

Repaso: preguntas para autoevaluarte¶

1. ¿Qué diferencia hay entre <video src="../..."> con un único archivo y usar varios <source> dentro de <video>? ¿Por qué se recomienda esta segunda opción?
2. Cita al menos tres condiciones bajo las que un navegador sí permite el autoplay con sonido.
3. ¿Para qué sirve el elemento <track> y qué formato de archivo usa?
4. Explica con tus palabras la diferencia entre transform, transition y animation en CSS3.
5. ¿Por qué se desaconseja el uso de manejadores de eventos "en línea" (por ejemplo, onclick="..." dentro del HTML)?
6. ¿Qué hace addEventListener() que no pueda hacer asignar directamente elemento.onclick = miFuncion?
7. En un formulario, ¿qué método del objeto evento se usa para impedir que se envíe si detectamos un dato incorrecto? ¿Por qué no basta con validar solo en el cliente?
8. Explica qué son los "elementos de reserva" (fallback content) en <video> y por qué son importantes.
9. Nombra al menos dos herramientas o servicios que se pueden usar para automatizar las pruebas en distintos navegadores.
10. ¿Por qué se recomienda usar animaciones "con criterio" en lugar de usarlas siempre que sea posible? Cita al menos dos efectos negativos de un mal uso.

De dónde sale esto (fuentes de la carpeta)¶

• DIW08.pdf — material histórico (hacia 2013) sobre elementos interactivos, DHTML, pseudoclases CSS, DOM clásico (getElementById, getElementsByTagName) y las bases de JavaScript no obstrusivo. Usado sobre todo para el contenido UT4-1 y UT4-2, marcando como obsoleto lo relativo a <object>/<embed>/Flash.
• WEB - MDN - Contenido de vídeo y audio.pdf — documentación actual de MDN sobre <video>, <audio>, <source>, formatos/códecs y <track>/WebVTT. Fuente principal del contenido UT4-1.
• WEB - MDN - Elemento video.pdf y WEB - MDN - Elemento audio.pdf — referencia detallada de atributos (autoplay, controls, poster, preload, playsinline, crossorigin...) y eventos (play, pause, ended, timeupdate...) de <video> y <audio>. Complementan la sección UT4-1 y sirven de puente hacia los eventos de UT4-3.
• WEB - MDN - Reproducción automática (autoplay).pdf — guía de MDN sobre políticas de autoplay, el atributo autoplay, Navigator.getAutoplayPolicy() y la cabecera Permissions-Policy. Usado en UT4-1.
• MULTIMEDIA - Animacion WEB.pdf — diapositivas sobre transformaciones, transiciones y animaciones CSS3, y sobre el buen y mal uso de las animaciones web. Fuente principal de UT4-2.
• WEB - MDN - Introducción a los eventos.pdf — documentación de MDN sobre eventos, addEventListener(), el objeto evento y preventDefault(). Fuente principal de UT4-3.
• WEB - MDN - Pruebas en distintos navegadores.pdf — introducción de MDN al cross-browser testing: por qué ocurren los problemas entre navegadores, flujo de trabajo de pruebas y herramientas de automatización. Fuente principal de UT4-4.
• 3 MULTIMEDIA - Imagenes - Html-Css-JavaScript.pdf — técnicas de carga de imágenes responsive (srcset, <picture>, preload/prefetch). Se solapa más con la unidad de multimedia (UT3) que con esta; se ha usado solo de forma puntual en UT4-1 como complemento, sin dedicarle un contenido propio.

Avisos:

• Los cuatro contenidos de la programación (UT4-1 a UT4-4) están cubiertos con material suficiente en los PDF de la carpeta.
• DIW08.pdf es sensiblemente más antiguo (hacia 2013) que el resto del material; donde ha discrepado con la documentación MDN más reciente (por ejemplo, el uso de plugins como Flash, o getElementById/getElementsByTagName frente a querySelector), se ha priorizado la fuente reciente y se ha señalado lo antiguo como contexto histórico, tal y como pedía el encargo.
• El PDF 3 MULTIMEDIA - Imagenes - Html-Css-JavaScript.pdf encaja mejor, por contenido, con la unidad de multimedia (UT3) que con esta UT4; se ha aprovechado solo de forma breve y marcada como complemento, sin forzarlo en ninguno de los cuatro contenidos.
• No se han encontrado en la carpeta imágenes sueltas (solo las embebidas en los PDF); se han usado 6 imágenes aprovechables tras filtrar logotipos, iconos y capturas ilegibles. Es un número algo por debajo del objetivo orientativo de 8-20, pero no había más figuras de calidad suficiente en el material disponible.