Por Qué el HTML Todavía Merece Práctica Deliberada

El HTML tiene un problema de imagen. Es el lenguaje que los desarrolladores tienen más probabilidades de decir que ya "conocen" sin nunca haberlo practicado deliberadamente, porque durante años la suposición habitual fue: copiar un fragmento, ajustar las clases, publicar. Las etiquetas semánticas, la estructura de formularios y las partes de CSS que realmente controlan el layout tienden a quedar de lado en favor de lo que un framework o una librería de componentes ya resuelve.

Eso funciona bien hasta que deja de hacerlo — una prueba técnica que pide marcado real en vez de importar un componente, una ronda de pizarra donde nadie puede abrir una chuleta, o un bug donde un div simplemente no se comporta y la respuesta mejor votada en Stack Overflow no aplica a tu estructura real. Ahí suele quedar claro por primera vez que "conozco HTML" en realidad significaba "reconozco HTML", no "puedo producirlo desde un archivo en blanco".

Reconocer el marcado no es lo mismo que escribirlo

Leer un div lleno de clases utilitarias y entender más o menos qué hace es una barra mucho más baja que sentarte a estructurar un formulario, una lista anidada o un layout de página semántico tú mismo, correctamente, sin una librería de componentes rellenando los huecos. La mayoría de quienes dicen conocer HTML en realidad desarrollaron una fuerte habilidad de reconocimiento de patrones sobre marcado que ya han visto antes — lo cual funciona bien hasta que el layout que tienen enfrente no coincide con nada memorizado.

Por qué los frameworks y las herramientas de IA ocultan esto por igual

El desarrollo frontend moderno entierra el HTML puro bajo JSX, abstracciones de componentes y frameworks de clases utilitarias, y la asistencia de IA entierra lo que queda de eso bajo generación de un solo paso. Ambos facilitan pasar meses sin escribir realmente un formulario, una tabla o una pieza de marcado semántico a mano — la página sigue renderizando correctamente, así que no hay ninguna señal obvia de que la habilidad subyacente se haya quedado en silencio.

En qué vale la pena tener fluidez real

• Estructura semántica. Saber cuándo usar section, article, nav o button en vez de un div genérico importa para la accesibilidad y el SEO, y es exactamente el tipo de cosa que resulta invisible hasta que un revisor, o un lector de pantalla, lo señala.
• Formularios, la columna vertebral poco glamorosa de la web. Las etiquetas vinculadas a los campos, los tipos de input correctos y los atributos de validación aparecen en casi todo proyecto real, y son lo primero que se salta cualquiera que solo haya ensamblado formularios desde una librería de componentes.
• Layout con CSS real, no solo clases utilitarias. Poder explicar por qué un layout flex o grid hace lo que hace, no solo qué clase lo arregló, es la diferencia entre depurar un bug de layout en un minuto o reordenar clases al azar hasta que algo se vea bien.
• El modelo de caja, todavía. El colapso de márgenes, padding vs. border, y por qué dos elementos no se alinean como el marcado sugiere que deberían — tiene décadas de antigüedad y sigue explicando la mayoría de la confusión cotidiana de layout.

Practicar HTML de la misma forma que cualquier otra cosa

El mismo principio que aplica a cualquier otro lenguaje aplica aquí: reconocer marcado correcto cuando ya está escrito no es la misma habilidad que producirlo tú mismo, bajo presión leve, sin nada que rellene los huecos. Es un músculo estrecho y específico, y como cualquier otro responde a ejercitarse a propósito en vez de incidentalmente.

El plan de HTML de SoloScript está construido exactamente para esto — ejercicios cortos y calificados de marcado y CSS que verifican el resultado renderizado, no una cadena exacta, así que hay más de una forma correcta de resolver cada uno.