Diseño Web para Terminal

Read in English

Voy a hacer un ejercicio de puro entretenimiento: una guía de diseño web para navegadores de terminal. A partir de los navegadores de texto más usados, voy a sacar un conjunto de reglas por si algún día decides hacer una web cuyo objetivo sea una lectura y visualización óptimas en un terminal. No es una alternativa a Gemini, Gopher ni un intento de smallweb, sino una guía de buenas prácticas para que tu web se lea bien en un navegador de terminal, e incluso que puedas construir Web Apps para el terminal.

Cinco motores, una prueba

Lo primero es instalar los cinco motores de texto que de verdad usa la gente y pasarles las mismas páginas de prueba, aislando una característica cada vez.

  • w3m (0.5.6): el más capaz con tablas, e incluso pinta imágenes en terminales que lo permiten.
  • lynx (2.9.3): el patriarca, el mínimo común denominador desde 1992.
  • links (2.30): rápido, con un pelín de CSS.
  • elinks (0.20.0): el primo con más ambiciones, tiene hasta un motor de CSS opcional.
  • EWW: el de Emacs.

Ahora toca buscar los cruces de compatibilidad. Hay que probar características de HTML y CSS, y ver cómo las interpreta cada motor.

Los resultados:

Característica EWW w3m lynx links elinks
JavaScript No No No No No
Hojas <style> / <link> No No No No Parcial
display:none inline Oculta Muestra Muestra Oculta Muestra
display:none por clase Muestra Muestra Muestra Muestra Muestra
color inline Sí (con contraste) Depende del terminal Depende del terminal Depende del terminal Depende del terminal
text-align No No No No Sí
Tablas de datos Sí Sí Sí (sin bordes) Sí Sí
colspan / rowspan Sí Sí Aplana Sí Sí
Imágenes gráficas Sí En terminal No No No
alt de una imagen rota Sí Sí Sí Sí Sí
srcset Sí (elige resolución) alt/src alt/src alt/src alt/src
data: URI en imagen Sí alt alt alt alt
Formularios GET/POST Sí Sí Sí Sí Sí
<details> plegable No No No No No
Espaciado de <article>, <section>... No No No No No
<base href> Sí Sí Sí Sí Sí
<title>, <pre>, <hr>, listas Sí Sí Sí Sí Sí

De aquí sacamos conclusiones generales:

  • El JavaScript no existe. En ninguno. No es que sea lento o parcial. Es que no hay intérprete.
  • El CSS es casi un espejismo. Las hojas de estilo, ya sean <style> o <link>, se ignoran en todos salvo en elinks, que aplica cuatro cosas como text-align. Cuatro de cinco motores no leen tu CSS. Diséñalo asumiendo que no está.
  • display:none es una trampa. Si escondes algo con una clase (class="oculto" y .oculto{display:none} en tu hoja), los cinco motores lo muestran. Todos. Porque no leen la hoja: no ocultes nada importante con CSS. Si no debe verse, no lo pongas en el HTML.
  • Las imágenes son texto. Solo EWW (y w3m en algunos terminales) pintan la imagen de verdad. En los demás, la imagen es su atributo alt. Los cinco caen al alt cuando la imagen está rota, y una imagen sin alt te deja un [hero] con el nombre del fichero, o directamente nada. El alt no es accesibilidad para otros, es tu contenido.
  • <details> no se pliega. Ninguno de los cinco lo hace interactivo. El resumen y el cuerpo se muestran siempre, uno detrás del otro.
  • Las etiquetas semánticas de HTML5 no se ven. article, section, nav, header, footer, main, aside: son contenedores transparentes. No añaden ni un salto de línea. Su valor es semántico, no visual.

Con ello, ya podemos sacar unas líneas de diseño y buenas prácticas.

8 reglas para publicar en la terminal

1. El orden del DOM manda

No hay float, ni flex, ni grid, ni order. Lo que pongas primero en el HTML, sale primero en pantalla. Así que coloca el contenido nada más abrir el <body> y manda la navegación larga y el pie de página al final. Un lector que abre tu artículo no quiere teclear treinta enlaces de menú antes de llegar a la primera frase.

2. Estructura con etiquetas, no con estilos

Encabezados reales <h1>..<h6> para la jerarquía, nunca un <div class="titulo-grande">. Listas con <ul>/<ol>, definiciones con <dl>. Citas con <blockquote>, que todos indentan. Código con <pre> y <code>. Cada motor les da un tratamiento propio: úsalas por lo que significan.

3. Tu página debe leerse con el CSS apagado

Es la piedra de toque. Si desactivas el CSS y tu página se vuelve ilegible, no es un problema del navegador de terminal, es un problema de tu HTML. El espaciado (margin, padding, line-height) no existe: la separación la dan los párrafos. Estructura con <p> de verdad, no con <br> sueltos.

4. No transmitas información solo con color

Un "campo obligatorio en rojo" o un "verde = correcto" se evaporan. El color inline es lo más frágil de la tabla: depende del terminal y de su configuración, y en muchos casos ni aparece. Acompaña siempre el color con texto o un símbolo. "Error:" delante, un asterisco, lo que sea.

5. Tablas solo para datos, jamás para maquetar

EWW y w3m dibujan una rejilla ASCII sorprendentemente buena, con colspan y rowspan incluidos. Pero una tabla de maquetación produce una cuadrícula absurda e ilegible. Vigila el ancho: si la suma de columnas supera el del terminal, la experiencia se degrada. Menos columnas y celdas cortas ganan.

6. Imágenes con alt descriptivo y srcset

