Brennen Puth: el CSS que hace imprimible tu web

Un CTRL-P que casi nadie prueba

12 puntos es el tamaño de fuente que Brennen Puth decidió usar para el cuerpo de texto de su web cuando se imprime. No lo sacó de un manual de diseño: lo sacó de imprimir su propia página y comprobar que el texto salía unas dos tallas más grande de lo razonable. El resto del resultado tampoco le gustó.

Ese es el punto de partida de una entrada que publicó en su blog personal y que incomoda más de lo que parece. Casi todos los equipos de producto revisan cómo se ve su web en móvil, en tablet y en escritorio. Muy pocos abren el diálogo de impresión para ver qué pasa cuando alguien intenta guardar ese contenido en papel o en PDF.

Para un founder, la pregunta no es estética. Es cuántas veces tu mejor artículo, tu guía de onboarding o tu comparativa de precios terminan convertidos en un PDF ilegible que alguien reenvía por correo.

El diagnóstico: tres fallos en una web sencilla

Puth describe su sitio como algo que no tiene nada de complejo. Aun así, al imprimirlo encontró tres problemas concretos:

• El texto salía demasiado grande, alrededor de dos niveles por encima de lo que funciona en papel. Su web usa tipografía de escala variable, que en pantalla se ve bien y en una hoja impresa se desborda.
• La cabecera se veía francamente fea en formato impreso, sin aportar nada al documento.
• Los enlaces aparecían en un gris poco legible al imprimir en blanco y negro, porque el azul de la web se traduce en un tono lavado cuando no hay color.

Ninguno de los tres es un bug. Son decisiones de diseño tomadas pensando solo en la pantalla, que es exactamente el sesgo que él señala: durante un tiempo, imprimir documentos desde páginas HTML fue un foco importante del diseño web, y esa conversación prácticamente desapareció.

Las reglas CSS que usa (y que puedes copiar)

La solución que aplicó cabe en un bloque @media print y un par de clases auxiliares. El autor dice explícitamente que no es protector con su código y que cualquiera puede tomarlo.

Dos clases para controlar qué se ve en papel. .onlyPrint arranca con display: none y solo aparece dentro del bloque de impresión. Él la usa para añadir una pequeña atribución de autoría bajo el subtítulo, algo que en pantalla no tiene sentido y en papel sí. .noPrint hace lo contrario: se oculta al imprimir, y la aplicó a la cabecera.

Tamaños en puntos, no en píxeles. Dentro del bloque de impresión fija p y ol en 12pt, los subtítulos h3 y h4 en 13pt, h2 en 14pt y h1 en 16pt. Su razonamiento es simple: 12pt es un tamaño razonablemente aceptado para texto impreso, y una escala ligeramente mayor para los encabezados mantiene la jerarquía sin gritar.

Enlaces en negro. Un a { color: black !important } dentro del bloque de impresión. El azul funciona en pantalla, pero en escala de grises se pierde; igualar el color al del resto del texto resuelve el problema sin tocar la versión digital.

Ajustes para bloques de código. Aplica un borde negro de 3px al contenedor y baja la tipografía a 11pt. Es la parte que él mismo califica como la menos resuelta.

¿Vale la pena dedicarle una mañana a esto?

El propio Puth es honesto sobre la duda: dice que le llevó una buena parte de la mañana esconder y mostrar las cosas correctas, que su sitio no es complejo y que sospecha que muy poca gente imprime páginas web. Incluso admite que puede ser el único.

Esa honestidad es la parte más útil del texto. Porque el argumento que da a continuación no depende de que imprimir sea masivo: si todo lo que tu web ofrece es texto, permitir que la gente lo consuma en el formato que prefiere nunca es mala idea.

Traducido al negocio de una startup, hay tres escenarios donde esto deja de ser un detalle de artesanía y se vuelve operativo:

• Contenido que se guarda y se comparte. Guías, checklists, plantillas e informes sectoriales se descargan como PDF desde el propio navegador. Si esa exportación sale mal, tu material de marca viaja con la peor versión posible de tu diseño.
• Documentación técnica y de producto. Un equipo que documenta integraciones o APIs sabe que sus usuarios imprimen o archivan páginas. Un bloque de código que se corta entre dos hojas es exactamente el tipo de fricción que genera tickets de soporte.
• Ventas y propuestas. Cuando alguien del otro lado imprime una página de precios para llevarla a una reunión, el resultado es tu propuesta comercial. Conviene que se lea.

El coste es bajo: unas horas de un desarrollador y un bloque de CSS que no afecta en nada a la versión de pantalla. El retorno no se mide en conversiones, se mide en que el contenido siga siendo utilizable fuera del navegador.

Qué significa esto para tu startup

Acción 1: haz la prueba esta semana. Abre las tres páginas que más tráfico reciben de tu web y pulsa CTRL-P o Cmd-P. No hace falta imprimir: la vista previa del diálogo ya te muestra qué se rompe. Mira si el menú de navegación ocupa media hoja, si el banner de cookies aparece en el papel, si los enlaces desaparecen en gris y si las imágenes se salen del margen. Es un diagnóstico de diez minutos.

Acción 2: añade un bloque @media print mínimo. Con dos clases basta para empezar: una que oculte lo que no aporta en papel (navegación, formularios de suscripción, avisos emergentes) y otra que muestre lo que solo tiene sentido impreso, como la autoría del artículo o la URL canónica. Fija los tamaños del cuerpo en puntos y fuerza los enlaces a negro. Nada de esto toca la experiencia en pantalla.

Acción 3: decide qué contenido es tu activo imprimible. No todas las páginas merecen el esfuerzo. Si publicas guías largas, informes o material de referencia, esas son las que la gente guarda. Empieza por ahí y deja el resto para después.

El problema que sigue abierto: los bloques de código

Puth cierra su repaso con una admisión poco habitual en un post técnico: los bloques de código siguen siendo la parte más fea del resultado. Quieren salir como un solo bloque y no romperse en el borde de la página, y él pide abiertamente una solución a quien la tenga.

Para una startup que vende herramientas para desarrolladores, ese detalle no es menor. La documentación es producto, y la documentación impresa mal cortada es producto defectuoso. Si tu equipo encuentra la manera de resolverlo, tienes una mejora concreta que la mayoría de tus competidores no ha tocado.

Conclusión

La idea central del texto no es técnica, es de criterio de producto. Puth lo formula así: el camino hacia el buen software está pavimentado con gestos amables de los ingenieros hacia sus usuarios, y quizá algún día alguien encuentre ese gesto y sonría, aunque sea por un instante.

Ese es un estándar razonable para evaluar cualquier detalle de tu web. No todo lo que construyes tiene que mover una métrica. Algunas cosas solo tienen que funcionar cuando alguien las necesita, incluso si ese alguien eres tú dentro de seis meses intentando archivar tu propio artículo.

Fuentes

• https://brennenputh.me/blog/printable-websites (fuente original)