Bloque III · Tema 7 · Cuerpo de Técnicos Auxiliares de Informática
Así lo numera la convocatoria: Bloque III. Desarrollo de sistemas. En nuestro temario es el tema 21 de 33.
Aplicaciones web. Desarrollo web front-end y en servidor, multiplataforma y multidispositivo. Lenguajes: HTML, XML y sus derivaciones. Navegadores y lenguajes de programación web. Lenguajes de script.
El tema MÁS preguntado de los 33, y el que no pide definiciones sino leer código: cuál de estos cuatro XML está bien formado, qué pinta este bloque de CSS, qué imprime esta línea de JavaScript. Va entero con fragmentos y con el porqué de los tres distractores: la estructura HTML5 con su DOCTYPE, las etiquetas semánticas y la accesibilidad del marcado, XML bien formado frente a válido con DTD y XSD, JSON según la RFC 8259, los selectores de CSS y la especificidad, la igualdad doble frente a la triple de JavaScript, Angular, PHP, Razor y el renderizado en servidor.
Tema desarrollado para el ejercicio único del Cuerpo de Técnicos Auxiliares de Informática de la Administración del Estado. Es el tema 7 del bloque III «Desarrollo de sistemas», que en nuestra numeración interna es el tema 21 de 33.
Cuánto pesa y cómo pregunta. Es, con diferencia, el tema más preguntado de los 33: 158 preguntas oficiales lo tocan. Y pregunta de una forma muy particular que conviene entender antes de empezar: casi nunca pide definiciones, pide leer código. Cuál de estos cuatro fragmentos de XML está bien formado. Qué muestra en pantalla este bloque de CSS. Qué imprime esta línea de JavaScript. Qué etiqueta pone el encabezado de una columna. Cuál de estos cuatro selectores aplica el color a los enlaces que cuelgan de un elemento de lista.
Eso tiene una consecuencia práctica: este tema no se aprueba leyendo, se aprueba mirando código hasta reconocerlo de un vistazo. Por eso el apunte va lleno de fragmentos, y cada uno lleva al lado por qué las otras tres opciones están mal, que es donde el tribunal esconde la dificultad. Los errores que usa son siempre de la misma familia: una etiqueta que cierra con otro nombre, un atributo sin comillas, un elemento inventado que suena razonable —<theader>, <container>, mandatory—, o una propiedad real con el valor equivocado.
Las cinco cosas que más ha preguntado, para saber por dónde empezar: la estructura mínima de un documento HTML5 con su DOCTYPE, qué hace bien formado a un XML, los selectores y la especificidad de CSS, la comparación estricta de JavaScript y la accesibilidad del marcado, que ya ha caído tres veces y va a más.
Índice
- La aplicación web
- El navegador por dentro
- HTML
- XHTML y la familia del marcado
- XML
- JSON
- CSS
- JavaScript
- Bibliotecas y marcos de trabajo
- El lado del servidor
- Dónde se pinta la página
- Multiplataforma y multidispositivo
- Seguridad en el desarrollo web
- Probar el front-end
- Cuadros para memorizar
- Lo que ya ha preguntado el tribunal
1. La aplicación web
1.1. Qué es y en qué se distingue
Una aplicación web es una aplicación cliente/servidor cuyo cliente es el navegador y cuyo protocolo es HTTP. Esa definición, que parece obvia, es la que explica todas sus ventajas y todas sus limitaciones.
| A favor | En contra |
|---|---|
| No hay que instalar nada en el puesto, ni actualizar nada. Se despliega una vez y todos ven la versión nueva. | Depende de la red: sin conexión no hay aplicación, salvo que se programe expresamente para funcionar sin ella. |
| Multiplataforma de serie: funciona en cualquier sistema que tenga un navegador. | Acceso limitado al equipo: el navegador aísla la página del sistema por seguridad, y llegar al hardware exige permiso explícito del usuario. |
| Acceso desde cualquier sitio, que es lo que hace posible la sede electrónica. | Diferencias entre navegadores: lo que funciona en uno puede no funcionar igual en otro. |
| Control central de los datos y de la seguridad. | Latencia: cada interacción que necesite al servidor cuesta un viaje de ida y vuelta. |
Conviene separar tres cosas que se confunden: una página web es un documento; un sitio web es un conjunto de páginas relacionadas; y una aplicación web es un programa que se usa a través del navegador, con estado, lógica e interacción. La sede electrónica de un ministerio es un sitio; el formulario de solicitud que hay dentro es una aplicación.
1.2. El recorrido de una página, de la dirección al píxel
Este recorrido ordena el tema entero, porque cada paso corresponde a un apartado del programa oficial:
- El usuario teclea una dirección. El navegador la descompone en protocolo, dominio, puerto, ruta y parámetros.
- Resuelve el nombre del dominio a una dirección de red y abre la conexión, cifrada si el protocolo es HTTPS.
- Envía una petición HTTP y el servidor devuelve un documento HTML.
- El navegador analiza ese HTML y va construyendo el DOM, el árbol de objetos que representa el documento.
- Al encontrar referencias a hojas de estilo, guiones, imágenes y tipografías, pide cada recurso por separado. Una página normal son decenas de peticiones, no una.
- Con el HTML y el CSS combinados calcula qué se ve y dónde, y pinta.
- El JavaScript entra en escena: reacciona a lo que hace el usuario, modifica el DOM y pide más datos al servidor sin recargar la página.
Dos consecuencias que se preguntan indirectamente: el HTML dice qué es cada cosa, el CSS cómo se ve y el JavaScript qué hace —esa separación de responsabilidades es el principio de diseño de toda la web—; y el rendimiento percibido depende más del número de peticiones y del peso de los recursos que de la velocidad del servidor.
1.3. Front-end y back-end
| Front-end | Back-end | |
|---|---|---|
| Dónde se ejecuta | En el navegador del usuario | En el servidor |
| Lenguajes | HTML, CSS y JavaScript (y TypeScript, que se traduce a JavaScript) | Java, C#, PHP, Python, Go, Node.js… |
| De qué responde | Presentación, interacción, accesibilidad, validación inmediata | Lógica de negocio, persistencia, seguridad real, integración |
| Quién lo controla | El usuario: puede leerlo y modificarlo entero | La organización |
🚨 El tribunal preguntó en 2023 cuál de cuatro lenguajes está relacionado con el desarrollo en back-end, y la respuesta era GO. Los otros tres son la trampa exacta de este apartado: SASS es un preprocesador de estilos —front-end—, XML es un lenguaje de marcado de datos y no de programación, y ANGULAR es un marco de trabajo de front-end. La lección: en una lista mezclada hay que preguntarse dos cosas seguidas, ¿es un lenguaje de programación? y, si lo es, ¿dónde se ejecuta?
⚠️ Y la regla de seguridad que atraviesa todo el tema, porque se deduce de la última fila de la tabla: nada de lo que ocurre en el front-end es fiable. La validación del formulario, el campo oculto, la comprobación de permisos en el guion: todo es cortesía para el usuario honrado y no protege de nadie. Toda comprobación que importe se repite en el servidor.
2. El navegador por dentro
2.1. Los motores de renderizado
Un navegador no es un programa monolítico: lo importante es su motor de renderizado, que interpreta el HTML y el CSS y decide qué se pinta, y su motor de JavaScript, que ejecuta el código. Que dos navegadores compartan motor explica que se comporten igual.
🚨 El tribunal preguntó en 2023 cuál es el motor web desarrollado por la Fundación Mozilla, y la respuesta es Gecko. El distractor fino era Firefox, que es el navegador, no el motor: esa es exactamente la distinción que la pregunta mide.
| Motor de renderizado | De quién | Navegadores | Motor de JavaScript |
|---|---|---|---|
| Gecko | Mozilla Foundation | Firefox | SpiderMonkey |
| Blink | Google (derivado de WebKit) | Chrome, Edge, Opera, Brave | V8 |
| WebKit | Apple | Safari | JavaScriptCore |
Dos datos que se preguntan de rebote: Edge dejó de tener motor propio y usa Blink, de modo que hoy la web se pinta esencialmente con tres motores; y V8, el motor de JavaScript de Chrome, es el mismo que hace funcionar Node.js en el servidor, que es la razón por la que el mismo lenguaje sirve en los dos lados.
2.2. El DOM y el proceso de pintado
El DOM (Document Object Model) es la representación del documento como un árbol de objetos que el navegador construye al leer el HTML y que los guiones pueden consultar y modificar. Es una recomendación del W3C y es la pieza que conecta los tres lenguajes: el HTML lo crea, el CSS lo decora y el JavaScript lo manipula.
El proceso completo, con los nombres que a veces se preguntan:
- Análisis del HTML y construcción del DOM.
- Análisis del CSS y construcción del árbol de estilos.
- Combinación de los dos en el árbol de renderizado, que contiene solo lo que se ve.
- Maquetación: calcular la posición y el tamaño de cada caja.
- Pintado y composición de capas.
Un detalle con consecuencias prácticas: un guion bloquea el análisis del HTML mientras se descarga y ejecuta, porque podría modificar el documento. De ahí las dos formas de evitarlo —pedir que el guion se descargue en paralelo y se ejecute al final, o que se ejecute en cuanto esté listo—, y de ahí la vieja costumbre de poner los guiones al final del cuerpo.
2.3. Almacenamiento en el cliente y cookies
HTTP no tiene memoria, así que el navegador necesita guardar cosas. Las tres formas, que se preguntan por sus diferencias:
| Cookie | localStorage | sessionStorage | |
|---|---|---|---|
| Tamaño | Unos 4 KB | Varios megabytes | Varios megabytes |
| ¿Viaja al servidor? | Sí, en cada petición | No | No |
| Duración | La que se le fije; sin fecha, hasta cerrar el navegador | Persiste hasta que se borre | Muere al cerrar la pestaña |
| Para qué | Sesión y estado que el servidor necesita | Preferencias, datos del cliente | Datos de un solo uso |
🚨 Y los atributos de seguridad de la cookie, que el tribunal ha preguntado TRES veces por separado. Es un apartado especialmente rentable porque las tres preguntas se contestan con la misma tabla:
| Atributo | Qué hace exactamente | Contra qué protege |
|---|---|---|
| HttpOnly | 🚨 JavaScript NO puede acceder a la cookie. Preguntado en 2023 y en 2026. | XSS: aunque inyecten un guion, no podrán robar la cookie de sesión. |
| Secure | La cookie solo se envía por conexión cifrada. | Que viaje en claro y la lea quien esté escuchando. |
| SameSite | 🚨 El navegador solo envía la cookie si se originó en el mismo sitio al que se está contactando. Preguntado en 2023. | Falsificación de petición entre sitios. |
| Domain y Path | Para qué dominio y qué rutas vale. | Limitan el alcance, no son una defensa por sí solos. |
| Expires / Max-Age | Cuánto dura. | Reducen la ventana de una cookie robada. |
⚠️ HttpOnly y Secure se confunden y son cosas distintas: Secure protege la cookie EN EL CAMINO —que no viaje sin cifrar— y HttpOnly la protege EN EL NAVEGADOR —que no la lea un guion—. Amenazas distintas, defensas distintas, y se ponen las tres junto a SameSite.
3. HTML
3.1. De dónde viene y quién manda hoy
HTML (HyperText Markup Language) es el lenguaje de marcado con el que se estructura el contenido de una página. No es un lenguaje de programación: no tiene variables, ni condicionales, ni bucles. Marca qué es cada trozo de contenido, y de ahí sale todo lo demás.
Su genealogía se pregunta de vez en cuando y conviene tenerla: desciende de SGML, el metalenguaje de marcado normalizado en los años ochenta del que también sale XML. Sus versiones relevantes son HTML 4.01, la de finales de los noventa; XHTML, la reformulación en XML; y HTML5, la actual.
⚠️ Y un detalle de gobernanza que el tribunal ya ha usado en un enunciado: hoy la especificación viva es el HTML Living Standard del WHATWG, un estándar sin número de versión que se actualiza de forma continua. El W3C publicó HTML5 como recomendación y hoy trabaja de acuerdo con el WHATWG en ese documento único. Por eso los enunciados citan indistintamente «el estándar HTML5 del W3C» y «el HTML Living Standard de WHATWG»: hablan de lo mismo.
3.2. La estructura de un documento
🚨 De aquí han salido dos preguntas en los dos modelos de 2026, o sea cuatro. La primera pedía en qué posición debe aparecer la declaración DOCTYPE, y la respuesta es en la primera línea, antes del elemento raíz. La segunda pedía cuál de cuatro estructuras HTML5 es válida.
La estructura mínima correcta, que hay que saber escribir de memoria:
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>EducaData</title>
</head>
<body>
<div id="alumnos"></div>
</body>
</html>
Cada pieza, con lo que pasa si falta:
- La declaración de tipo de documento va la primera, antes de todo, y en HTML5 es corta: solo html, sin la larga referencia a un DTD que llevaban HTML 4 y XHTML. No es una etiqueta: es una instrucción para el navegador, y su ausencia lo hace entrar en modo de compatibilidad, en el que emula el comportamiento de navegadores antiguos y la página se ve distinta.
- El elemento raíz es html, y conviene que lleve el atributo de idioma: los lectores de pantalla lo usan para elegir la pronunciación.
- La cabecera contiene lo que no se ve: la codificación de caracteres —sin ella, los acentos y las eñes salen rotos—, el título, que es obligatorio y es lo que se ve en la pestaña y en los resultados de búsqueda, la etiqueta de ventana gráfica que hace posible el diseño adaptable, y los enlaces a las hojas de estilo.
- El cuerpo contiene lo que se ve.
Los tres distractores de la pregunta de 2026 son un catálogo de los errores que el tribunal usa, y merece la pena desmontarlos uno a uno: el primero no lleva declaración de tipo ni cabecera; el segundo se inventa un atributo de versión en el elemento raíz y una etiqueta <container> que no existe en HTML; y el tercero escribe <!HTML5>, que no es una declaración válida, y además deja el documento sin cerrar. La regla para descartar: si una opción usa una etiqueta que no existe, está mal por definición. HTML no es extensible por el programador —eso es XML—.
3.3. Las etiquetas semánticas de HTML5
La aportación más característica de HTML5 fue un juego de etiquetas que dicen qué papel cumple cada bloque, en lugar del <div> genérico para todo:
| Etiqueta | Qué marca |
|---|---|
| header | La cabecera de la página o de una sección. |
| nav | Un bloque de navegación. |
| main | El contenido principal. Solo puede haber uno por documento. |
| section | Una sección temática del contenido, normalmente con su encabezado. |
| article | Un contenido con sentido por sí solo: una noticia, una entrada, una ficha. |
| aside | Contenido relacionado pero secundario: una barra lateral, una nota al margen. |
| footer | El pie de la página o de una sección. |
| figure y figcaption | Una ilustración y su leyenda, unidas. |
🚨 El tribunal preguntó en los dos modelos de 2026 qué recomiendan las pautas de accesibilidad WCAG 2.1 para estructurar el contenido principal, y la respuesta era exactamente esta: utilizar etiquetas semánticas de HTML5 como main, section y header. Los distractores eran los tres antipatrones clásicos: maquetar con tablas —una práctica de los años noventa que destroza la navegación con lector de pantalla—, usar solo divisiones con clases —que se ve igual pero no dice nada a quien no ve— y definir la estructura solo con estilos.
La razón de fondo, que es lo que hay que entender: una etiqueta semántica se ve exactamente igual que una divisón genérica —el navegador no las pinta distinto— pero un lector de pantalla puede saltar directamente al contenido principal, enumerar las secciones y anunciar dónde está el usuario. La semántica no es para el ojo: es para el software que lee la página.
3.4. Texto, listas y tablas
Encabezados. De h1 a h6, y forman una jerarquía que no se puede saltar. Volverá enseguida, porque de ahí sale una pregunta.
Listas. Tres tipos: no ordenada (ul), ordenada (ol) y de definiciones (dl, con dt y dd). Los elementos son siempre li.
🚨 En 2019 el tribunal pidió el código de una lista anidada —un opositor con sus dos notas colgando— y la respuesta correcta es la que mete la lista interior DENTRO del elemento de la lista exterior:
<ul>
<li>Opositor
<ul>
<li>Nota 1</li>
<li>Nota 2</li>
</ul>
</li>
</ul>
Los distractores eran: poner las dos listas hermanas en lugar de anidadas —que se ve parecido pero no expresa la relación—, inventarse etiquetas <li1> y <li2>, y anidar mal cerrando en el orden equivocado. La regla: la sublista va dentro del li al que pertenece, nunca al lado.
Tablas. Sus etiquetas, que se preguntan por su nombre exacto:
| Etiqueta | Qué es |
|---|---|
| table | La tabla. |
| tr | Una fila. |
| td | Una celda de datos. |
| th | 🚨 Una celda de ENCABEZADO. El navegador la muestra en negrita y centrada, y el lector de pantalla la usa para anunciar a qué columna pertenece cada dato. |
| thead, tbody, tfoot | Los tres bloques de la tabla. |
| caption | El título de la tabla. |
En 2019 el tribunal preguntó qué etiqueta define la celda de encabezado de una columna con formato diferenciado, y la respuesta es th. Los tres distractores eran invenciones plausibles —tableheader, theader, tableh—, y ninguna existe. ⚠️ Ojo con la confusión de vecindad: thead sí existe, pero agrupa filas de encabezado, no es la celda.
3.5. Formularios
Es donde el tribunal más se detiene, porque un formulario es lo que hace una sede electrónica. Los elementos:
- form, con su action —a dónde se envía— y su method —normalmente GET para buscar y POST para enviar datos—.
- input, con su atributo type, que en HTML5 se multiplicó: text, email, number, date, tel, url, password, checkbox, radio, file, hidden, submit. Cada tipo trae validación y teclado adecuado de regalo.
- label, con su atributo for apuntando al identificador del campo. No es decorativo: es lo que hace que el lector de pantalla anuncie qué se pide al llegar al campo, y lo que permite pulsar sobre el texto para activar la casilla.
- select con sus option, textarea, button y fieldset con legend para agrupar.
🚨 Dos preguntas oficiales, las dos sobre atributos de validación. En 2019, cómo forzar que un campo sea obligatorio:
<input type="text" name="username" required/>
Los distractores —enforced, mandatory, compulsory— son tres sinónimos ingleses de «obligatorio» que no existen en HTML. Es la forma más pura de la trampa de este tema: el atributo real es el que hay que reconocer, no el que suena mejor.
Y en 2024, cómo impedir que un correo exceda los 100 caracteres:
<input type="email" id="email" name="email" maxlength="100">
Aquí los tres distractores son atributos reales con otro significado, y por eso la pregunta es mejor: size fija el ancho visible del campo, no cuánto se puede escribir; max fija el valor máximo y solo tiene sentido en campos numéricos y de fecha; y length no es un atributo de HTML. La regla que resuelve la familia entera: maxlength cuenta caracteres, max compara valores y size mide el hueco en pantalla.
Los demás atributos de validación que conviene reconocer: min y max para rangos, minlength, pattern para una expresión regular, placeholder para el texto de ejemplo —que no sustituye a la etiqueta, error de accesibilidad frecuente—, readonly, disabled y autocomplete.
Y tres atributos del propio elemento form que deciden CÓMO viajan los datos, y que se preguntan cruzados:
| Atributo | Qué fija | Lo que hay que saber |
|---|---|---|
| action | La dirección que atiende el envío. | Si se omite, se envía a la misma dirección de la página. |
| method | El verbo: GET o POST. | El primero pone los datos EN LA DIRECCIÓN —quedan en el historial y en los registros del servidor— y el segundo, en el CUERPO. Ninguno de los dos cifra nada: de eso se ocupa HTTPS. |
| enctype | Cómo se codifica el cuerpo. | Solo se aplica con POST, y tiene tres valores. |
🚨 Los tres valores de la codificación, porque de ahí sale la pregunta de la subida de ficheros:
- application/x-www-form-urlencoded: es el valor por defecto. Pares de clave y valor codificados como en la dirección. Vale para texto y no sirve para ficheros.
- multipart/form-data: divide el cuerpo en partes con una frontera entre ellas, y es la única forma de subir un fichero. Es también el valor que hay que elegir en cualquier supuesto que hable de adjuntar un documento.
- text/plain: sin codificar. Existe, pero solo se usa para depurar.
⚠️ Olvidar la codificación por partes es el fallo clásico del formulario de subida: el navegador envía únicamente el nombre del fichero, no su contenido, y en el servidor llega un campo de texto vacío sin ningún error visible.
3.6. Multimedia
HTML5 incorporó el vídeo y el audio como elementos nativos, sin necesidad de complementos externos. 🚨 En 2019 el tribunal puso este fragmento y preguntó qué muestra un navegador que soporte HTML5:
<video width="320" height="240" controls> <source src="movie.mp4" type="video/mp4"> <source src="movie.ogg" type="video/ogg"> No soportado </video>
La respuesta es que se mostrará el vídeo mp4 si el navegador soporta ese formato, y entenderlo resuelve toda una familia de preguntas. El mecanismo tiene tres niveles de reserva: el navegador recorre los elementos source en orden, se queda con el primero que sepa reproducir y ignora los demás; y el texto suelto que hay dentro del elemento solo se muestra si el navegador no entiende la etiqueta de vídeo. Por eso son falsas las opciones de «se mostrarán los dos vídeos» y «se mostrará el mensaje en todos los casos».
El resto de elementos multimedia: audio, con el mismo mecanismo; canvas, una superficie de dibujo que se pinta con JavaScript; svg, gráficos vectoriales que se escriben como marcado; y track, que añade subtítulos a un vídeo y es un requisito de accesibilidad, no un adorno.
3.7. Eventos
🚨 En 2024, en los dos modelos: qué evento usar para producir un efecto al situar el puntero del ratón sobre un elemento. La respuesta es onmouseover.
| Evento | Cuándo se dispara |
|---|---|
| onmouseover | 🚨 Al entrar el puntero en el elemento. |
| onmouseout | Al salir. Es el distractor natural. |
| onmousedown / onmouseup | Al pulsar y al soltar el botón. |
| onclick | Al hacer clic completo. |
| onchange / oninput | Al cambiar el valor de un campo, al salir de él o mientras se escribe. |
| onsubmit | Al enviar un formulario. Es donde se engancha la validación. |
| onload | Cuando la página y sus recursos han terminado de cargarse. |
| onkeydown / onkeyup | Al pulsar y soltar una tecla. |
⚠️ Un apunte de accesibilidad que también se pregunta: los efectos que dependen solo del ratón dejan fuera a quien navega con teclado. Lo correcto es acompañar el evento de ratón del equivalente de foco, para que quien tabula reciba el mismo efecto.
3.8. Accesibilidad en el marcado
🚨 Ha caído tres veces y va en aumento, así que merece su propio apartado aunque el bloque III le dedique un tema entero.
Primera pregunta, 2023: qué es WCAG. Son unas pautas de accesibilidad de contenidos web promovidas por el W3C. Se organizan en cuatro principios que conviene saber enumerar —perceptible, operable, comprensible y robusto— y en tres niveles de conformidad: A, AA y AAA. La normativa española exige el nivel AA.
Segunda pregunta, 2026: encontrar el problema de accesibilidad en este fragmento:
<h1>Gestión de usuarios</h1> <span><strong>Seleccione un usuario para ver acciones</strong></span> <h3>Administradores</h3>
El problema es que hay un salto en la jerarquía de encabezados, de h1 a h3, sin pasar por h2. Y la razón es concreta: quien usa un lector de pantalla navega saltando de encabezado en encabezado para hacerse un mapa de la página; un nivel que falta rompe ese mapa y da a entender que hay una sección intermedia que no está. ⚠️ Y ojo con los dos distractores, porque enuncian cosas correctas que no son el problema: usar <strong> en lugar de <b> es lo recomendable, precisamente porque el primero aporta importancia semántica y el segundo solo engorda la letra.
Tercera pregunta, 2026: qué atributo hace falta para que un lector de pantalla informe de que un menú desplegable está desplegado. La respuesta es aria-expanded="true".
Eso abre la puerta a WAI-ARIA, el conjunto de atributos que añade semántica a lo que HTML no cubre. Sus tres familias:
- Papeles (role): qué es este elemento —un botón, una pestaña, un diálogo— cuando se ha construido con divisiones genéricas.
- Estados: en qué situación está ahora. aria-expanded, aria-checked, aria-disabled, aria-hidden. Cambian con la interacción.
- Propiedades: características estables. aria-label para dar un nombre accesible, aria-labelledby y aria-describedby para apuntar a otro elemento que lo describe.
⚠️ La primera regla de ARIA es no usar ARIA. Suena a broma y es literal: si existe un elemento HTML nativo que ya hace el papel —un button, un select, un details—, hay que usarlo, porque trae la semántica, el foco y el manejo por teclado de fábrica. ARIA es para lo que no se puede expresar con HTML, y un ARIA mal puesto es peor que ninguno, porque miente al lector de pantalla.
Y los cuatro fallos de accesibilidad que aparecen una y otra vez: imágenes sin texto alternativo, contraste insuficiente, campos sin etiqueta asociada y funcionalidad que solo se alcanza con el ratón.
4. XHTML y la familia del marcado
XHTML es HTML reformulado como XML: el mismo vocabulario de etiquetas, pero obligado a cumplir las reglas estrictas de XML. Nació para acabar con la tolerancia de los navegadores a las páginas mal escritas, y hoy es una vía secundaria —HTML5 ganó—, pero sigue cayendo en el examen porque sirve para preguntar por las reglas de XML de rebote.
🚨 El tribunal preguntó en los dos modelos de 2024 una diferencia entre HTML y XHTML, y la respuesta oficial es que en XHTML es obligatoria la presencia del elemento head.
Los tres distractores estaban invertidos, que es el truco más usado del tema: cada uno enuncia una regla verdadera de XHTML atribuyéndosela a HTML. Las reglas reales, todas heredadas de XML:
| Regla en XHTML | En HTML |
|---|---|
| Todos los elementos se cierran, incluidos los vacíos, que se cierran sobre sí mismos. | Muchos cierres son opcionales y los vacíos no se cierran. |
| Etiquetas y atributos en minúscula, obligatoriamente. | Da igual la caja. |
| Los valores de los atributos van entre comillas, siempre. | Se pueden omitir en muchos casos. |
| No se admiten atributos minimizados: hay que escribir el par completo. | Basta el nombre del atributo. |
| Anidamiento estricto: se cierra en orden inverso al de apertura. | El navegador perdona y corrige. |
| head y body obligatorios. | Se pueden omitir; el navegador los da por implícitos. |
🚨 Y en 2026 volvió a preguntarlo dentro de una pregunta de «indique la afirmación INCORRECTA», donde la opción verdadera decía que en XHTML todos los elementos tienen que llevar cierre. La afirmación falsa de aquella pregunta era otra —que jQuery fuera un lenguaje de programación—, y volverá en el apartado de bibliotecas.
La regla mnemotécnica para el par entero: XHTML es HTML con las reglas de XML, y XML no perdona nada. Cualquier opción que presente a XHTML como el permisivo de los dos es falsa.
5. XML
5.1. Qué es y para qué sirve
XML (eXtensible Markup Language) es un metalenguaje de marcado del W3C: no trae un juego de etiquetas fijo, sino las reglas para que cada cual defina el suyo. Esa es la diferencia capital con HTML, que tiene un vocabulario cerrado.
Su propósito no es presentar información, es estructurarla e intercambiarla entre sistemas distintos, y esa vocación explica sus rasgos:
- Legible por personas y por máquinas a la vez.
- Independiente de plataforma y de lenguaje.
- Autodescriptivo: los nombres de las etiquetas dicen qué es cada dato.
- Validable contra un esquema, que es lo que permite rechazar automáticamente un documento que no cumple lo pactado.
🚨 El tribunal lo resumió en un distractor verdadero de 2026: XML es la base de un gran número de normas, y ahí es donde conecta con el resto del temario —la firma electrónica, los servicios web, el expediente electrónico, la interoperabilidad—.
5.2. Bien formado
Un documento bien formado es el que cumple las reglas sintácticas de XML. Sin eso, ningún analizador lo procesa: no es que dé un aviso, es que falla. Las reglas, que son las que el examen comprueba una por una:
- 🚨 UN SOLO elemento raíz. Preguntado literalmente en los dos modelos de 2026: un documento XML bien formado contiene solo uno, el elemento raíz, cuyas etiquetas de apertura y cierre no están dentro del contenido de ningún otro elemento.
- Toda etiqueta que abre, cierra, y los elementos vacíos se cierran sobre sí mismos.
- El anidamiento es correcto: se cierra en orden inverso al de apertura.
- Los nombres son sensibles a mayúsculas: la etiqueta que cierra debe escribirse exactamente igual que la que abre.
- Los valores de los atributos van siempre entre comillas, simples o dobles.
- Los caracteres reservados se escriben con su entidad.
🚨 La pregunta de 2026, en los dos modelos, pedía cuál de cuatro fragmentos está bien formado. El correcto:
<?xml version="1.0" encoding="UTF-8"?> <alumno><id_alumno>10</id_alumno><nombre>Juan Pérez</nombre></alumno>
Y los tres fallos, que son el catálogo completo de errores que el tribunal usa:
- Abrir id_alumno y cerrar con otro nombre (</nombre>). Viola la regla 4.
- Dejar el elemento raíz sin cerrar al final. Viola la regla 2.
- Abrir nombre y cerrar con id_alumno: anidamiento cruzado. Viola la regla 3.
⚠️ El método para resolver esta pregunta en veinte segundos, que vale para cualquier variante: recorrer el fragmento apuntando cada etiqueta que abre y tachándola cuando aparece su cierre exacto. La opción buena es la única que termina con la lista vacía. No hay que entender el contenido para nada.
Del prólogo conviene saber que la declaración XML es opcional pero recomendable, que si aparece va la primera y sin nada delante, y que la codificación por defecto es UTF-8.
5.3. Válido: DTD y esquema XML
Un documento válido es el que, además de estar bien formado, cumple las reglas de una gramática declarada: qué elementos puede haber, en qué orden, cuántas veces y con qué atributos. La distinción se pregunta mucho y se resume así: bien formado es cuestión de sintaxis; válido, de vocabulario. Todo documento válido está bien formado; lo contrario no.
| DTD | Esquema XML (XSD) | |
|---|---|---|
| Qué es | 🚨 Proporciona medios para validar archivos XML respecto de un conjunto de normas. Es la forma clásica, heredada de SGML. | 🚨 El lenguaje de definición de esquemas XML, recomendación del W3C. Las dos definiciones son literales de una pregunta de 2026. |
| Sintaxis | NO es XML: tiene su propia notación. | Es XML, así que se procesa con las mismas herramientas. |
| Tipos de datos | Prácticamente ninguno: todo es texto. | Sistema de tipos rico: enteros, fechas, decimales, restricciones de rango y patrones. |
| Espacios de nombres | No los soporta. | Sí. |
| Cardinalidad | Limitada a unos pocos símbolos. | Precisa: mínimo y máximo de apariciones. |
La conclusión práctica: XSD sustituyó a DTD para todo lo serio, y es lo que usan los esquemas de la Administración. DTD sobrevive por compatibilidad y como pregunta de examen. Existe además RELAX NG, una tercera vía más simple que aparece de vez en cuando como distractor.
5.4. Atributos, comentarios y detalles de sintaxis
🚨 La pregunta de los atributos, en los dos modelos de 2026. La forma correcta de poner un atributo:
<alumno id_alumno="10"><nombre>Juan Pérez</nombre></alumno>
Los tres errores que usó: dos puntos en lugar del signo igual, el valor sin comillas —que en XML es siempre error, aunque sea un número— y el atributo escrito fuera de la etiqueta, como si fuera contenido. La regla, en una línea: nombre, igual, valor entrecomillado, y todo dentro de la etiqueta de apertura.
Y la duda de diseño que a veces se pregunta: ¿elemento o atributo? La convención es que los datos van en elementos y los metadatos en atributos. Un atributo no puede repetirse ni tener estructura interna, así que en cuanto un dato pueda crecer, mejor elemento.
🚨 Los comentarios, preguntados en 2019, se escriben exactamente igual que en HTML:
<!-- esto es un comentario -->
Con dos restricciones que conviene retener: no pueden contener dos guiones seguidos dentro y no pueden ir dentro de una etiqueta.
Los otros elementos de sintaxis que completan el cuadro: las entidades predefinidas —cinco: menor que, mayor que, ampersand, comilla doble y comilla simple—, la sección CDATA, que dice al analizador «no interpretes nada de lo que hay aquí dentro» y es la forma de meter un fragmento de código sin escaparlo entero, y las instrucciones de procesamiento.
5.5. Espacios de nombres
El problema que resuelven es real: si un documento combina vocabularios de dos organismos y los dos definen un elemento <titulo> con significados distintos, hay colisión. Un espacio de nombres es un identificador único —normalmente escrito como una dirección, aunque no se descarga nada de ella— que se asocia a un prefijo y desambigua:
<exp:expediente xmlns:exp="http://ejemplo.gob.es/expediente"
xmlns:doc="http://ejemplo.gob.es/documento">
<exp:titulo>Solicitud de beca</exp:titulo>
<doc:titulo>Anexo I</doc:titulo>
</exp:expediente>
⚠️ El punto que se pregunta: lo que identifica al elemento es el espacio de nombres, no el prefijo. El prefijo es una abreviatura local que se puede cambiar sin alterar el significado del documento.
5.6. La familia: XPath, XSLT, XQuery y XSL-FO
| Tecnología | Para qué |
|---|---|
| XPath | Navegar por el documento y seleccionar nodos con una expresión de ruta. Es la pieza que usan todas las demás. |
| XSLT | Transformar un XML en otra cosa: otro XML, HTML o texto. Funciona con reglas de plantilla que casan con patrones XPath. |
| XSL-FO | Describir el formato de página para producir documentos paginados, típicamente PDF. |
| XQuery | Consultar colecciones de documentos XML, como SQL hace con las tablas. |
| XLink y XPointer | Enlaces entre documentos y referencias a partes concretas. |
⚠️ Cuidado con XSL como distractor. En 2023 el tribunal preguntó qué lenguaje de estilos usar para cambiar el color de un botón en el frontal web, y la respuesta es CSS. XSL estaba entre las opciones y es, efectivamente, un lenguaje de hojas de estilo, pero para transformar XML, no para dar estilo a una página en el navegador. La regla: CSS decora HTML; XSL transforma XML.
5.7. Procesar XML: DOM, SAX y StAX
🚨 En 2019 el tribunal preguntó cuál de cuatro opciones es una API de Java para el procesamiento de documentos XML, y la respuesta era StAX. Los distractores —JNA, JNI, JPaX— son cosas de otro mundo: los dos primeros sirven para llamar a código nativo desde Java y el tercero no existe.
| Modelo | Cómo trabaja | Cuándo conviene |
|---|---|---|
| DOM | Carga el documento entero en memoria como un árbol navegable en cualquier dirección. | Documentos pequeños que hay que recorrer y modificar. Inviable con ficheros grandes. |
| SAX | Recorre el documento en flujo y va lanzando sucesos —empieza un elemento, hay texto, termina un elemento— a los que reacciona el programa. Es un modelo de empuje. | Ficheros enormes con poca memoria. Solo hacia delante y solo lectura. |
| StAX | También en flujo, pero de tracción: es el programa quien pide el siguiente elemento cuando lo necesita. | Lo mismo que SAX, con un código mucho más fácil de escribir porque el control lo lleva el programa. |
| JAXB | No recorre: convierte el XML en objetos y al revés. | Cuando lo que se quiere son objetos y no el árbol. |
La forma corta de recordar la diferencia entre los dos de flujo: SAX te avisa, StAX le preguntas.
Y las bibliotecas de Apache que aparecen en los enunciados, porque en 2024 el tribunal preguntó por una: Xerces es el analizador de XML, Xalan el procesador de XSLT y CXF el marco de servicios web —que es la respuesta correcta a «con qué generar un cliente de servicios web en Java»—. Flink, el cuarto distractor, es un motor de procesamiento de flujos de datos, nada que ver.
🚨 Y en 2023 preguntó, al revés, cuál NO es una biblioteca de Java de la Apache Foundation. La respuesta era Mockete, que no existe; las tres reales son Log4J —el registro de trazas—, httpclient —cliente HTTP— y commons-io —utilidades de entrada y salida—. ⚠️ El distractor está construido para que suene a Mockito, que sí existe pero es una biblioteca de simulación para pruebas y no es de Apache. De la misma casa conviene reconocer ActiveMQ, que es su gestor de colas de mensajes y que el tribunal usó como distractor en la pregunta de Bootstrap.
5.8. Derivaciones de XML
El enunciado oficial dice «HTML, XML y sus derivaciones», así que conviene tener la lista:
| Derivación | Qué es |
|---|---|
| XHTML | HTML con las reglas de XML. |
| SVG | Gráficos vectoriales escritos como marcado: escalan sin perder calidad y se pueden animar y estilar con CSS. |
| RSS y Atom | Sindicación de contenidos: publicar novedades para que otros las consuman. |
| SOAP y WSDL | La pila de servicios web del tema anterior. |
| XAdES | Firma electrónica avanzada sobre XML. Es la que se usa en la Administración junto a CAdES —sobre datos binarios— y PAdES —sobre PDF—. |
| UBL | El Lenguaje Universal de Negocios, base de la facturación electrónica. Lo nombró un distractor verdadero de 2026. |
| OOXML y ODF | Los formatos de documento ofimático, los dos basados en XML comprimido. |
| XOP | 🚨 XML-binary Optimized Packaging. Preguntado en 2023 por el término asociado: el XOP Package. Resuelve un problema concreto: meter un adjunto binario en un mensaje XML sin pagar el sobrecoste de codificarlo en base 64, sacándolo aparte y dejando una referencia. Va de la mano de MTOM, el mecanismo que lo usa en los servicios web. |
6. JSON
JSON (JavaScript Object Notation) es el formato de intercambio que ha desplazado a XML en la web. Nació de la sintaxis de los objetos de JavaScript, pero es independiente del lenguaje: cualquiera lo lee y lo escribe.
🚨 El tribunal lo ha preguntado tres veces citando la norma por su número: RFC 8259.
Primera: los tipos. Un valor JSON debe ser uno de estos siete: object, array, number, string, true, false y null. Merece la pena mirar por qué fallan los distractores, porque enseñan el formato entero:
- ❌ date y undefined: JSON no tiene tipo fecha —las fechas se transmiten como cadenas de texto, normalmente en formato ISO— y undefined es de JavaScript, no de JSON.
- ❌ function: JSON transporta datos, no código. Es una de sus decisiones de diseño y una de sus virtudes de seguridad.
- ❌ NaN: no es un valor JSON válido; tampoco lo son infinito ni menos infinito.
- ⚠️ Y el detalle fino: la norma no lista boolean como tipo, sino los dos literales true y false por separado. Ese matiz es exactamente lo que separa la opción correcta de dos distractores.
Segunda, en 2026: cuál es la afirmación correcta. Un objeto JSON es una colección NO ORDENADA de pares nombre/valor. Las tres falsas: que mantenga el orden de inserción por definición —no lo garantiza, aunque en la práctica muchas implementaciones lo conserven—, que permita definir tipos personalizados y que admita comentarios. ⚠️ Esta última es un clásico: JSON no tiene comentarios, y es una de sus diferencias más molestas con XML y con YAML.
Tercera, en 2023: cómo convertir una cadena JSON en un objeto de JavaScript. El método estático es JSON.parse(). Y su inverso, que es el otro medio par que hay que saber, es JSON.stringify(), que convierte un objeto en cadena. La regla: parse trae hacia dentro, stringify manda hacia fuera.
| XML | JSON | |
|---|---|---|
| Verbosidad | Alta: cada dato con etiqueta de apertura y cierre. | Baja: menos peso en la red. |
| Tipos | Todo es texto salvo que haya esquema. | Tipos nativos: número, cadena, booleano, nulo. |
| Validación | XSD, maduro y potente. | JSON Schema, más reciente. |
| Comentarios | Sí. | No. |
| Atributos y espacios de nombres | Sí. | No: solo pares nombre/valor. |
| Transformación | XSLT. | Sin equivalente estándar. |
| Dónde manda | Interoperabilidad entre organismos, documentos, firma. | API web, configuración, aplicaciones móviles. |
Y el tercero en discordia: YAML, más legible aún, con la indentación como estructura y con comentarios. Es el formato de la configuración —y, como se vio en el tema anterior, uno de los dos en los que se escribe OpenAPI, junto con JSON—.
7. CSS
7.1. Qué es y cómo se aplica
CSS (Cascading Style Sheets, hojas de estilo en cascada) es el lenguaje que define cómo se ve lo que el HTML ha marcado. 🚨 En 2023 el tribunal preguntó qué lenguaje de estilos usar para cambiar el color de un botón en el frontal web, y la respuesta es CSS, con XML, SGML y XSL de señuelo: los tres son de marcado o de transformación, no de presentación en el navegador.
Una regla CSS tiene tres partes con nombre propio:
input:required { border-color: red; }
/* selector propiedad valor */
Y hay tres formas de aplicarlo, en orden de menor a mayor prioridad: la hoja externa enlazada desde la cabecera —la única recomendable, porque un solo fichero sirve a todo el sitio y se cachea—; la hoja interna dentro de una etiqueta de estilo en la cabecera; y el estilo en línea con el atributo style, que gana a los otros dos y por eso mismo hay que evitar: rompe la separación entre contenido y presentación y obliga a usar el modificador !important para corregirlo, que es el principio de la degradación de cualquier hoja de estilos.
7.2. Selectores
Es lo que más se pregunta del apartado, porque es donde se ve si alguien ha escrito CSS de verdad.
| Selector | Qué selecciona |
|---|---|
| p | Todos los elementos de ese tipo. |
| .aviso | Todos los que tengan esa clase. |
| #principal | El que tenga ese identificador. Solo puede haber uno por documento. |
| div p (espacio) | Descendiente: cualquier p dentro de un div, a cualquier profundidad. |
| li > a | 🚨 Hijo DIRECTO: solo los a que cuelgan inmediatamente de un li. |
| h2 + p | Hermano adyacente: el primer p que sigue a un h2. |
| h2 ~ p | Hermanos generales: todos los p que siguen a un h2. |
| input[type="email"] | Por atributo y su valor. |
| a:hover, input:required | Pseudoclases: un estado del elemento. |
| p::first-line, li::before | Pseudoelementos: una parte del elemento o contenido añadido. Llevan dos puntos dobles. |
🚨 La pregunta de 2019 pedía aplicar el color verde a los elementos <a> que sean hijos de un <li>. La respuesta:
li > a { color: green; }
Los tres distractores enseñan la sintaxis a base de romperla: li.a selecciona los li con clase «a», li#a el li con identificador «a», y li_a no significa nada. ⚠️ Y el matiz que conviene tener por si aparece la variante: li a con un espacio también seleccionaría esos enlaces, pero además los que estén más abajo en el árbol; el signo de mayor exige que sea hijo directo.
🚨 Y la de Flexbox, del mismo examen: aplicar el modelo de caja flexible a un div con identificador «principal»:
div#principal { display: flex; }
Los tres distractores inventan valores que suenan bien —flexbox, flex-container, flexible— y no existen. El valor es exactamente flex, y esa es toda la pregunta.
7.3. Especificidad y cascada
Cuando dos reglas afectan al mismo elemento y se contradicen, gana una. El orden de decisión, de mayor a menor peso:
- Una declaración marcada como importante.
- El estilo en línea.
- La especificidad del selector.
- A igual especificidad, la que aparezca la última.
🚨 La especificidad se preguntó en los dos modelos de 2024, y con un selector concreto: input:required, cuya especificidad es 0-1-1.
Se calcula como una terna que se lee de izquierda a derecha, donde cada posición pesa más que todas las de su derecha juntas:
| Posición | Qué cuenta | En input:required |
|---|---|---|
| Primera | Identificadores | 0 — no hay ninguno |
| Segunda | Clases, pseudoclases y selectores de atributo | 1 — la pseudoclase :required |
| Tercera | Tipos de elemento y pseudoelementos | 1 — el elemento input |
De ahí 0-1-1. ⚠️ El error que inducen los distractores es contar la pseudoclase como si fuera un identificador, que daría 1-0-1, o contar el elemento en la primera posición. La pseudoclase pesa como una clase, no como un identificador, y esa es la única idea que hay que llevar.
Dos apuntes que completan el sistema: el selector universal y los combinadores no suman nada; y la herencia es un mecanismo distinto —algunas propiedades, como el color y la tipografía, pasan de padres a hijos, y otras, como los márgenes, no—.
7.4. El modelo de caja
Todo elemento es una caja rectangular con cuatro capas, de dentro afuera: contenido, relleno, borde y margen.
🚨 En 2026 el tribunal puso un bloque de CSS y preguntó qué pasa visualmente con un div:
div {
text-align: center;
font-weight: bold;
border-radius: 20px;
box-shadow: 4px 4px 4px black;
background-color: limegreen;
}
La respuesta correcta: el texto se muestra centrado y en negrita, sobre una caja RECTANGULAR de color verde lima, con el borde REDONDEADO y con la sombra negra aplicada a la caja. Es una pregunta de precisión y se resuelve leyendo propiedad por propiedad:
- text-align: center centra el texto dentro de la caja; no centra la caja en la página.
- font-weight: bold pone la letra en negrita.
- ⚠️ border-radius redondea las ESQUINAS de una caja que sigue siendo rectangular. No la convierte en un círculo —para eso haría falta un radio del 50 % y unas dimensiones iguales—, y ese es exactamente el distractor que dice «una caja redonda».
- box-shadow aplica la sombra a la caja, no al texto. La sombra del texto es otra propiedad distinta, y ese es el otro distractor.
- background-color pinta el fondo.
La lección de método: en estas preguntas las cuatro opciones dicen casi lo mismo y se diferencian en un adjetivo. Hay que leer qué recibe cada efecto —el texto o la caja— y qué forma queda.
7.5. Unidades de medida
🚨 Preguntado tres veces en 2024 —dos modelos de ingreso libre y promoción interna—: en CSS3, cuál de estas unidades NO es relativa. La respuesta es Q.
| Unidad | Tipo | Respecto a qué |
|---|---|---|
| Q | 🚨 ABSOLUTA | Es un cuarto de milímetro. Es la respuesta, y la que casi nadie conoce. |
| cm, mm, in, pt, pc, px | Absolutas | Medidas físicas fijas. El píxel se considera absoluto en CSS. |
| em | Relativa | Al tamaño de letra del propio elemento (o del padre, para la propia propiedad de tamaño). |
| rem | Relativa | Al tamaño de letra del elemento raíz. Es la más recomendable para tipografía accesible. |
| ex | Relativa | A la altura de la letra x de la fuente actual. |
| ch | Relativa | Al ancho del carácter cero de la fuente actual. |
| vw y vh | Relativas | Al 1 % del ancho y del alto de la ventana. Son la base del diseño adaptable. |
| % | Relativa | Al elemento contenedor. |
⚠️ La trampa está en que ex y ch son unidades raras y suenan a absolutas, mientras que Q suena a rara y por eso muchos la eligen como «la que no conozco, será la buena»… acertando por el motivo equivocado. La forma segura: si la unidad depende de la fuente o de la ventana, es relativa; si es una medida física, es absoluta. Q es milimétrica, luego física.
Y la razón por la que esto importa más allá del examen: fijar los tamaños de letra en píxeles impide que el usuario los agrande, lo que es un problema de accesibilidad. Por eso las pautas recomiendan unidades relativas para el texto.
7.6. Flexbox y rejilla
Los dos sistemas modernos de maquetación, que sustituyeron a los flotantes:
- Flexbox —el modelo de caja flexible— reparte el espacio en una dimensión: una fila o una columna. Se activa con display: flex en el contenedor, y sus propiedades características son la dirección, la justificación en el eje principal, la alineación en el eje cruzado y el ajuste de línea.
- Grid reparte en dos dimensiones a la vez, filas y columnas. Se activa con display: grid y permite definir la rejilla y colocar cada elemento en ella.
La regla para elegir: Flexbox para una tira de elementos, Grid para una retícula. Se usan juntos sin problema.
7.7. Diseño adaptable y multidispositivo
El enunciado oficial pide «multiplataforma y multidispositivo», y en el front-end eso se llama diseño adaptable (responsive): una sola página que se reorganiza según el tamaño de la pantalla, en lugar de una versión para móvil y otra para escritorio. Sus tres ingredientes:
- La etiqueta de ventana gráfica en la cabecera. Sin ella, el móvil finge ser un escritorio y encoge todo.
- Rejillas y medidas flexibles: porcentajes y unidades de ventana en lugar de anchos fijos.
- Consultas de medios: bloques de reglas que solo se aplican por debajo o por encima de cierto ancho.
Las dos filosofías de trabajo: «móvil primero», que empieza por la pantalla pequeña y va añadiendo, y la contraria. La primera es la recomendada, porque obliga a decidir qué es lo esencial.
7.8. Preprocesadores
🚨 En 2019 el tribunal preguntó por las tecnologías de front-end, y la afirmación correcta era: Sass, Less y Stylus son preprocesadores de CSS.
Un preprocesador es un lenguaje que se escribe con más comodidades —variables, anidamiento, funciones, fragmentos reutilizables, ficheros troceados— y que se compila a CSS normal antes de servirse. El navegador nunca ve el original: solo entiende CSS.
Y los tres distractores de aquella pregunta, que son en sí mismos tres datos que hay que saber: Postman sirve para probar servicios REST, justo lo contrario de lo que decía el distractor; Node.js está construido sobre el motor V8 de JavaScript, no sobre ningún entorno de ejecución de Java; y Bootstrap no prueba servicios, sino que es —🚨 y esto lo preguntó aparte en 2023— el conjunto de herramientas de presentación y comportamiento que ofrece componentes para la parte dinámica del frontal web HTML. Los distractores de aquella otra pregunta eran una biblioteca de cálculo numérico, un gestor de colas de mensajes y una biblioteca de aprendizaje automático: tres nombres conocidos de tres mundos que no son la web.
7.9. Ocultar un elemento: tres formas que NO son lo mismo
Es una distinción pequeña que el tribunal puede preguntar y que además tiene consecuencias de accesibilidad:
- display: none saca el elemento del flujo: desaparece y su hueco también. Los lectores de pantalla tampoco lo anuncian.
- visibility: hidden lo hace invisible pero conserva el hueco, de modo que el resto de la página no se mueve. Tampoco lo lee la tecnología de apoyo.
- opacity: 0 lo deja transparente, pero el elemento sigue ahí y sigue siendo pulsable, que es la trampa: un botón invisible con este método se puede seguir activando.
⚠️ Y una cuarta, la que hace falta cuando se quiere ocultar algo solo visualmente pero que el lector de pantalla SÍ lo lea —el típico texto que explica un icono—: no vale ninguna de las tres, hay que recurrir a la técnica de sacarlo de la pantalla con posición absoluta y un recorte de un píxel, la clase que las bibliotecas suelen llamar de solo lectores.
8. JavaScript
8.1. Qué es y qué NO es
JavaScript es el lenguaje de programación de la web: interpretado, de tipado dinámico y débil, con funciones de primera clase y orientación a objetos basada en prototipos. Se ejecuta en el navegador y, desde la llegada de Node.js, también en el servidor.
🚨 Y lo primero que hay que saber es lo que NO es, porque el tribunal lo preguntó en 2026 como afirmación falsa: «el lenguaje de programación JavaScript forma parte de la plataforma Java» es FALSO. No tienen nada que ver: el parecido del nombre fue una decisión comercial de 1995, cuando Java estaba de moda. Java es compilado a bytecode y de tipado estático; JavaScript es interpretado y de tipado dinámico. La coincidencia empieza y acaba en cuatro letras.
De la misma pregunta salen dos afirmaciones verdaderas que también conviene fichar: isNaN("hola") devuelve verdadero —porque la cadena no se puede convertir a número— y React es una biblioteca de código abierto de JavaScript para crear interfaces de usuario de front-end.
8.2. Tipos, variables y ámbito
🚨 En 2026 el tribunal pidió la afirmación INCORRECTA sobre JavaScript, y las tres verdaderas son materia pura de este apartado:
- ✅ Entre los tipos de datos están String, Boolean, Undefined y Number. Los tipos primitivos completos son siete: string, number, bigint, boolean, undefined, symbol y null; todo lo demás es objeto.
- ✅ Una variable declarada sin valor asignado tiene el valor undefined. ⚠️ Y aquí está la distinción que se pregunta: undefined es «no se le ha dado valor» y null es «se le ha dado expresamente el valor vacío». El primero lo pone el lenguaje; el segundo, el programador.
- ✅ El alcance de una variable declarada con let es de bloque. Es la diferencia capital con la declaración antigua.
Las tres formas de declarar, que hay que saber separar:
| Declaración | Ámbito | Se puede reasignar |
|---|---|---|
| var | De función. Se «eleva» al principio, lo que produce errores difíciles de ver. | Sí |
| let | 🚨 De bloque: solo existe entre las llaves donde se declaró. | Sí |
| const | De bloque. | No. ⚠️ Pero si el valor es un objeto o un array, su contenido sí se puede modificar: lo constante es la referencia, no el contenido. |
8.3. La igualdad: el error más caro
🚨 Dos preguntas oficiales, en 2024 y en 2026, sobre exactamente lo mismo. Y es el punto donde más gente falla, porque las dos respuestas son contrarias:
| Expresión | Resultado | Por qué |
|---|---|---|
| 123 == '123' | 🚨 true | El doble igual es la igualdad ABSTRACTA: convierte los tipos antes de comparar. La cadena se convierte a número y los valores coinciden. (La pregunta de 2026 daba por INCORRECTA la afirmación de que devolvería falso.) |
| 10 === '10' | 🚨 false | El triple igual es la igualdad ESTRICTA: compara valor Y tipo, sin convertir nada. Número y cadena son tipos distintos, así que falso. (Preguntado en la promoción interna de 2024.) |
La regla en una línea: dos iguales convierten, tres iguales no. Y la recomendación profesional que se deriva: usar siempre el triple igual, porque la conversión automática produce resultados que sorprenden —una cadena vacía es igual a cero, y el valor nulo no es igual a undefined con tres iguales pero sí con dos—.
8.4. Operadores y precedencia
🚨 La pregunta de cálculo, en los dos modelos de 2026. Con a = 10, b = 4 y c = 4, ¿cuánto vale?
(a + b) % 2 == 0 ? c + 4 : c - 2
La respuesta es 8, y se saca en tres pasos: (10 + 4) = 14; 14 % 2 = 0, porque el operador de módulo devuelve el resto de la división y 14 es par; como 0 == 0 es verdadero, el operador ternario devuelve la rama de la izquierda, que es 4 + 4 = 8.
Lo que la pregunta mide de verdad es el operador ternario, que es la única estructura condicional que devuelve un valor: condición ? valor si verdadero : valor si falso. Quien invierta las ramas responde 2, que es justamente uno de los distractores.
Y de la pregunta anulada de 2023 sale el otro operador que conviene tener: 4 * 3 ** 2 = 36, porque la exponenciación tiene más precedencia que la multiplicación: primero 3 al cuadrado, que es 9, y después por 4. Fue anulada por estar mal enunciada —hablaba de JSON cuando el código es JavaScript—, pero la operación se puede volver a preguntar bien.
El orden de precedencia que hay que llevar: paréntesis, exponenciación, multiplicación, división y módulo, suma y resta, comparaciones, lógicos y por último el ternario y la asignación.
8.5. Manipular el DOM
Es para lo que nació el lenguaje. Las operaciones que se reconocen en cualquier fragmento:
- Seleccionar: getElementById, y sobre todo querySelector y querySelectorAll, que aceptan cualquier selector de CSS. Es la razón por la que saber selectores sirve dos veces.
- Leer y escribir: textContent para el texto y innerHTML para el marcado. ⚠️ Esta segunda es la puerta clásica del XSS: si se le mete texto que viene del usuario sin escapar, el navegador lo ejecuta.
- Crear y colocar elementos nuevos, cambiar atributos y clases.
- Escuchar sucesos con addEventListener, que es la forma correcta —permite varios oyentes sobre el mismo elemento, a diferencia de poner el manejador como atributo en el HTML—.
🚨 El tribunal lo preguntó en 2019 con un fragmento mínimo: dado <h1 id="titulo">Primer ejercicio TAI</h1>, cuál es el código de JavaScript que obtiene esa cadena. La respuesta oficial:
var titulo = document.getElementById("titulo").firstChild.nodeValue;
Se lee de izquierda a derecha y cada eslabón es una idea del DOM: getElementById devuelve el elemento; firstChild baja a su primer hijo, que aquí es el nodo de texto —porque en el DOM el texto también es un nodo, no una propiedad—; y nodeValue saca su contenido.
Los tres distractores fallan por cosas distintas y las tres son preguntables: document.titulo no existe —no se accede a un elemento como si fuera una propiedad del documento—; document.getElement("h1") tampoco, porque el método es getElementsByTagName, en plural y devolviendo una colección; y ⚠️ los dos escriben InnerHTML e InnerText con la primera letra en mayúscula, cuando las propiedades reales son innerHTML e innerText. JavaScript distingue mayúsculas de minúsculas, así que esa sola letra ya invalida la opción. Es el tipo de detalle que este tribunal usa con frecuencia: la respuesta correcta se reconoce tanto por lo que dice como por cómo está escrita.
8.6. Peticiones asíncronas
La técnica de pedir datos al servidor sin recargar la página se llamó históricamente AJAX. Hoy se hace con fetch.
🚨 El tribunal pidió en los dos modelos de 2026 la llamada correcta a un servicio REST desde JavaScript:
fetch("http://localhost:8080/alumnos")
.then(response => response.json())
.then(data => console.log(data));
Merece desmontarse porque tiene tres piezas y cada una es preguntable: fetch es una función global del navegador —los distractores la inventaban como método de otro objeto—; devuelve una promesa, que es un objeto que representa un resultado que llegará más tarde y sobre el que se encadena con then; y hacen falta dos encadenamientos, porque el primero entrega la respuesta y hay que pedirle el cuerpo ya convertido desde JSON, lo que a su vez devuelve otra promesa.
La forma moderna equivalente usa async y await, que hace que el código asíncrono se lea como si fuera secuencial. Y el otro detalle que cae de rebote: una petición a otro origen desde un guion está sujeta a CORS, como se vio en el tema anterior.
8.7. ECMAScript y TypeScript
ECMAScript es la norma; JavaScript, su implementación. Las versiones se nombran por el año, y la que el tribunal citó en un enunciado de 2026 es ECMAScript 2022. Los hitos que conviene reconocer: la edición de 2015 fue la refundación del lenguaje —trajo let y const, las clases, las funciones flecha, los módulos, las promesas y el operador de propagación—, y a partir de ahí hay una edición pequeña cada año.
TypeScript es un superconjunto de JavaScript que añade tipado estático y se compila a JavaScript normal. No lo entiende ningún navegador: lo que llega al navegador es siempre JavaScript. Su valor es que el error se detecta al compilar y no en producción, y por eso es la opción por defecto en los proyectos grandes y en Angular.
🚨 En 2026 el tribunal puso este código de TypeScript y preguntó qué hace:
const menuAdministrador = ["Usuarios", "Permisos"]; const menuGestor = ["Notificaciones", "Usuarios", "Asientos registrales"]; return [...menuAdministrador, ...menuGestor];
La respuesta: genera un NUEVO array con el contenido de los dos. Los tres puntos son el operador de propagación, que desparrama los elementos de un array dentro de otro. Tres consecuencias que desmontan los distractores: no sustituye nada —los originales quedan intactos, y por eso pueden ser constantes—; no calcula intersecciones, así que «Usuarios» aparecerá dos veces; y el resultado tiene cinco elementos, no cuatro. ⚠️ Ese detalle de que no elimina duplicados es lo que separa la opción correcta de la que habla de elementos comunes.
8.12. Los métodos de array que hay que reconocer
Buena parte del JavaScript moderno se escribe encadenando estos métodos en lugar de con bucles, y el tribunal los ofrece juntos como distractores unos de otros. La diferencia que hay que tener clara es qué devuelve cada uno:
| Método | Qué hace | Qué devuelve |
|---|---|---|
| filter | Se queda con los elementos que cumplen una condición. | Un array nuevo, más corto o igual. |
| map | Transforma cada elemento, uno a uno. | Un array nuevo, de la misma longitud. |
| reduce | Acumula todos los elementos en un valor. | Un solo valor: un número, un objeto, lo que sea. |
| find | Busca el primero que cumple la condición. | Un elemento, o indefinido si no hay ninguno. |
| forEach | Recorre y ejecuta algo con cada elemento. | Nada: se usa por su efecto, no por su resultado. |
| sort | Ordena según el criterio que se le pase. | El mismo array, ⚠️ MODIFICADO. |
⚠️ La distinción que se falla: los cinco primeros no tocan el array original, y el de ordenar SÍ lo modifica en el sitio. Por eso, cuando hay que conservar el orden de partida, se ordena sobre una copia hecha con el operador de propagación.
9. Bibliotecas y marcos de trabajo
Antes de los nombres, la distinción que el tribunal pregunta de tres formas distintas:
- Un lenguaje tiene su propia sintaxis y su propio intérprete o compilador.
- Una biblioteca es código que tú llamas cuando lo necesitas. Tú llevas el control.
- Un marco de trabajo (framework) es una estructura que te llama a ti: define el esqueleto de la aplicación y tú rellenas los huecos. A eso se le llama inversión del control.
🚨 Primera pregunta, 2026: la afirmación INCORRECTA era «jQuery es un lenguaje de programación que permite la mejora de JavaScript». jQuery es una BIBLIOTECA de JavaScript, no un lenguaje. Fue enormemente popular porque uniformaba las diferencias entre navegadores y simplificaba la manipulación del DOM; hoy ha perdido peso porque el propio lenguaje incorporó casi todo lo que aportaba.
🚨 Segunda pregunta, 2023: cuál NO es un marco de trabajo para JavaScript. La respuesta era JDBC, que es la interfaz de acceso a bases de datos de Java. Angular, Bootstrap y React sí pertenecen al mundo del front-end. ⚠️ Detalle fino: Bootstrap no es un marco de JavaScript en sentido estricto, sino un marco de CSS con algunos componentes que usan JavaScript; pero de las cuatro opciones era JDBC la única completamente ajena, y así hay que leer estas preguntas: se elige la más claramente fuera, no la técnicamente más discutible.
| Nombre | Qué es exactamente |
|---|---|
| Angular | Marco completo de Google, escrito en TypeScript. Trae de serie enrutado, formularios, peticiones e inyección de dependencias. |
| React | 🚨 Biblioteca de código abierto para construir interfaces de usuario, de Meta. No es un marco completo: para lo demás se combina con otras piezas. |
| Vue | Marco progresivo: se puede usar en una parte de la página o para la aplicación entera. |
| jQuery | Biblioteca, no lenguaje. |
| Bootstrap | 🚨 Conjunto de herramientas de presentación y comportamiento con componentes para la parte dinámica del frontal web HTML. Definición literal del tribunal. |
| Node.js | Entorno de ejecución de JavaScript fuera del navegador, sobre el motor V8. No es un marco ni una biblioteca. |
🚨 Y dos preguntas de Angular del ejercicio extraordinario de 2026, las dos de sintaxis exacta.
Enlace bidireccional entre un campo y una propiedad del componente:
<input type="text" [(ngModel)]="email" />
La notación se llama «caja de plátano dentro de una caja» y no es un capricho: en Angular, los corchetes marcan el flujo del componente hacia la vista y los paréntesis, de la vista hacia el componente. Combinarlos es lo que produce el enlace en los dos sentidos, y por eso los distractores que usan solo corchetes o solo paréntesis son unidireccionales.
Mostrar una fecha con formato:
<p>Fecha y hora: {{ fechaHora | date: 'dd/MM/yyyy HH:mm' }}</p>
Aquí hay tres cosas que tienen que estar bien a la vez, y cada distractor rompe una: la interpolación va con DOBLE llave, no simple; el patrón de formato va entre comillas; y el patrón distingue mayúsculas —MM es el mes y mm los minutos, y HH son horas de 0 a 23 mientras que hh son de 1 a 12—. Como el ejemplo pedido era «19:32», hacía falta HH. La barra vertical es una tubería, el mecanismo de Angular para transformar un valor antes de mostrarlo.
9.5. Dos piezas que explican por qué una interfaz moderna va rápida
El DOM virtual. Tocar el árbol real es de las operaciones más caras que hay en el navegador: cada cambio puede obligar a recalcular la disposición de la página entera y a repintarla. Los marcos que redibujan la vista completa cuando cambia un dato lo resuelven con una copia ligera en memoria: se construye el árbol nuevo, se compara con el anterior y solo se aplican al DOM real las diferencias. De ahí que redibujar «todo» resulte, en la práctica, más barato que ir tocando nodos a mano.
El trabajador de servicio. Es un guion que se registra una vez y corre en segundo plano, fuera de la página, con su propio ciclo de vida. Se coloca como intermediario entre la aplicación y la red, de modo que puede interceptar cada petición y decidir si la deja pasar o la responde desde su caché. Eso es lo que permite tres cosas que antes eran exclusivas de una aplicación instalada:
- Funcionar sin conexión, sirviendo desde la caché lo que ya se descargó.
- Recibir avisos enviados por el servidor aunque la pestaña esté cerrada.
- Sincronizar en segundo plano lo que quedó pendiente al recuperarse la red.
Junto al manifiesto de la aplicación —el fichero que da el nombre, los iconos y el modo de presentación—, es la pieza que convierte un sitio web en una aplicación web progresiva, instalable en el escritorio o en el móvil. ⚠️ Exige HTTPS: sin canal cifrado el navegador no registra el trabajador, precisamente porque puede reescribir las respuestas.
10. El lado del servidor
10.1. Los lenguajes
En el servidor no hay un lenguaje obligatorio: sirve cualquiera que sepa atender una petición HTTP. Los que aparecen en los enunciados:
| Lenguaje | Dónde se usa |
|---|---|
| Java | La opción dominante en la Administración, con Spring Boot. Es el tema 5 de este bloque. |
| C# | Con ASP.NET Core, la otra gran plataforma empresarial. |
| PHP | El clásico de la web; mueve una parte enorme de los sitios existentes. |
| Python | Con Django o Flask; muy extendido en análisis de datos. |
| Go | 🚨 La respuesta correcta a «cuál está relacionado con el desarrollo en backend». Compilado, con concurrencia sencilla, típico de servicios y herramientas de infraestructura. |
| JavaScript con Node.js | El mismo lenguaje en los dos lados. |
10.2. PHP
🚨 Preguntado dos veces en 2023, en ingreso libre y en promoción interna, con el mismo enunciado: qué variable se usa en PHP para almacenar datos del inicio de sesión de un usuario. La respuesta es $_SESSION.
La clave para no fallarla está en el guion bajo: PHP tiene un juego de variables superglobales que empiezan todas por $_ y se escriben en mayúsculas. Los distractores quitaban el guion bajo o cambiaban el nombre, y ninguna de esas variantes existe.
| Superglobal | Qué contiene |
|---|---|
| $_SESSION | 🚨 Los datos de la sesión del usuario, que persisten entre peticiones. |
| $_GET y $_POST | Los parámetros recibidos por cada método. |
| $_COOKIE | Las cookies enviadas por el navegador. |
| $_SERVER | Información del servidor y de la petición. |
| $_FILES | Los ficheros subidos. |
| $_REQUEST | La mezcla de GET, POST y COOKIE. ⚠️ Desaconsejada, porque no se sabe de dónde viene cada dato. |
| $GLOBALS | Todas las variables globales. Esta es la única sin guion bajo, y es la que hace creíble el distractor. |
10.3. Motores de plantillas
Un motor de plantillas mezcla un documento HTML con datos para producir la página final en el servidor.
🚨 En 2024 el tribunal preguntó por Razor, el de ASP.NET Core, y la afirmación correcta es: Razor es la sintaxis de plantillas utilizada en ASP.NET Core para crear vistas dinámicas en aplicaciones web.
Los tres distractores enseñan por contraste qué es y qué no:
- ❌ «Es uno de los lenguajes de programación de ASP.NET Core». No: es una sintaxis de plantillas. Los lenguajes son C#, F# y Visual Basic.
- ❌ «Se ejecuta directamente en el navegador». No: se ejecuta en el servidor, y lo que llega al navegador es HTML ya generado. (La excepción es Blazor, que es otra cosa.)
- ❌ «Utiliza el símbolo arroba para pasar de C# a HTML». ⚠️ Este es el distractor bueno, porque está invertido: la arroba marca el paso de HTML a C#, es decir, señala dónde empieza el código dentro del marcado. Justo al revés.
Sus equivalentes en las otras plataformas: Thymeleaf y JSP en Java, Twig y Blade en PHP, Jinja en Python.
10.4. Servidores web
| Servidor | Qué conviene saber |
|---|---|
| Apache HTTP Server | El histórico, modular y configurable por directorio. Su fichero de configuración distribuida es el que permite reescribir direcciones sin tocar la configuración global. |
| nginx | Diseñado para muchísimas conexiones simultáneas con pocos recursos. Se usa sobre todo como proxy inverso, servidor de estáticos y terminador de TLS delante de una aplicación. |
| IIS | El de Windows, integrado con .NET y con el directorio activo. |
⚠️ Distinción que se pregunta: un servidor web sirve contenido por HTTP; un servidor de aplicaciones ejecuta la lógica y ofrece transacciones, seguridad y persistencia. En un despliegue típico van los dos, con el servidor web delante.
11. Dónde se pinta la página
🚨 En 2024 el tribunal planteó un formulario extenso con muchas consultas de datos y preguntó qué usar para renderizar la página en el servidor. La respuesta es Server Side Rendering, y los distractores eran tres tecnologías reales de comunicación —sucesos enviados por el servidor, AJAX y WebSocket— que traen datos pero no pintan la página. La lección: renderizar y comunicar son cosas distintas.
| Estrategia | Dónde se genera el HTML | A favor | En contra |
|---|---|---|---|
| Renderizado en servidor | En el servidor, en cada petición. | La primera carga es rápida, funciona sin JavaScript y los buscadores lo indexan sin problema. Es lo mejor para formularios extensos y para accesibilidad. | Cada interacción que necesite datos nuevos cuesta un viaje al servidor. |
| Renderizado en cliente | En el navegador, con JavaScript. | Interacción muy fluida una vez cargada. Es el modelo de la aplicación de página única. | Primera carga lenta, y sin JavaScript no hay nada: es un riesgo de accesibilidad y de indexación. |
| Generación estática | En la construcción, antes de desplegar. | Lo más rápido y barato de servir. | Solo vale para contenido que no cambia por usuario. |
| Hidratación | Primero en servidor, después el JavaScript «despierta» la página. | Combina la primera carga rápida con la interacción fluida. | Más complejidad y más código que enviar. |
12. Multiplataforma y multidispositivo
El enunciado oficial lo pide expresamente, y hay cuatro maneras de llegar a un móvil:
| Enfoque | Qué es | Contrapartida |
|---|---|---|
| Web adaptable | Una web que se reorganiza según la pantalla. | Sin acceso pleno al dispositivo ni presencia en las tiendas. |
| Aplicación web progresiva | Una web que además se instala, funciona sin conexión y recibe notificaciones, gracias a un trabajador de servicio y a un manifiesto. | Soporte desigual entre plataformas. |
| Híbrida | Web empaquetada dentro de un contenedor nativo con una vista web. | Rendimiento y acabado inferiores a lo nativo. |
| Nativa multiplataforma | Un solo código que compila a las dos plataformas: .NET MAUI, Flutter, React Native. | Se depende del marco elegido. |
| Nativa pura | Kotlin o Java para Android, Swift para Apple. | Dos desarrollos y dos equipos. |
🚨 De Swift el tribunal preguntó en 2024 la afirmación INCORRECTA, que era «se utiliza exclusivamente para la construcción de aplicaciones para iOS». Las tres verdaderas: lo creó Apple, se distribuye bajo licencia abierta Apache 2.0 y entre sus tipos habituales están String, Int, Double y Bool. Es falsa la exclusividad porque Swift sirve para todo el ecosistema de Apple —también para el escritorio, el reloj y el televisor— y, al ser abierto, también corre en Linux y en el servidor. ⚠️ La palabra que delata el distractor es «exclusivamente», que en este tema casi siempre marca la opción falsa.
13. Seguridad en el desarrollo web
🚨 Primera pregunta, en los dos modelos de 2026: qué recomienda OWASP para prevenir los ataques XSS. La respuesta es validar y escapar correctamente los datos antes de mostrarlos en el navegador.
El guionado entre sitios consiste en que el atacante consigue que su código se ejecute en el navegador de la víctima, normalmente colando marcado en un campo que después se pinta sin escapar. Sus tres formas: almacenado —el código queda guardado en la base de datos y se sirve a todos—, reflejado —viaja en la dirección y se devuelve en la respuesta— y basado en el DOM —ocurre entero en el navegador—.
La defensa tiene tres capas y conviene saber el orden: escapar al pintar, que es la principal y la que dice la respuesta oficial; validar la entrada con una lista de lo permitido; y reducir el daño con la política de seguridad de contenido y con la cookie marcada para que no la lea un guion.
🚨 Segunda pregunta, 2026: qué cabecera evita el XSS mediante rastreo MIME. La respuesta es X-Content-Type-Options: nosniff.
El problema que resuelve: algunos navegadores, si el tipo declarado no les convence, adivinan el tipo real mirando el contenido. Un fichero subido como imagen que en realidad contiene código podría acabar ejecutándose. Esa cabecera dice: no adivines, fíate del tipo que declaro.
Los otros tres distractores son cabeceras reales que hay que saber colocar: X-Frame-Options: DENY impide que la página se muestre dentro de un marco ajeno y protege del secuestro de clic; Content-Security-Policy declara de qué orígenes se puede cargar cada tipo de recurso; y X-XSS-Protection es una cabecera antigua que ya no se recomienda —y con el valor cero, además, la desactiva—.
El cuadro completo de cabeceras de seguridad, que cierra el apartado:
| Cabecera | Contra qué protege |
|---|---|
| Content-Security-Policy | XSS e inyección de recursos. |
| X-Content-Type-Options: nosniff | 🚨 XSS por rastreo MIME. |
| X-Frame-Options | Secuestro de clic. |
| Strict-Transport-Security | Degradación a HTTP sin cifrar. |
| Referrer-Policy | Fuga de información en la cabecera de procedencia. |
14. Probar el front-end
🚨 Selenium WebDriver, preguntado en 2023, sirve para automatizar la ejecución de pruebas en el navegador. Conduce un navegador real como lo haría una persona —abre páginas, rellena campos, pulsa botones— y comprueba el resultado. Los distractores lo confundían con lectura de textos, optimización de carga y diseño adaptable.
🚨 Y en 2026, con qué tipo de fichero se implementan las pruebas unitarias de un componente del frontal: con un fichero .spec.ts. Es la convención de Angular y del mundo JavaScript en general: el fichero de pruebas lleva el mismo nombre que el componente con el sufijo spec, de modo que la prueba vive al lado de lo que prueba. Los distractores eran las otras tres extensiones reales de un proyecto de Angular: el componente, el módulo y un fichero de configuración.
Y la escalera completa de pruebas del front-end: unitarias de un componente aislado, de integración entre varios, de extremo a extremo conduciendo el navegador —ahí entra Selenium—, y las de accesibilidad, que se automatizan parcialmente pero nunca del todo: las herramientas detectan la mitad de los problemas, y el resto exige revisión manual con lector de pantalla.
⚠️ Un apunte de interoperabilidad que conecta con el bloque I y que ya ha caído: la Norma Técnica de Interoperabilidad de Catálogo de estándares fija qué formatos puede usar la Administración. En 2026 el tribunal preguntó cuál NO está incluido en la categoría de formatos de imagen y texto, y la respuesta era BMP, frente a CSS, JPEG y TIFF, que sí lo están. El detalle es de tema 8, pero la lección aquí es que los formatos que se usan en una aplicación de la Administración no se eligen libremente.
15. Cuadros para memorizar
Lo que se reconoce, no se razona.
| Pregunta | Respuesta |
|---|---|
| Posición del DOCTYPE | La primera línea, antes del elemento raíz |
| Elementos raíz de un XML bien formado | Uno solo |
| Diferencia HTML / XHTML | En XHTML el head es obligatorio (y todo cierra, en minúsculas y con comillas) |
| Comentario en XML | Con los delimitadores de apertura y cierre de comentario, iguales que en HTML |
| Celda de encabezado de tabla | th |
| Campo obligatorio en un formulario | required |
| Limitar a 100 caracteres | maxlength (no size, que es el ancho, ni max, que es el valor) |
| Puntero del ratón sobre un elemento | onmouseover |
| Estructura accesible del contenido principal | Etiquetas semánticas de HTML5: main, section, header |
| Menú desplegado para un lector de pantalla | aria-expanded="true" |
| Qué es WCAG | Pautas de accesibilidad de contenidos web del W3C |
| Motor web de Mozilla | Gecko (Firefox es el navegador) |
| Tipos de valor en JSON | object, array, number, string, true, false y null |
| Objeto JSON | Colección NO ordenada de pares nombre/valor · sin comentarios |
| Cadena JSON a objeto | JSON.parse() (y al revés, JSON.stringify()) |
| Unidad CSS que NO es relativa | Q (un cuarto de milímetro) |
| Especificidad de input:required | 0-1-1 |
| Enlaces hijos directos de un elemento de lista | li > a |
| Activar Flexbox | display: flex |
| border-radius | Redondea las esquinas; la caja sigue siendo rectangular |
| Preprocesadores de CSS | Sass, Less y Stylus |
| Lenguaje de estilos para el frontal web | CSS (XSL transforma XML, no decora HTML) |
| 123 == '123' | true (dos iguales convierten) |
| 10 === '10' | false (tres iguales comparan valor y tipo) |
| (a+b) % 2 == 0 ? c+4 : c-2, con a=10 b=4 c=4 | 8 |
| 4 * 3 ** 2 | 36 (la exponenciación va primero) |
| Ámbito de let | De bloque |
| Llamada REST desde JavaScript | fetch(...).then(r => r.json()).then(...) |
| Los tres puntos de TypeScript | Propagación: genera un array NUEVO con el contenido de los dos, sin quitar duplicados |
| jQuery | Biblioteca de JavaScript, NO un lenguaje |
| Qué NO es marco de JavaScript | JDBC |
| Componentes para la parte dinámica del frontal HTML | Bootstrap |
| Enlace bidireccional en Angular | [(ngModel)] |
| Sesión de usuario en PHP | $_SESSION |
| Razor | Sintaxis de plantillas de ASP.NET Core, ejecutada en el servidor |
| Lenguaje de backend | GO (SASS y Angular son front; XML no es de programación) |
| Renderizar la página en el servidor | Server Side Rendering |
| Swift | De Apple, abierto, y NO exclusivo de iOS |
| Prevenir XSS según OWASP | Validar y escapar antes de mostrar |
| XSS por rastreo MIME | X-Content-Type-Options: nosniff |
| Cookie inaccesible desde JavaScript | HttpOnly |
| Cookie solo si se originó en el mismo sitio | SameSite |
| Selenium WebDriver | Automatizar pruebas en el navegador |
| Fichero de pruebas de un componente del frontal | .spec.ts |
| API de Java para procesar XML | StAX |
| Término asociado a XOP | XOP Package |
Los pares que el tribunal confunde a propósito.
| Par | Cómo se separan |
|---|---|
| == / === | Convierte el tipo / no lo convierte |
| HttpOnly / Secure | Protege del guion / protege en el camino |
| maxlength / max / size | Cuenta caracteres / compara valores / mide el hueco |
| bien formado / válido | Cumple la sintaxis / cumple además una gramática |
| DTD / XSD | Notación propia y sin tipos / es XML y con tipos ricos |
| CSS / XSL | Decora HTML / transforma XML |
| SAX / StAX | Te avisa / le preguntas |
| biblioteca / marco | Tú la llamas / él te llama |
| Gecko / Firefox | El motor / el navegador |
| onmouseover / onmouseout | Al entrar / al salir |
| MM / mm y HH / hh | Mes / minutos y 24 horas / 12 horas |
| undefined / null | No se le dio valor / se le dio el valor vacío |
16. Lo que ya ha preguntado el tribunal
| Convocatoria | Qué preguntó | Respuesta oficial |
|---|---|---|
| 2026 (A y B) | Posición del DOCTYPE según el HTML Living Standard | Primera línea, antes del elemento raíz |
| 2026 (A y B) | Elementos raíz de un XML bien formado | Solo uno |
| 2026 (A y B) | Tipos y literales de un valor JSON (RFC 8259) | object, array, number, string, true, false, null |
| 2026 (A y B) | Resultado de la expresión condicional en JavaScript | 8 |
| 2026 (A y B) | Estructura HTML5 válida con un contenedor | La que lleva DOCTYPE, head con title y body |
| 2026 (A y B) | Fragmento XML bien formado | El que cierra cada etiqueta con su mismo nombre |
| 2026 (A y B) | Atributo en un elemento XML | id_alumno="10", con igual y comillas |
| 2026 (A y B) | Llamada REST desde JavaScript | fetch con dos encadenamientos |
| 2026 (A y B) | Estructura del contenido principal según WCAG 2.1 | Etiquetas semánticas de HTML5 |
| 2026 (A y B) | Atributo para anunciar un menú desplegado | aria-expanded="true" |
| 2026 (A y B) | Recomendación de OWASP contra XSS | Validar y escapar antes de mostrar |
| 2026 (extra.) | Afirmación correcta sobre JSON | Colección no ordenada de pares nombre/valor |
| 2026 (extra.) | Afirmación INCORRECTA sobre XSD, DTD, XHTML y jQuery | jQuery NO es un lenguaje de programación |
| 2026 (extra.) | Afirmación INCORRECTA sobre JavaScript | Que 123 == '123' devuelva falso (devuelve verdadero) |
| 2026 (extra.) | Afirmación FALSA | Que JavaScript forme parte de la plataforma Java |
| 2026 (extra.) | Propósito de HttpOnly | Impedir que los guiones del cliente lean la cookie |
| 2026 (extra.) | Problema de accesibilidad en un fragmento HTML | Salto de h1 a h3 sin pasar por h2 |
| 2026 (extra.) | Enlace bidireccional en Angular | [(ngModel)] |
| 2026 (extra.) | Fecha con formato en una plantilla de Angular | Doble llave, tubería date y patrón entre comillas con HH |
| 2026 (extra.) | Qué hace la clase CSS sobre un div | Caja rectangular con borde redondeado y sombra en la caja |
| 2026 (extra.) | Qué hacen los tres puntos en TypeScript | Un array nuevo con el contenido de los dos |
| 2026 (extra.) | Cabecera contra el XSS por rastreo MIME | X-Content-Type-Options: nosniff |
| 2026 (extra.) | Fichero de pruebas unitarias del frontal | spec.ts |
| 2026 (extra.) | Formatos de la documentación OpenAPI/Swagger | YAML y JSON |
| 2024 (A y B) | Diferencia entre HTML y XHTML | En XHTML el head es obligatorio |
| 2024 (A y B) | Evento al situar el puntero sobre un elemento | onmouseover |
| 2024 (A y B) | Limitar el correo a 100 caracteres | maxlength="100" |
| 2024 (A, B y PI) | Unidad de CSS3 que NO es relativa | Q |
| 2024 (A y B) | Especificidad del selector input:required | 0-1-1 |
| 2024 (A y B) | Razor en ASP.NET Core | Sintaxis de plantillas para vistas dinámicas |
| 2024 (A y B) | Cómo renderizar en el servidor un formulario extenso | Server Side Rendering |
| 2024 (PI) | Resultado de console.log(10 === '10') | false |
| 2024 (PI) | Afirmación INCORRECTA sobre Swift | Que se use exclusivamente para iOS |
| 2023 (LI) | Qué es WCAG | Pautas de accesibilidad web del W3C |
| 2023 (LI) | Motor web de la Fundación Mozilla | Gecko |
| 2023 (LI) | Cuál NO es un framework de JavaScript | JDBC |
| 2023 (LI) | Término relacionado con XOP | XOP Package |
| 2023 (LI y PI) | Variable de PHP para la sesión | $_SESSION |
| 2023 (LI) | Método para convertir una cadena JSON en objeto | JSON.parse() |
| 2023 (LI) | Componentes para la parte dinámica del frontal HTML | Bootstrap |
| 2023 (LI) | Lenguaje de estilos para el color de un botón | CSS |
| 2023 (LI) | Para qué sirve Selenium WebDriver | Automatizar pruebas en el navegador |
| 2023 (LI) | Lenguaje relacionado con el backend | GO |
| 2023 (LI) | Cookie que solo se envía si se originó en el mismo sitio | SameSite |
| 2023 (PI) | Atributo que impide el acceso de JavaScript a la cookie | HttpOnly |
| 2019 | Tecnologías de front-end | Sass, Less y Stylus son preprocesadores de CSS |
| 2019 | API de Java para procesar XML | StAX |
| 2019 | Comentarios en XML | Los mismos delimitadores que en HTML |
| 2019 | Celda de encabezado de una columna | th |
| 2019 | Lista anidada en HTML5 | La sublista dentro del li |
| 2019 | Campo obligatorio en un formulario | required |
| 2019 | Color a los enlaces hijos de un elemento de lista | li > a { color: green; } |
| 2019 | Aplicar Flexbox a un div con identificador | div#principal { display: flex; } |
| 2019 | Qué muestra un vídeo con dos source | El primero que el navegador sepa reproducir |
Y una que anuló. En 2023 preguntó qué valor imprime console.log(4 * 3 ** 2) presentándolo como código «en JSON», cuando JSON es un formato de datos y no ejecuta nada: el código es JavaScript y el resultado, 36. La anuló por el enunciado, no por la operación, así que la precedencia de la exponenciación sigue siendo materia viva.
¿Te lo sabes? 🐂
Cien preguntas de este tema, escritas al estilo del cuestionario del INAP y contrastadas con los nueve exámenes oficiales que tenemos resueltos. Crea tu cuenta gratis para guardar tu progreso y repasar tus falladas. Gratis y siempre lo será.
