por qué este blog está compuesto en una serif

6 de septiembre de 2026 meta cssdesign

Todos los blogs de desarrollador que leí antes de construir este usaban la misma tipografía. Inter, o system-ui, o alguna sans geométrica que se ve genial en una librería de componentes y no dice nada de la persona que escribe. El mío no. Abre cualquier página aquí y estás leyendo Literata, una serif, tanto en los títulos como en el cuerpo del texto. Eso no fue casualidad y tardé más en decidirlo de lo que esperaba.

La cabecera de la portada compuesta en Literata

el encargo que me di a mí mismo

Cuando me senté a rehacer el aspecto de este sitio (todo el asunto pasó por más rondas de rediseño de las que quiero admitir, registradas como V1 a V7.3 en mis propias notas por si quieres el detalle vergonzoso) el primer intento fue "notas de campo, musgo y papel". Energía genérica de blog de naturaleza. Mi propio crítico, es decir yo mismo una semana después, lo rechazó por leerse exactamente igual que cualquier otra plantilla de blog por ahí. La idea que sobrevivió fue "el diario, en voz alta": algo que se lea como un cuaderno de verdad que alguien lleva, no una página de marketing de contenidos con un blog pegado.

Una tipografía de palo seco para interfaces no te lleva hasta ahí por sí sola. Sans es lo que uno elige por defecto porque todo sistema de diseño viene con una, y porque se renderiza limpia en tamaños pequeños de interfaz. Pero un párrafo de cuerpo compuesto en una sans geométrica se lee como software, no como escritura. Las serifas cargan esa asociación antigua con periódicos y libros lo quieras o no, y como este sitio trata sobre todo de mí escribiendo sobre lo que construí y lo que salió mal, quería que se leyera como algo escrito, no como un panel de control.

por qué Literata en concreto

No quería una serif de exhibición que solo funcione a tamaño de titular y se desmorone a 17px. Literata está construida exactamente para esto, empezó como un proyecto de Google para lectura en pantalla a tamaño de libro, y viene como fuente variable, pesos del 400 al 900, redonda y cursiva, en un solo archivo por estilo. Eso importa porque un peso pesado para h1 y uno ligero para el cuerpo vienen de la misma tipografía en vez de dos fuentes distintas fingiendo hacer juego.

--font-display: 'Literata', ui-serif, Georgia, serif;
--font-body: 'Literata', ui-serif, Georgia, serif;
--font-mono: 'IBM Plex Mono', ui-monospace, monospace;

Tanto display como body apuntan a la misma familia. Los títulos y los párrafos son la misma tipografía en pesos distintos, que es parte de lo que hace que toda la página se lea como una sola voz en vez de una fuente de titular haciendo una actuación sobre un cuerpo de texto genérico debajo.

el error del CDN

En el primer intento de configurar esto hice lo que todo tutorial te dice que hagas: etiqueta link directa a Google Fonts, listo en cinco minutos.

<!-- first pass -->
<link
	rel="stylesheet"
	href="https://fonts.googleapis.com/css2?family=Literata:wght@400..900&display=swap"
/>

Funcionó, en el sentido de que la tipografía aparecía. Lo que no pensé hasta más tarde es que esto significa que el navegador de cada visitante hace un segundo viaje de ida y vuelta a Google antes de que el texto real pueda renderizarse, y si esa petición es lenta o está bloqueada, entra la pila de respaldo y luego se intercambia debajo de ti, que es el destello de texto sin estilo del que todo el mundo se queja pero que nadie nombra bien (no es "sin estilo", es "con el estilo equivocado durante un segundo").

El arreglo fue vendorizarla. Saqué los archivos woff2 reales de la API CSS2 de Google Fonts una vez, a mano, y los subí bajo static/fonts/, reducidos a latin más latin-ext para no enviar tablas de glifos cirílicos y griegos que nadie en este sitio necesita:

@font-face {
	font-family: 'Literata';
	font-style: normal;
	font-weight: 400 900;
	font-display: swap;
	src: url('/fonts/literata-normal-latin.woff2') format('woff2');
	unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304,
		U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

Cuatro bloques de estos en total, redonda y cursiva, latin y latin-ext, cada uno con su propio unicode-range para que un navegador solo descargue el subconjunto que realmente necesita para renderizar la página que tiene delante. Sin paquete npm, sin CDN de fuentes en tiempo de ejecución, nada apuntando ya a un servidor de Google. IBM Plex Mono, la fuente de los bloques de código, sigue viniendo del CDN de Google Fonts porque es una petición mucho más pequeña (un solo par de pesos, usado para código, no toda la página) y todavía no me he puesto a vendorizarla también. La coherencia diría que debería. Aún no lo he hecho.

la medida de lectura, lo que nadie nota hasta que está mal

Hay una clase CSS en el layout llamada .measure:

.measure {
	max-width: 68ch;
}

ch es una unidad que significa "más o menos el ancho del carácter 0 en la fuente actual". Limita el cuerpo del texto a 68 de esos y estás limitando la longitud de línea a algo entre 65 y 75 caracteres dependiendo de las formas de las letras, que es el rango que la gente de tipografía lleva décadas citando como el punto óptimo antes de que el ojo empiece a perder el sitio al saltar de vuelta al inicio de la siguiente línea. El texto a ancho completo en un monitor grande sin control de medida es genuinamente incómodo de leer más allá de un párrafo, y casi ninguna plantilla de blog se molesta en imponerlo, simplemente dejan que la columna de contenido se estire hasta donde le dé la cuadrícula.

No conocía este término antes de empezar a fijarme en por qué algunos blogs se sienten fáciles de leer y otros se sienten como trabajo incluso cuando la escritura en sí está bien. No son las palabras, es la longitud de línea.

la razón real, debajo de todo eso

Toda la justificación técnica es cierta pero también es un poco a posteriori. La razón real es que quería que esto se sintiera mío y no como un tema que instalé. Un tipo en Lovund escribiendo sobre scripts de Django y medias maratones en la misma tipografía que Random House usa para libros de verdad se sentía como el desajuste justo. La mayoría de los blogs de desarrollador son sans porque "limpio" y "técnico" se equipararon en algún punto del camino y nadie lo cuestionó. El mío no tiene por qué parecer una página de aterrizaje de SaaS. No lo es.

la escala tampoco es plana

Una vez decidida la tipografía todavía tenía que decidir cuánto volumen le tocaba a cada tamaño respecto a los demás. La escala tipográfica aquí corre a una proporción de aproximadamente 1,25 entre pasos, un h3 a 1.3125rem, h2 a 1.6875rem, hasta h1 a 2.125rem, con el cuerpo de texto a 1.0625rem y una altura de línea de 1.65 (ese número importa casi tanto como la elección de tipografía, demasiado apretado y una serif a tamaño de cuerpo se vuelve visualmente ruidosa, demasiado suelto y los párrafos empiezan a sentirse desconectados entre sí). Los títulos de las entradas en concreto no siguen esa escalera de pasos fija en absoluto, escalan con clamp() entre 2.25rem y 3.5rem según el ancho de la ventana, ya que el título de una entrada es el único lugar de una página donde quería un momento de exhibición genuinamente sonoro en vez de un peldaño más en una escala predecible. h1 lleva el peso más pesado de la página, 800, mientras que h2 a h4 se quedan todos en 700, así que hay exactamente un "grito" en toda la jerarquía y todo lo demás se mantiene un escalón más callado que él, a propósito.

0 comentarios

Inicia sesión para comentar.

Iniciar sesión

¿No tienes cuenta?