Webs que se leen en la terminal: el estándar TermWeb

Nunca me he atrevido a escribir o definir un estándar para web, y mucho menos de diseño. Soy más técnico que cualquier otra cosa. Pero por diversión, esta vez lo voy a hacer. Voy a definir un patrón de diseño y desarrollo web que proporcione un layout y una experiencia de usuario coherentes en todos los navegadores de terminal, fácil de navegar con tabulación, respetando la verticalidad y sin depender de CSS, JavaScript ni imágenes. Y lo voy a hacer con reglas claras y verificables. A este estándar lo voy a llamar TermWeb.

Si quieres ver el origen de la idea, te recomiendo leer mi artículo donde hablo sobre cómo diseñar webs para navegadores de terminal. Profundizo sobre cuáles son las etiquetas adecuadas, las limitaciones y los puntos en común entre los distintos navegadores web de terminal. Al final logro agrupar un conjunto de reglas y buenas prácticas, las cuales amplío y formalizo aquí.

¡Aviso! No es un estándar de comité, sino mi humilde propuesta a partir de datos empíricos y la recopilación de algunos patrones de diseño ya existentes.

0. Principio y alcance

Las reglas siguen la convención de las RFC. DEBE es obligatorio, DEBERÍA es recomendado y PUEDE es opcional. Una página es conforme si cumple todos los DEBE.

Y hay dos anchuras que lo gobiernan todo. El texto normal fluye y lo recoloca el propio motor, pero lo que fijas tú a mano (arte ASCII, líneas de navegación, tablas, bloques <pre> y de código) tiene dos topes:

• DEBE caber en 80 columnas: el límite duro, el de la terminal de escritorio.
• DEBERÍA caber en 40 columnas: el ancho seguro, el que aguanta en el móvil en vertical y en las terminales estrechas. Coincide con el sucesor de las 79 columnas en el móvil y con el mínimo del rango de legibilidad, de 30 a 40 caracteres por línea.

1. Orden canónico del documento

En la terminal no hay float, ni flex, ni grid, ni order. Lo que pongas primero en el HTML sale primero en pantalla. Punto. Así que toda página DEBE seguir este orden en el código:

1. Enlace de salto al contenido
2. Cabecera: nombre del sitio y, como mucho, una línea de navegación corta
3. Migas de pan (salvo en la portada)
4. Contenido principal
5. Contenido complementario (relacionado, etiquetas)
6. Paginación, si la hay
7. Navegación completa
8. Pie

El contenido DEBE empezar en las primeras líneas de la pantalla. La navegación larga y el pie van al final. No hay columnas ni barras laterales: lo que sería lateral va en el punto 5.

Las etiquetas header, nav, main, aside y footer DEBEN usarse por su valor semántico, pero no te engañes: no añaden ni un salto de línea. La separación visual la dan los párrafos, los encabezados y <hr>.

2. Cabecera y logo

Lo primero que aparece. Que sea texto, que quepa y que lleve a casa.

• 2.1. El nombre del sitio DEBE ser texto y enlazar a la portada.
• 2.2. Si el logo es una imagen, su alt DEBE ser el nombre del sitio.
• 2.3. El lema, si existe, DEBERÍA ocupar una sola línea.
• 2.4. Un logo en arte ASCII PUEDE ir en <pre>, con 6 líneas como máximo. DEBE caber en 80 columnas y DEBERÍA hacerlo en 40, para que no reviente en móvil.
• 2.5. Cada página DEBE tener un <title> descriptivo: lynx y links lo muestran arriba y todos lo usan para identificar la página.
• 2.6. El documento DEBE declarar <meta charset="utf-8"> y DEBERÍA servirse por HTTPS.

3. Navegación

Nadie quiere tabular por treinta enlaces de menú antes de llegar a la primera frase. La navegación se poda.

