Buenas prácticas

Escribir HTML que "funciona" es fácil; escribir HTML que funciona bien, se mantiene durante años y pasa la revisión de un cliente exigente es lo que te hace profesional. En esta lección reunimos las convenciones, herramientas y el checklist que deberías aplicar antes de entregar cualquier proyecto.

Concepto

Piensa en un electricista: dos instalaciones pueden encender la luz, pero una tiene los cables etiquetados, ordenados y siguiendo la norma, y la otra es una maraña que nadie más podrá reparar. Las buenas prácticas son "la norma" del HTML: hacen tu trabajo predecible, seguro y fácil de mantener por ti o por otros.

Convenciones de escritura

Formato

<!-- ✅ Minúsculas, comillas dobles, sangría consistente de 2 espacios -->
<section class="servicios" id="servicios">
  <h2>Servicios</h2>
  <ul>
    <li>Diseño web</li>
  </ul>
</section>

<!-- ❌ Mayúsculas, sin comillas, sangría caótica -->
<SECTION CLASS=servicios>
<h2>Servicios</H2>
      <ul><li>Diseño web</ul>
</SECTION>

• Etiquetas y atributos en minúsculas.
• Valores de atributos siempre entre comillas dobles.
• Sangría consistente (2 espacios es lo más común) y cierre de etiquetas no vacías.
• Usa Prettier en VS Code con "Format on Save" para no preocuparte por esto.

Nombres de clases e IDs

<!-- ✅ Describen QUÉ es, en kebab-case -->
<div class="tarjeta-producto">
<button class="boton boton-primario">

<!-- ❌ Describen cómo se ve o no dicen nada -->
<div class="caja-roja-izquierda">
<div class="div1">

• Usa kebab-case (tarjeta-producto) y nombres por función, no por apariencia (si el cliente cambia el rojo por azul, caja-roja miente).
• Metodologías como BEM (tarjeta__titulo, tarjeta--destacada) ayudan en proyectos grandes; lo verás en el curso de CSS.
• Los id son únicos por página. Para estilos, prefiere clases.
• Idioma: elige español o inglés para las clases y sé consistente en todo el proyecto.

Separación de responsabilidades

<!-- ❌ Estilos y comportamiento mezclados en el HTML -->
<p style="color: red; font-size: 20px" onclick="alert('hola')">Oferta</p>

<!-- ✅ HTML para estructura, CSS para estilos, JS para comportamiento -->
<p class="oferta" data-mensaje="hola">Oferta</p>

Evita atributos style y manejadores como onclick en línea. Pon el CSS en archivos .css y el JavaScript en archivos .js.

Comentarios útiles

<!-- ===== SECCIÓN: Testimonios ===== -->
<section class="testimonios">...</section>
<!-- /Testimonios -->

<!-- TODO: reemplazar con las fotos finales del cliente -->

Comenta el porqué o marca secciones grandes; no comentes lo obvio.

HTML válido

El navegador "perdona" errores, pero los errores provocan comportamientos distintos entre navegadores, problemas de accesibilidad y bugs difíciles de encontrar.

Validador W3C

1. Entra a validator.w3.org.
2. Pega la URL, sube el archivo o pega el código (Validate by Direct Input).
3. Corrige todos los errores y revisa las advertencias.

Errores frecuentes que detecta:

• Etiquetas sin cerrar o mal anidadas.
• id duplicados.
• <img> sin alt.
• Elementos donde no pueden ir (un <div> dentro de un <p>, un <li> fuera de una lista, un <a> dentro de otro <a>).
• Atributos que no existen o valores inválidos.

Valida mientras escribes

Instala la extensión HTMLHint en VS Code o configura un linter en tu proyecto. Detectarás los errores al momento, sin esperar al final.

Reglas de anidamiento que conviene memorizar

• Un <p> no puede contener elementos de bloque (<div>, <ul>, <h2>, otro <p>).
• Un <a> puede envolver bloques (una tarjeta completa), pero nunca otro <a> ni un <button>.
• Un <button> no puede contener elementos interactivos.
• <ul>/<ol> solo tienen hijos <li>; <dl>, solo <dt>/<dd> (o <div> que los agrupe).
• <table>: <caption>, <thead>, <tbody>, <tfoot>, <tr>; las celdas siempre dentro de <tr>.

Rendimiento desde el HTML

• Imágenes: formatos modernos, width/height, loading="lazy" excepto la principal, srcset (repasa Imágenes).
• Scripts: con defer (o type="module"), nunca bloqueando la carga.
• CSS: en el <head>, un solo archivo minificado si es posible.
• Fuentes: pocas familias y pesos; precarga la principal.
• Conexiones: adelanta las conexiones a dominios externos importantes.

<head>
  <!-- Abre la conexión con anticipación -->
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
  <!-- Precarga la imagen del hero (la más importante) -->
  <link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">
  <link rel="stylesheet" href="/css/estilos.min.css">
  <script src="/js/app.js" defer></script>
</head>

Seguridad básica

• Enlaces externos con target="_blank" → rel="noopener noreferrer".
• Formularios siempre validados también en el servidor; usa HTTPS.
• No dejes información sensible en comentarios, atributos data-* ni campos hidden.
• Incrusta iframes solo de fuentes confiables (y con sandbox si es posible).
• Si el formulario recibe mucho spam, agrega un campo trampa (honeypot) oculto o un captcha.

Compatibilidad

