CSS para impresión: saltos de página y control de viudas y huérfanos

(De vez en cuando uno se encuentra con algo que apenas conoce, se pone a profundizar y no encuentra un recurso en dos segundos en Google que resuma de manera efectiva y eficiente lo que hay que saber sobre el tema. Seguramente porque no he buscado bien, pero ese ha sido el caso después de leer 6 Things I Learned About Print Stylesheets From HTML5 Boilerplate. Por tanto, dejo mi resumen aquí.)


Uno de los puntos en los que casi nunca pensamos cuando hacemos el CSS de una página es el de los estilos para impresión. Es posible que en un futuro cercano, de dispositivos móviles ubicuos y acceso a internet bueno-bonito-y-barato (podemos soñar, ¿no? :-P) dejemos de imprimir páginas web, pero hasta que eso llegue de-verdad-de-la-buena, pasa con frecuencia que imprimimos páginas web con resultados que dejan bastante que desear. No hablaré ahora de @media, sino de cinco propiedades CSS (CSS2, además, especificadas aquí) que, me da la impresión, son unas grades desconocidas y nos permiten mejorar algunas cosas sin mucho esfuerzo.

Las tres primeras de dichas propiedades son page-break-before, page-break-after y page-break-inside que, como su propio nombre indica, impiden saltos de página antes, después o dentro del elemento HTML que especifiquemos, respectivamente. Así, por ejemplo, podríamos usar h2 { page-break-after: avoid; } para evitar que un título de segundo nivel fuese lo último impreso en una página, cosa que lo separaría del párrafo que siempre viene a continuación en nuestro diseño, si fuera el caso. O, en caso que usemos títulos de tercer nivel muy largos, también nos podría interesar h3 { page-break-inside: avoid; }. Los valores permitidos para estas tres propiedades son auto, always (útil para elementos que queremos como final de página), avoid, inherit y left o right, que fuerzan uno o dos saltos de página antes o después del elemento, de forma que la siguiente página sea par (left) o impar (right).

Las otras dos propiedades son orphans y widows que, respectivamente controlan la aparición de huérfanos y viudas en el texto impreso (un huérfano es una línea que se queda sola al inicio de una página, mientras que una viuda es una línea que se queda sola al final). Por ejemplo, p { orphans: 3; widows: 3; } indica al navegador que debe hacer todo lo posible para que un párrafo no tenga menos de tres líneas ‘colgadas’ al inicio o final de una página.