• 3.1. La navegación de cabecera NO DEBE superar 5 enlaces ni una línea de 80 columnas, y DEBERÍA caber en 40.
• 3.2. La navegación completa DEBE ir al final y PUEDE funcionar como mapa del sitio.
• 3.3. NO DEBE haber desplegables ni submenús: la jerarquía se resuelve con páginas índice por sección.
• 3.4. Las páginas interiores DEBEN mostrar migas de pan: Inicio > Sección > Página.
• 3.5. El enlace de salto DEBE ser el primer enlace y DEBE estar siempre visible. Ocultarlo con una clase CSS no sirve: los cinco motores lo muestran igual.

4. Contenido

Si la estructura vive en las etiquetas y no en el CSS, se lee en cualquier parte.

• 4.1. La estructura DEBE marcarse con etiquetas, no con estilos: h1–h6, ul/ol, dl, blockquote, pre y code. Nunca un <div class="titulo">.
• 4.2. Cada página DEBE tener un único h1 y una jerarquía de encabezados sin saltos.
• 4.3. Los párrafos DEBEN ser <p> reales, no bloques separados con <br>.
• 4.4. Las páginas con más de 3 secciones DEBERÍAN empezar con un índice enlazado a anclas.
• 4.5. La fecha de publicación DEBE ser texto visible.
• 4.6. <details> NO DEBE usarse para ocultar contenido: ningún motor lo pliega y siempre se muestra todo.

5. Enlaces

En la terminal los enlaces se recorren con el tabulador, uno detrás de otro. Fuera de su frase, tienen que seguir significando algo.

• 5.1. El texto de cada enlace DEBE entenderse fuera de contexto. "Aquí" o "leer más" sin complemento no valen.
• 5.2. Los enlaces a otros formatos DEBERÍAN indicarlo: Manual (PDF, 2 MB).
• 5.3. Si se usan enlaces relativos, DEBERÍA declararse <base href>, que respetan los cinco motores.

6. Imágenes y multimedia

Solo EWW pinta siempre la imagen, y w3m únicamente en terminales capaces. En los otros cuatro motores, por defecto, la imagen es su alt. Que se te quede grabado: el alt no es un extra de accesibilidad, es tu contenido.

• 6.1. Toda imagen informativa DEBE tener un alt escrito como frase. Las decorativas DEBEN llevar alt="" explícito, porque un alt ausente muestra el nombre del archivo.
• 6.2. Ninguna información crítica DEBE depender de una imagen, de un color o de un icono. El color DEBE ir siempre acompañado de texto o de un símbolo ("Error:", un asterisco).
• 6.3. Las imágenes DEBERÍAN ofrecer srcset para que el motor que sí las pinta elija la resolución.
• 6.4. Quedan prohibidas las fuentes de iconos.
• 6.5. Audio y vídeo DEBEN ofrecer un enlace directo al archivo y una descripción o transcripción.
• 6.6. Una imagen incrustada como data: URI solo la pinta EWW; en el resto se ve su alt, así que no ahorra nada frente a un src normal y engorda el HTML. NO DEBERÍA usarse.

7. Tablas

w3m y EWW dibujan una rejilla ASCII sorprendentemente decente. Pero una rejilla no es una maqueta.

• 7.1. Las tablas DEBEN usarse solo para datos, nunca para maquetar.
• 7.2. Las tablas DEBERÍAN tener una sola fila de encabezados y NO DEBEN anidarse.
• 7.3. colspan y rowspan DEBERÍAN evitarse: lynx los aplana.
• 7.4. Una tabla DEBE caber en 80 columnas y DEBERÍA caber en 40, con pocas columnas y celdas cortas. Si no cabe, DEBERÍA convertirse en una lista estructurada.

8. Formularios e interacción

GET y POST funcionan en los cinco motores.

