Integración, depuración y entrega

Tres horas. Media hora para aprender a clasificar un problema de CSS antes de tocarlo, y dos horas y media construyendo una interfaz desconocida, reparando una hoja rota y cerrando la entrega de la unidad.

Se explica

25 minutos · conceptos y demostración

Las dos mitades de la sesión son la misma habilidad vista de los dos lados: clasificar un problema antes de escribir código, y clasificar un fallo antes de corregirlo. Quien no clasifica, prueba cosas.

Dónde estábamos y dónde estamos

1. UD1 · estructura, semántica, contenido, formularios, accesibilidad
2. UD2 · presentación, Flexbox, Grid, responsive, componentes
3. = un sitio web estático completo

Antes de tocar CSS, clasifica

Ante una interfaz que no has visto, la pregunta no es qué propiedad usar: es de qué tipo es cada problema. Son seis, y no todas las zonas necesitan las seis.

Dejar una zona en flujo normal también es una decisión, y muchas veces es la correcta.

Un ejemplo de cómo se razona una casilla: las tarjetas de un catálogo se repiten en filas y columnas y su número debe depender del espacio, lo cual apunta a Grid con una plantilla adaptable. Dentro de cada tarjeta, imagen, texto y acción forman una relación en una dimensión, así que puede bastar el flujo normal o un Flexbox. Se resuelve cada nivel por separado.

Diagnosticar, no rehacer

Recibirás una página que se ve mal. La tentación es borrarlo todo y empezar de cero, y es exactamente lo que no vas a poder hacer en un trabajo: el CSS que te toque arreglar será de otro, tendrá años y funcionará en sitios que no puedes romper.

1. ¿Qué esperaba ver y qué veo?
2. Inspeccionar el elemento concreto que falla
3. ¿Qué reglas le llegan? ¿Cuáles están tachadas?
4. ¿Es un problema de selector, de cascada, de caja o de layout?
5. Corregir la causa, no el síntoma

El paso 4 es el que ahorra tiempo. Los cuatro tipos de problema se buscan en sitios distintos:

Las cuatro pestañas

Un procedimiento resuelve la mitad de los casos: en Styles, las casillas contiguas a cada declaración la desactivan en vivo. Desactivar propiedades una a una hasta que el problema desaparece te dice cuál era la culpable en veinte segundos, sin tocar el archivo.

Revisar el CSS de otra persona

Un compañero revisará tu proyecto. No evaluará si le gustan tus colores: eso no es revisable. Revisará lo técnico, y lo hará con el formato de la UD1: qué, por qué y qué harías tú.

No todas las sugerencias tienen por qué ser correctas. Aprender a evaluar una revisión también forma parte del ejercicio, y rechazar una observación justificándola bien puntúa igual que aceptarla. La regla de la UD1 sigue vigente: se revisa el código, no a la persona.

Se trabaja

150 minutos · interfaz nueva, hoja rota y cierre del proyecto

Los dos primeros pasos construyen; el tercero y el cuarto reparan. Los dos últimos cierran la unidad.

Paso 1 · Clasifica antes de escribir · 15 min

Recibes una captura y el HTML semántico de una página de actividades. La interfaz contiene una cabecera con navegación, un bloque destacado, un catálogo de tarjetas, una botonera de filtros y un aviso final. No recibes ninguna pista sobre las propiedades.

Rellena la tabla de seis decisiones de la explicación, zona por zona, antes de escribir una sola línea de CSS. Cuando la tengas, contrasta dos casillas con un compañero: si no coincidís, las dos posturas tienen que poder defenderse.

Paso 2 · Construye y defiende la interfaz · 45 min

Se entrega el HTML y una hoja con variables, tipografía y el box model ya preparados. Faltan deliberadamente la distribución del catálogo, el comportamiento de la navegación y los estados de los controles. Completa primero esas tres decisiones y comprueba cada una en DevTools antes de continuar.

La solución debe cumplir estos requisitos sin framework:

1. El contenido conserva una anchura legible y espacios coherentes.
2. La navegación funciona en una línea cuando cabe y no desborda cuando deja de caber.
3. El catálogo decide automáticamente cuántas columnas entran.
4. Las imágenes conservan proporción y encajan sin deformarse.
5. Los filtros y enlaces tienen estados de interacción y foco visibles.
6. No existe scroll horizontal entre 320 px y 1600 px.
7. Cada media query responde a una rotura que puedes señalar.

Al terminar, cambia un requisito: el orden de la navegación, la anchura mínima de tarjeta o la dirección de un componente. Predice el resultado, haz el cambio mínimo y explícalo. Una interfaz bien decidida absorbe ese cambio en pocos minutos.

Paso 3 · Quita el !important · 10 min

#main .listado div.card.producto {
    margin-left: 37px !important;
}

Esta regla funciona. Di tres cosas que están mal en ella, y cómo quedaría bien.

Ver respuesta

1 · El !important. Esconde un conflicto en vez de resolverlo, y obliga a que cualquier ajuste futuro sea otro !important.

2 · La especificidad. Un id, dos clases, dos elementos y una clase más: ese selector no se puede sobrescribir con nada razonable. Con .producto bastaría.

3 · El número mágico. 37px no sale de ninguna decisión: sale de mirar una pantalla. Colocar mediante margin-left es además síntoma de que falta un sistema de layout: si es separación entre elementos de una lista, es gap.

Quedaría en algo así como .producto { } sin margen, y un gap en el contenedor.

Paso 4 · CSS forense · 40 min

Recibirás una página cuya hoja de estilos contiene fallos deliberados de todos los tipos:

• La hoja no carga en una de las páginas.
• Un selector escrito con una errata, que no selecciona nada.
• Una regla con especificidad innecesaria que impide ajustar nada.
• Un !important puesto para tapar el problema anterior.
• Un elemento que desborda horizontalmente.
• Un width fijo en píxeles que rompe en móvil.
• Un Grid con columnas fijas que genera pistas demasiado estrechas.
• Un Flexbox sin flex-wrap cuyo contenido no cabe.
• Una imagen deformada.
• position: absolute usado para maquetar una zona entera.
• El foco invisible por un outline: none.
• Un color repetido catorce veces.
• Dos media queries que se contradicen.

Tu trabajo:

1. Localiza los problemas.
2. Clasifica cada uno en selector, cascada, caja o layout. Esa columna es la que se evalúa.
3. Corrígelos atacando la causa.
4. Explica las tres correcciones más importantes.

Estoy atascado · no sé por dónde empezar

Por lo que afecta a más cosas. Si la hoja no carga en una página, todo lo demás que veas ahí es ruido: arréglalo primero y vuelve a mirar.

Después, los desbordamientos, porque suelen tener una única causa que produce muchos síntomas. En último lugar, los detalles de cascada, que son locales.

Regla general de la sesión: si la regla no aparece en Styles es de selector; si aparece tachada es de cascada. Esa distinción te ahorra la mitad del trabajo.

Paso 5 · La auditoría final · 20 min

Recorre las cinco listas sobre tu propio sitio. Cada línea que no puedas marcar es trabajo pendiente de hoy.

Paso 6 · Revisión por pares y cierre de la entrega · 20 min

Intercambia el proyecto y rellena la matriz de revisión con el formato qué / por qué / qué harías. Después recibe la tuya y decide qué aceptas, justificando lo que rechaces.

Se entrega:

• A · El sitio. El mismo de la UD1, convertido en una web completa: diseño coherente entre las cuatro páginas, variables CSS para las decisiones repetidas, Flexbox y Grid donde corresponda, navegación adaptable, catálogo responsive, formulario con estilo propio, imágenes adaptables, estados :hover y :focus-visible, al menos una transición con una finalidad, y media queries solo donde hagan falta.
• B · La tabla forense del paso 4, con la columna de tipo de problema.
• C · La matriz de revisión del proyecto de tu compañero.
• D · Tus decisiones, en media página: las tres decisiones de layout de las que estés más seguro, y por qué.

Dedica los últimos minutos a preparar la defensa. Tres minutos y cuatro preguntas:

• Enseña una parte de tu sitio que se adapte sin media query, y explica por qué no la necesita.
• ¿Dónde has puesto un breakpoint y qué te dijo el contenido que lo pusieras ahí?
• Enseña un sitio donde dudaste entre Flexbox y Grid, y por qué elegiste lo que elegiste.
• ¿Has tenido que tocar el HTML de la UD1? Si sí, ¿dónde y por qué?

La defensa incluye una prueba en vivo: se te pedirá un cambio pequeño sobre tu propio CSS. Convertir un Grid de tres columnas en dos, cambiar el eje de un Flexbox, hacer que el menú funcione a 360 px, o quitar un !important sin romper nada. Si no puedes hacerlo, no controlas el código que has entregado.

No puntúa que el sitio sea vistoso. Puntúa que aguante: que siga funcionando cuando cambia el contenido, cuando cambia la pantalla y cuando lo usa alguien que no ve la tuya.

Ampliación si has completado el trabajo

Primero termina la entrega. Los dos retos apuntan a lo que viene después de esta unidad: componentes que deciden por su propio espacio, y leer un diseño ajeno.

Reto 1 · El componente que no pregunta por la pantalla

Una media query pregunta por el viewport. Una container query pregunta por el espacio del contenedor del componente, que no es lo mismo: la misma tarjeta puede aparecer en una columna estrecha de la portada y en el ancho completo de la ficha.

.zona-producto {
  container-type: inline-size;
}

@container (width >= 35rem) {
  .producto { grid-template-columns: 1fr 2fr; }
}

1. Coge tu tarjeta de producto y colócala en dos sitios de anchuras muy distintas de tu sitio.
2. Resuélvela primero con una media query y anota qué falla: en una pantalla ancha, la tarjeta de la columna estrecha recibe la disposición ancha aunque no le quepa.
3. Reescríbela con una container query y comprueba que ahora cada copia decide por su cuenta.
4. Explica en tres líneas por qué una media query no podía resolver esto, por muchos breakpoints que le pusieras.
5. Como segunda parte, reescribe un único componente con CSS anidado, donde & representa al selector exterior. Limita el anidamiento a uno o dos niveles y comprueba con DevTools que no has creado selectores más específicos de lo necesario. Anota qué especificidad tenían antes y después.

Reto 2 · Copiar un diseño es leerlo

Recibirás la captura de una interfaz pequeña, sin su código, y tendrás que reproducirla con HTML y CSS.

El objetivo no es la coincidencia píxel a píxel. Antes de escribir nada, contesta por escrito sobre la captura:

1. ¿Qué está agrupado con qué? Dibuja las cajas que ves, aunque no tengan borde.
2. ¿Qué está alineado con qué? Las alineaciones invisibles son las que delatan la cuadrícula.
3. ¿Qué espacios se repiten? Si encuentras tres medidas repetidas, ese es su sistema de espaciado.
4. ¿Qué zonas son Grid y cuáles Flexbox? Justifica cada una con la regla de una o dos dimensiones.
5. ¿Cuál es la jerarquía visual y con qué está construida: tamaño, peso, color o espacio?

Después constrúyela. Al terminar, compara tu respuesta 3 con las variables que has acabado escribiendo: si coinciden, has leído bien el diseño.

Cierre

5 minutos · comprobación y recuerdo

Ver respuestas

1 · Flujo normal, tamaño, espacio, distribución, comportamiento responsive y estado.

2 · Si la regla no aparece en Styles, no ha seleccionado nada: es de selector o de sintaxis. Si aparece tachada, sí seleccionó y perdió: es de cascada.

3 · Para desactivar propiedades en vivo y localizar cuál causa el problema sin tocar el archivo.

4 · Porque en un trabajo real el CSS es de otro, tiene años y funciona en sitios que no puedes romper. El segundo motivo es que rehacer el código no identifica dónde estaba el defecto.

5 · Se revisa lo técnico: cascada, responsive, accesibilidad, organización. No se revisa si gustan los colores.

6 · La media query pregunta por el viewport; la container query, por el espacio disponible del contenedor del componente.

---