El alt es lo que se ve en cuatro de cinco motores. Que sea una frase, no un imagen1.png. Y si la imagen es pura decoración, ponle un alt="" explícito: así el lector la ignora en vez de leerte el nombre del fichero. Que falte el alt y que sea vacío no son lo mismo. Ofrece srcset con varias resoluciones, que el motor que sepa mostrar imágenes ya elegirá la adecuada. Y no dependas de una imagen para comunicar algo crítico, porque en la mayoría de motores no se cargan en absoluto.

7. Formularios de verdad

Nada de envíos por JavaScript. Un <form> con su action y su method (GET o POST), y un <input type="submit"> o un <button>. Pon name en todos los campos: los motores recolectan por name, y un campo sin name se pierde. Asocia un <label> a cada uno.

8. Cabeceras que sí cuentan

<title> siempre, descriptivo: lynx y links lo centran arriba, y todos lo usan para identificar la página. <meta charset> en UTF-8 como fallback de codificación. <base> si usas enlaces relativos, que todos respetan. Y sirve por HTTPS, que varios motores avisan del estado del certificado.

TerminalSpeed Insights

Una guía que no puedes ejecutar es una lista de buenos propósitos. Así que escribí un prototipo. Es un script de Python que lee un HTML, o una URL, y te devuelve una puntuación de legibilidad con los avisos concretos. El número es un heurístico, no una ciencia. Reparto los puntos a ojo, un error pesa más que un aviso y punto. Lo que de verdad importa es la lista de avisos, no el marcador.

Puedes descargarlo desde su repositorio, TerminalSpeed Insights, y lanzarlo contra cualquier página:

python3 terminalspeed.py https://tu-sitio.dev/

Pasándolo por algunos sitios populares, enfocados más al contenido que al diseño, tengo algunos números:

Sitio Puntuación
andros.dev (este blog) 100
text.npr.org (versión de solo texto de NPR) 100
motherfuckingwebsite.com 100
emacswiki.org 94
suckless.org 94
gnu.org 88
Páginas de manual en man7.org 88
Wikipedia (un artículo) 46
Hacker News 55

Arriba están las wikis, las docs, los sitios de texto y los que hacen bandera del minimalismo. Abajo, curiosamente, dos de los sitios más queridos por la gente que lee en terminal. No es casualidad: los que puntúan alto sirven el contenido primero y se apoyan en las etiquetas, no en el CSS. La EmacsWiki, por ejemplo, es casi HTML plano, y por eso se lee en cualquier cosa que sepa mostrar texto.

Sin embargo, son números que no todos los navegadores comparten. Abre Hacker News en w3m y verás la portada perfectamente legible, con su lista de titulares numerada, pese a ese 55. W3m dibuja las tablas tan bien que sobrevive. El validador no se equivoca al penalizarlo, señala fricción real, pero la fricción no siempre es una condena. Toma la puntuación como una orientación, no como un veredicto: un 100 casi te garantiza que se lee bien, un número bajo te dice dónde mirar.

No solo documentos: una Web App Terminal

Hasta aquí te he hablado de documentos: artículos, fichas, páginas de docs. Nos falta sacarles jugo a los formularios: GET y POST funcionan en los cinco motores. Y un formulario que funciona es, ni más ni menos, una aplicación.

Te lo demuestro con una cafetería:

<form action="/order" method="post">
  <p><label>Your name <input type="text" name="name"></label></p>
  <p><label>Quantity <input type="number" name="qty" value="1"></label></p>
  <p><label><input type="checkbox" name="no_milk" value="yes"> No milk</label></p>
  <p><button type="submit">Order coffee</button></p>
</form>

Y así se ve en EWW, el navegador de Emacs. Los campos se editan con el teclado; aquí ya he puesto el nombre, la cantidad y he marcado "No milk":

Formulario de pedido de café en EWW, el navegador de Emacs, con el nombre "Bob", cantidad 2 y la casilla "No milk" marcada, y un botón "Order coffee"

Pulsas enviar y el <form> hace un POST. El servidor responde con un redirect (el patrón Post/Redirect/Get de toda la vida) y el navegador pinta la confirmación, todo sin salir del teclado ni tocar el ratón:

Confirmación del pedido en EWW, el navegador de Emacs: "Order confirmed. Coming right up: 2 coffees without milk for Bob. Total: 2.40 EUR" con un enlace para hacer otro pedido

Fíjate en el detalle: encabezado en negrita, el enlace coloreado, la cantidad y la opción sin leche recogidas correctamente. Es una app con estado, interactiva, sin JavaScript y sin un solo kilobyte de framework. Y sí, saca 100 con el validador.

Es una aplicación de verdad: vive en el navegador de texto, pero se ve igual de bien en Chrome o Firefox, porque por debajo solo hay HTML. Consigues una interfaz de terminal sin tocar ncurses ni ninguna librería de TUI. Tu toolkit es HTML, tu renderizador es el navegador y tu lógica vive en el servidor. La misma app, un lenguaje que ya conoces, y funciona en todas partes.

Conclusión

Ha sido una investigación divertida. Casi nadie diseña sus sitios para la terminal, es una minoría y, sin embargo, es un público que existe. Y razones no faltan: son visitantes que buscan accesibilidad o velocidad, que tienen resoluciones bajas o que trabajan con pipes. Más de una vez me he encontrado haciendo búsquedas rápidas en EWW, o leyendo algún artículo por la comodidad visual.

Puedes verlo como artículo curioso o como otro tipo de enfoque de diseño web. Yo al menos empezaré a mirar mis páginas con otros ojos.

Espero que te haya gustado este otro punto de vista sobre el diseño web.

Este trabajo está bajo una licencia Attribution-NonCommercial-NoDerivatives 4.0 International.

Ayúdame a seguir escribiendo

Cada café me da un empujón para escribir el siguiente artículo.

Ko-fi donations¡Claro, te invito!

Comentarios

Todavía no hay ningún comentario.

Sigue leyendo