• 8.1. Todo formulario DEBE tener action, method y un botón de envío real (<button type="submit"> o <input type="submit">).
• 8.2. Cada campo DEBE tener name, porque los motores recogen los datos por name, y un <label> asociado.
• 8.3. La validación DEBE hacerse en el servidor, con los errores como texto al principio del formulario.
• 8.4. Tras un POST, el servidor DEBERÍA responder con una redirección (patrón Post/Redirect/Get).
• 8.5. NO DEBE haber CAPTCHA gráfico sin alternativa textual.

Un ejemplo mínimo, un pedido de café:

<form action="/pedido" method="post">
  <p><label>Tu nombre <input type="text" name="nombre"></label></p>
  <p><label>Cantidad <input type="number" name="cantidad" value="1"></label></p>
  <p><label><input type="checkbox" name="sin_leche" value="si"> Sin leche</label></p>
  <p><button type="submit">Pedir café</button></p>
</form>

Funciona igual en EWW que en Chrome, sin una sola línea de JavaScript.

9. Dependencias

• 9.1. Ninguna página DEBE necesitar JavaScript para mostrar su contenido o funcionar.
• 9.2. Ningún recurso de terceros DEBE ser necesario para leer el contenido.
• 9.3. El sitio DEBERÍA ofrecer un feed RSS o Atom.

10. Capa gráfica opcional

Con el CSS desactivado, la página DEBE seguir siendo legible. Si no lo es, el problema no es del navegador, es de tu HTML.

• 10.1. El CSS PUEDE mejorar tipografía, espaciado y color en navegadores gráficos.
• 10.2. El CSS NO DEBE reordenar visualmente los elementos (order, grid-area, posicionamiento absoluto) respecto al código.
• 10.3. Lo que está en el HTML se ve en terminal. Un display:none por clase se muestra en los cinco motores, y uno en línea solo lo respetan EWW y links. Si algo no debe verse, NO DEBE estar en el HTML.
• 10.4. El centrado y la alineación de texto (text-align) solo los aplica elinks; en los otros cuatro el texto va a la izquierda. Ningún diseño DEBE depender de ellos.
• 10.5. El color en línea depende de la terminal, y en muchas ni se ve. Sirve de mejora, jamás de información (regla 6.2).

Ejemplo real

Este es el esqueleto de una página conforme; cámbiale el contenido y tienes desde un blog hasta una tienda:

<!DOCTYPE html>
<html lang="es">
<head>
  <meta charset="utf-8">
  <title>Título del artículo - Mi sitio</title>
</head>
<body id="top">

<a href="#contenido">Saltar al contenido</a>

<header>
  <p><a href="/">Mi sitio</a>, subtítulo o pequeña descripción</p>
  <nav aria-label="Principal">
    <p><a href="/">Inicio</a> | <a href="/blog/">Blog</a> | <a href="/sobre-mi/">Sobre mí</a></p>
  </nav>
</header>

<nav aria-label="Migas de pan">
  <p><a href="/blog/">Blog</a> &gt; <a href="/blog/web/">Web</a> &gt; Artículo</p>
</nav>

<main id="contenido">
  <h1>Título del artículo</h1>
  <p>El primer párrafo empieza en las primeras líneas de la pantalla.</p>
</main>

<hr>

<nav aria-label="Todas las secciones">
  <p><a href="/">Inicio</a> | <a href="/blog/">Blog</a> | <a href="/proyectos/">Proyectos</a> | <a href="/sobre-mi/">Sobre mí</a> | <a href="/contacto/">Contacto</a> | <a href="/feed.xml">RSS</a></p>
</nav>

<footer>
  <p>2026, Tu nombre</p>
  <p><a href="#top">Volver arriba</a></p>
</footer>

</body>
</html>

Dos detalles que enseñan medio estándar. El separador es un <hr>: no lo fijas tú, cada motor lo dibuja al ancho de su ventana, así que nunca se sale de la pantalla. Y las listas de enlaces van dentro de <p>, porque <nav> no añade ni un salto de línea y, sin el párrafo, la cabecera y las migas se pegarían en la misma fila.