¿Y el soporte de los navegadores? Uno esperaría que algo que es parte de CSS2 ya sería universal desde hace eones. Casi. Según la wikipedia, quedan los siguientes problemas:

  • Firefox y los navegadores Webkit (esto es Chrome y Safari), para page-break-before y page-break-after, sólo soportan los valores always y auto. No servirán de nada, por tanto, avoid, inherit y left o right. A ver si algún día implementan, al menos, avoid. Sirva como acicate el recordatorio de que que Internet Explorer lo tiene desde la 4.0 (allá por el jurásico superior) y que Opera lo tiene también desde hace unos cuantos eones.
  • Firefox, además, no implementa ni page-break-inside ni widows ni orphans :-(.

Aún a pesar de la falta de soporte de algunos de los navegadores más populares, no deja de ser un detalle tener en cuenta el CSS para paginación para los usuarios que disfrutan de navegadores más conscientes de la importancia de la impresión, especialmente en sitios en que anticipamos que los usuarios se van a llevar el contenido con ellos en papel.


Yapordiós. Es publicar la entrada y aparecer How To Set Up A Print Style Sheet

Los tuitlinks de la semana (21)

Los de mirar atrás

sensacional reportaje de 1979 sobre informática en RTVE. back to the futurehttp://j.mp/vUCvBA

10 años de historia de @mosaicUOC en una foto. faltan @albaladejo, @roserrr, @_rser, @davidguerrero y algunos más, pero… http://j.mp/w0Du8x

a punto de perderse otro trocito de la historia de Yahoo :-( http://j.mp/tIpe3n

Los de desarrollo web

#wtf Mozilla Adds Flash to Firefox for Android http://j.mp/vMzfeZ

RT @scottmcmillan A new direction for web applications http://bit.ly/o73Irx

#imprescindible HTML5Weekly http://j.mp/u03TM9

The differences between IE9 on the desktop and IE9 on WP7 http://j.mp/vlwwyP

Andy Baio: Think You Can Hide, Anonymous Blogger? Two Words: Google Analytics http://j.mp/vWgNLn

encomiable propósito. veremos qué da de sí: W3C Announces First Draft of Standard for Online Privacy http://j.mp/rsVa4E

Y el visual para cerrar

por si alguien no ha visto aún el timelapse en paralelo del Exploratorium de San Francisco. imperdible

[youtube]http://www.youtube.com/watch?v=PNln_me-XjI[/youtube]

Multimedia 1987

El jueves celebrábamos 10 años de Mosaic, la revista del grado de Multimedia de la UOC y aparecía, por alguna de las diapositivas, el ordenador que, en mi modesta opinión, más hizo por poner en marcha esto del multimedia, el Amiga. Y hoy me encuentro con esta maravilla de vídeo promocional de 1987. EStoy intentando contener la lagrimita…

[vimeo]http://vimeo.com/28228891[/vimeo]

Qué recuerdos, y qué avanzado a su época (un par de años luz por delante de los Macs de la época, directamente, en multimedia).

Porcentajes para periodistas (y otros animales)

Atención al titular de ayer en La Información:

Titular: ¿Quieres gastar un 130% menos en la cesta navideña? Compra ahora y congela
La imagen enlaza a la noticia, ahora mismo no corregida

El tema de los porcentajes no es nuevo en esta casa. Pero me sigue resultando alarmante que algo que no es trivial pero que para nada es complicado siga siendo motivo de errores garrafales :-S.

En resumen: si gastas un 100% menos, es que es gratis. Gastar un 130% menos implicaría que el tendero te está pagando por llevarte la comida. Las navidades son tiempo de paz y amor, pero me parece que no vamos a llegar a tanto…

Una chuleta para periodistas:

  • Doblar el precio es un aumento del 100%. El opuesto es un descuento del 50%.
  • Triplicar el precio es un aumento del 200%. El opuesto es un descuento del 66.66…%.
  • Cuadruplicar es un aumento del 300%. El opuesto es un descuento del 75%.

De aqui se deduce, sin ‘hacer números’ que lo contrario de un aumento del 130% (que diría que es lo que quería hacer el periodista) tiene que significar un ahorro de entre el 50 y el 66.66%. Un número menos espectacular que el 130% del titular, pero al menos correcto… y posible.

Y, en general, para deshacer un incremento cualquiera (pongamos por caso, del 130%) lo que hay que hacer es:

  1. Cogemos el aumento en porcentaje y dividimos por 100 (de 130 a 1,3).
  2. Sumamos uno (de 1,3 a 2,3).
  3. Invertimos ese número (es decir, hacemos 1/2,3, que da, aproximadamente, 0,43).
  4. Le restamos 1 a ese número y nos comemos el signo (1-0,43 son -0,57, y de ahí a 0,57).
  5. Multiplicamos por 100 y le añadimos el signo de porcentaje (57%).
  6. ¡Tachán!
  7. Si se desea, podemos hacer esta pequeña comprobación: si a algo que vale 100 euros le aplicamos un descuento del 57%, se queda en 43. Si a estos 43 le aplicamos un aumento del 130% (esto es, multiplicamos por 2,3), nos quedamos en 98 euros con 90 céntimos (el error viene del redondeo).

Como decía antes, no es trivial. Pero es la diferencia entre decir algo cierto y decir algo que, además de erróneo, es imposible. Y no debería costar mucho tener un Google Doc que lo hiciese (como este, que se puede descargar como hoja de cálculo Excel y OpenOffice.org ;-) ).

La carrera de Adobe por seguir siendo relevante en un mundo HTML…

…queda bastante bien ilustrada en el siguiente vídeo:

[youtube]http://www.youtube.com/watch?v=bzOjbGx5kwc[/youtube]

Después del anuncio de la renuncia de Adobe a continuar con el plugin Flash para los navegadores móviles, la carrera (ya en marcha: habíamos tocado el tema hace poco más de un año) por desarrollar las herramientas equivalentes a Flash para un mundo HTML se vuelve cada vez más importante.

Si bien opino que Adobe aún cuenta con bastante ventaja sobre la competencia (por ‘know how’ y, sobre todo, por presencia en el mercado), resulta un poco decepcionante comprobar que su estrategia apenas ha cambiado en doce meses. Siguen teniendo dos caballos en la carrera de las películas (por seguir usando terminología Flash) hechas con divs, CSS y jQuery (o bibliotecas JavaScript similares): un exportador para Flash (que genera HTML, CSS y JavaScript, que no HTML5; dudo bastante que hayan cambiado mucho en seis meses) y Edge, aún en beta, pero que, básicamente, parece competencia para Adobe fabricada por Adobe… Y, mientras tanto, ningún caballo en la carrera que a mí, al menos, me parece verdaderamente interesante: desarrollar algo que sea verdaderamente HTML5 (esto es, muy probablemente, tirando de canvas) y que nos ahorre los problemas de Flash, más que hacerlos perdurar en un entorno diferente… Pero, si la cosa sigue igual, comienzo a temer que Adobe pueda permitirse el lujo de patinar y aún así conservar la corona por incomparecencia de aspirantes al título. Esperemos que no sea así.