• Prueba en Chrome, Firefox y Safari (Safari en iPhone es el que más sorpresas da).
• Revisa en caniuse.com cualquier función reciente antes de depender de ella.
• Prueba en un celular real, no solo en el modo responsive del navegador.

Mantenimiento y entrega

• Estructura de carpetas ordenada (css/, js/, img/, fonts/).
• Nombres de archivo en minúsculas, sin espacios ni acentos.
• Usa Git desde el primer día; el cliente o el siguiente desarrollador te lo agradecerá.
• Incluye un README breve: cómo se publica el sitio y dónde se edita cada cosa.
• Entrega al cliente los accesos (dominio, hosting, Search Console) a su nombre.

Error común

Dejar contenido de relleno en producción: "Lorem ipsum", teléfonos 555-5555, enlaces a #, fotos de banco con marca de agua o el título "Document". Haz una búsqueda global en el proyecto de "lorem", "TODO" y href="#" antes de entregar.

Checklist profesional antes de entregar a un cliente

Copia esta lista y revísala en cada proyecto.

Estructura y código

• [ ] <!DOCTYPE html>, lang correcto, meta charset y meta viewport en todas las páginas.
• [ ] HTML validado en el W3C sin errores.
• [ ] Un solo <h1> por página y encabezados en orden.
• [ ] Estructura semántica: <header>, <nav>, <main>, <footer>.
• [ ] Sin estilos en línea ni código comentado o de prueba.
• [ ] Sin "Lorem ipsum", href="#" ni datos falsos.

Contenido y SEO

• [ ] <title> y meta description únicos en cada página.
• [ ] Open Graph con imagen de 1200×630 probada en WhatsApp y Facebook.
• [ ] Favicon, apple-touch-icon y theme-color.
• [ ] canonical en cada página; sin noindex en producción.
• [ ] robots.txt y sitemap.xml publicados y dados de alta en Search Console.
• [ ] JSON-LD (LocalBusiness u otro) validado.
• [ ] Ortografía revisada (acentos, mayúsculas, nombres del cliente).

Accesibilidad

• [ ] Todas las imágenes con alt adecuado.
• [ ] Contraste de colores AA.
• [ ] Navegación completa con teclado y foco visible.
• [ ] Todos los campos con <label>; errores comprensibles.
• [ ] Botones de solo icono con aria-label.
• [ ] Lighthouse Accesibilidad 95 o más; revisión con lector de pantalla.

Rendimiento

• [ ] Imágenes optimizadas (WebP/AVIF), con width/height y loading="lazy".
• [ ] Scripts con defer; CSS y JS minificados.
• [ ] Lighthouse Rendimiento 90 o más en móvil.

Funcionalidad

• [ ] Todos los enlaces funcionan (internos, externos, tel:, mailto:, WhatsApp).
• [ ] Formularios probados de punta a punta: el correo realmente llega al cliente.
• [ ] Mensajes de éxito y error en formularios.
• [ ] Probado en Chrome, Firefox, Safari y en celulares Android e iPhone reales.
• [ ] Página 404 personalizada.

Legal y entrega

• [ ] Aviso de privacidad (obligatorio si recolectas datos personales) y, si aplica, aviso de cookies.
• [ ] HTTPS activo y redirección de http a https y de www a la versión canónica.
• [ ] Analítica instalada (Google Analytics, Plausible…) si el cliente la pidió.
• [ ] Respaldo del proyecto y accesos entregados al cliente.

Casos de uso reales

• Antes de una presentación: corre Lighthouse y el validador; llega con un reporte de 95–100 en todas las categorías. Impresiona y justifica tu precio.
• Proyecto heredado: valida el HTML del sitio viejo para estimar cuánto trabajo implica arreglarlo.
• Equipo: acuerden convenciones (Prettier, idioma de clases, estructura de carpetas) desde el inicio.

Ejercicios

1. Encuentra y corrige los 6 problemas de este fragmento:

<P class="Precio" style="color:red">Oferta</P>
<div id="menu"></div>
<div id="menu"></div>
<a href="https://instagram.com" target="_blank">Instagram</a>
<p><div>Contenido</div></p>
<img src="Foto Producto.JPG">

2. Pasa por el validador W3C la página que hiciste en alguna lección anterior y corrige todos los errores.
3. Aplica el checklist completo a tu proyecto de la siguiente lección.

Ver solución

<!-- 1. Etiqueta en minúsculas, clase en kebab-case y sin estilo en línea -->
<p class="precio precio-oferta">Oferta</p>

<!-- 2. Los id deben ser únicos -->
<div id="menu-principal"></div>
<div id="menu-secundario"></div>

<!-- 3. Enlace externo seguro -->
<a href="https://instagram.com/cafearoma" target="_blank" rel="noopener noreferrer">Instagram</a>

<!-- 4. Un div no puede ir dentro de un p -->
<div><p>Contenido</p></div>

<!-- 5 y 6. Nombre de archivo sin espacios ni mayúsculas, y con alt -->
<img src="foto-producto.jpg" alt="Taza de cerámica negra" width="800" height="800">

/* El color va en la hoja de estilos */
.precio-oferta { color: #c62828; }

Resumen

• Escribe en minúsculas, con comillas dobles y sangría consistente; automatízalo con Prettier.
• Nombra clases por su función, en kebab-case; los id son únicos.
• Separa estructura (HTML), estilo (CSS) y comportamiento (JS).
• Valida siempre con el W3C y respeta las reglas de anidamiento.
• Cuida rendimiento (imágenes, defer, preconnect) y seguridad (noopener, validación en servidor).
• Usa el checklist profesional antes de cada entrega.