En el escritorio a 80 columnas cabe holgada; en un móvil a 40, la cabecera y las migas se parten en dos líneas y el <hr> se acorta, pero el orden y el contenido no se mueven.

Cámbiale el contenido por el de un sitio real y esto es lo que lee la terminal. La portada de Hacker News con estas reglas (dibujo los enlaces entre corchetes y el <hr> como una línea de guiones, al estilo de lynx):

[Skip to content]

HACKER NEWS - Links and discussion for curious hackers

[new] | [past] | [ask] | [show] | [submit]

TOP STORIES

1. [Designing websites for terminal browsers]
   (andros.dev)
   312 points by [andros] 4 hours ago | [87 comments] | [upvote]

2. [Show HN: A static site generator in 400 lines of Elisp]
   (github.com)
   198 points by [tanrax] 6 hours ago | [42 comments] | [upvote]

3. [Why SQLite's website weighs only 70 KB]
   (sqlite.org)
   156 points by [drh_fan] 8 hours ago | [31 comments] | [upvote]

4. [Ask HN: Do you still browse with lynx?]
   89 points by [oldschool] 9 hours ago | [120 comments] | [upvote]

[More stories »]

----------------------------------------

[new] | [past] | [comments] | [ask] | [show] | [jobs] | [submit]
[login] | [Guidelines] | [FAQ] | [API] | [Contact] | [RSS]

2026 - Y Combinator

[Back to top]

Y una página interna, con sus comentarios y un formulario incluidos:

[Skip to content]

HACKER NEWS - Links and discussion for curious hackers

[new] | [past] | [ask] | [show] | [submit]

[Top] > [Stories] > Designing websites for terminal browsers

DESIGNING WEBSITES FOR TERMINAL BROWSERS

[Read the article] (andros.dev)
312 points by [andros] 4 hours ago | [upvote] | 87 comments

ADD A COMMENT
Comment:
[________________________________________]
[Post comment]

COMMENTS

* [rahulj] 3 hours ago | [upvote] | [reply]
  I ran the validator against my blog: 94/100. It caught a jump
  from h1 to h4 I had never noticed.

    * [andros] 2 hours ago | [upvote] | [reply]
      Thanks! That's exactly the kind of friction it's meant to
      flag.

* [w3m_user] 3 hours ago | [upvote] | [reply]
  Funny that HN itself scores 55 but reads fine in w3m.

----------------------------------------

[new] | [past] | [comments] | [ask] | [show] | [jobs] | [submit]
[login] | [Guidelines] | [FAQ] | [API] | [Contact] | [RSS]

2026 - Y Combinator

[Back to top]

Apuntes finales

No voy a decir nada que no se haya dicho antes: el HTML manda y lo demás son mejoras de presentación. Adaptar una página web tiene trabajo, al igual que adaptarla a móvil. Priorizar una buena representación en terminal es una decisión de diseño, no un accidente: hay que escribirla bien.

Si necesitas alguna referencia, puedes usar mi humilde script TerminalSpeed Insights como primer paso, pero no lo consideres el validador definitivo: ese eres tú.

Fuentes

• Web Design for Terminal Browsers, mi artículo previo: el experimento con los cinco motores del que sale casi todo esto (bloques 0, 1, 4, 6, 8 y 10).
• Justificar a mano, ahora a 35 columnas: el cálculo del ancho seguro para móvil y el rango de legibilidad (bloque 0).
• Mejora progresiva de GOV.UK: la capa HTML manda, lo demás es mejora (bloques 0 y 10).
• WAI / WCAG del W3C: salto al contenido y orden con sentido (bloques 1, 3 y 5).
• Viewable with Any Browser: texto primero, sin depender de imágenes (bloques 2 y 6).
• Brutalist Web Design: el estilo solo para resolver problemas, no para decorar (bloque 10.1).