Las webs deberían poder imprimirse bien

Websites Should Be Printable

Brennen Puth reivindica que los sitios web cuiden cómo se ven al imprimirse. Con unas pocas reglas CSS (@media print) ajusta tamaños de fuente, oculta el encabezado y convierte los enlaces azules en negro para que el papel sea legible. Aunque duda que mucha gente imprima páginas, sostiene que si el contenido es solo texto, ofrecer una buena experiencia de impresión es un gesto de amabilidad hacia el usuario.

El camino hacia un buen software está pavimentado con gestos de amabilidad de los ingenieros de software hacia sus usuarios.
  1. beej71

    Aunque estoy de acuerdo con tener una buena estructura HTML que se imprima bien, y estoy de acuerdo con ocultar elementos de navegación, etc., no estoy tan de acuerdo con cambiar el tamaño de fuente predeterminado o las fuentes en la versión de impresión.

    Acabo de hacer un sitio simple que no establecía ningún tamaño de fuente en ningún lado, y un amigo mío se quejó de que la fuente era demasiado pequeña en el móvil. ¿Acaso detecto una pantalla de baja resolución y aumento el tamaño de fuente?

    Sé que muchos sitios hacen exactamente eso, pero siento que está mal. El usuario controla su tamaño de fuente predeterminado en su plataforma. ¿Y si ya lo hubieran aumentado, y ahora yo solo lo estoy haciendo más grande?

    ¿Y si hubieran disminuido su tamaño de fuente de impresión predeterminado y luego yo lo reduzco de nuevo?

    Creo que es mejor dejarlo completamente en manos del usuario.

  2. pidgeon_lover

    Estoy de acuerdo en que los sitios web deberían poder imprimirse. Soy fan del RSS y de las pantallas eInk (Kindles, y cuando pueda permitírmelo, un monitor de PC), y los sitios web imprimibles facilitarían su uso en pantallas similares al papel.

    He estado usando la extensión de navegador PrintFriendly [1] durante años (para imprimir sitios web que de otro modo no se pueden imprimir), pero ha empeorado, así que al buscar alternativas empecé con The Printliminator [2] (que usa el framework CSS Haartija [3]) y actualmente he terminado usando CopyAsMarkdown [4] (con Pandoc) y WebToEpub [5]

    [1] https://www.printfriendly.com/

    [2] https://github.com/CSS-Tricks/The-Printliminator

    [3] https://github.com/vladocar/Hartija---CSS-Print-Framework

    [4] https://github.com/yorkxin/copy-as-markdown/

    [5] https://github.com/dteviot/WebToEpub

  3. armcat

    Disiento respetuosamente. La intención original que tenía Tim Berners Lee [1] era crear una forma navegable de encontrar documentos e información. No imprimible. Todo el problema que tenemos hoy es que hemos difuminado ambos conceptos: el navegable y el imprimible. Un sitio web debería ser simplemente un espacio limpio y sencillo para navegar fácilmente y transmitir la información deseada. Para imprimir, tenemos latex y otros métodos de marcado que son perfectos para eso.

    [1] https://info.cern.ch/hypertext/WWW/TheProject.html

  4. swiftcoder

    Graciosamente, cuando pulso CMD-P en este sitio web en concreto, termino con 4 páginas: la primera está 80% en blanco, la segunda es bastante agradable, la tercera contiene solo el ejemplo de código CSS como una franja fina en el lado izquierdo, y la última página vuelve a ser en su mayoría espacio en blanco...

    También intenté algo como esto, pero solo para formatear mi currículum [1], ya que muchos empleadores requieren que se envíe como PDF

    [1]: https://www.trist.am/resume/

  5. lopsotronic

    Ve a hablar con los proveedores de navegadores y haz que incorporen las especificaciones CSS L3 PMM [1], que han estado en borrador durante... veamos aquí... oh, vaya, dos décadas.

    Te garantizo que en el instante —el milisegundo— en que CSS PMM entre en el navegador, ese es el segundo en que el ecosistema PDF se desvanece [2].

    Aparte de todo eso, volviendo al punto central, es bastante tarde para restringir HTML a una UX basada en páginas. Ha pasado al menos una década desde que el "navegador" se ha convertido en una especie de sandbox bastante mediocre para lo que solíamos llamar computación cliente-servidor y una especie de desarrollo de software justo a tiempo. Pero lo que pasa con el software, escribir software, es que es diametralmente opuesto al lenguaje, al lenguaje natural, como el que usas en los documentos. Por eso llamamos a uno lenguaje "formal" frente a lo que llamamos lenguaje "natural". La interfaz de estos dos, intentar hacer que sean lo mismo, es una cornucopia siempre abundante de sufrimiento.

    Ves esto en construcciones de marcado complejas, como condicionales y transclusiones [3], que cruzan espadas con el lenguaje natural, es decir, los documentos. Esto es una gran parte de por qué cada editor XML WYSIWYG "igual que el papel" que se ha hecho apesta tan horriblemente. No es que los desarrolladores sean todos idiotas —conozco a muchos, y son algunos de los desarrolladores más inteligentes/astutos que he conocido—, es que están asumiendo una tarea que es conceptualmente inviable.

    [1] Paged Media Module

    [2] Bueno, en todas partes fuera de la producción de impresión de alta gama, impresiones brillantes, white papers ejecutivos. Pero incluso allí, yo […]

  6. jillesvangurp

    Depurar problemas de CSS relacionados con la impresión puede ser un poco pesado. Añadir opciones de impresión para contenido dinámico en una página full stack no es técnicamente tan difícil. Pero conseguir que se vea bien puede ser un poco quisquilloso. Si no te importa cómo se ven las cosas una vez impresas, es fácil. Pero si te importa, en realidad necesita un poco de consideración.

    He hecho algunas cosas personalizadas con una aplicación que genera etiquetas para una impresora de etiquetas usando solo CSS y JavaScript. Esto no es tan difícil. Pero implica lidiar con muchas rarezas relacionadas con los diálogos de impresión nativos, frente a los diálogos de impresión específicos del navegador (y sus vistas previas de impresión), la interacción de características con la configuración nativa de la impresora y sus opciones de escalado, los navegadores que añaden pies de página al documento impreso, y rarezas generales relacionadas con problemas de diseño, tamaños de página, márgenes, etc.

    Mi sensación general al lidiar con esto es que el CSS para impresión recibe mucha menos atención por parte de los desarrolladores de navegadores que el CSS normal.

    Uno de los trucos que puedes hacer es generar un árbol DOM solo para impresión. Reemplaza la raíz de tu árbol DOM con eso, activa la impresión y luego vuelve a poner el árbol DOM antiguo (con tu aplicación full stack y todo lo demás). Parece muy hacky tener que hacerlo así. Pero más o menos funciona y es bastante simple de hacer. Y el beneficio es que saca de la ecuación al resto de tu aplicación (que probablemente no tiene en cuenta la impresión en absoluto) y evitará que interfiera con tu diseño de impresión. Conceptualmente, te hace q […]

  7. bigblind

    Si soy totalmente honesto, esto me parece algo que estaría bastante bajo en mi lista de prioridades. Preferiría mucho más centrarme en la UX en pantalla y la accesibilidad si tengo tiempo limitado. Creo que hacer que las cosas sean imprimibles tiene sentido en ciertos contextos, y creo que en realidad podría reemplazar muchos de los sitios de generación de PDF que se hacen para cosas como entradas, facturas, etc.

  8. pmlnr

    Oh, vaya, eso es un print.css muy ingenuo.

    Faltan cosas como redimensionar medios para que no ocupen todo, bloquear que ciertos elementos se dividan, y demás, ajustar cuando sea necesario, imprimir enlaces (sic), etc.

    Esto último es por lo que moví los enlaces a notas al pie en lugar de enlaces en línea, también para evitar romper el flujo de lectura.

    Además: añadir contadores de página es prácticamente imposible.

    De todos modos, creo que es una buena idea, pero principalmente por razones de archivo: si realmente quieres una copia de archivo, tendrás que imprimirlo.

Más de este día

2026-10-26