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…

Un píxel ya no es lo que era

Una de las cosas complicadas de colocar cosas en una pantalla es que hace tiempo que dejamos de saber a priori qué tamaño físico tiene esa pantalla, ni la ratio (¿4:3, 16:9, 16:10, 2.35:1?) ni cuántos píxeles tenemos a mano (ni, por tanto, la densidad de esos píxeles en pantalla, que hoy en día puede ir de algo más de 100 para una pantalla de ordenador a más de 200 en algunos dispositivos móviles).

Parece ser que el hecho de que esto sea así desde hace tiempo no ha evitado que cobre especial atención ahora por el rumor de que la próxima iteración de hardware del iPhone se va a ir a unos muy espectaculares 960×480 píxeles, lo que ha hecho que, naturalmente, se inquieten los desarrolladores, tanto web como de aplicaciones nativas, que obviamente no quieren que sus aplicaciones se encojan hasta niveles ridículos en una pantalla muy grande. Es fácil suponer que Apple no va a meter la pata con una cosa así, pero me ha llevado a QuirksBlog, que le dedica una entrada al tema, A pixel is not a pixel is not a pixel que habla, a su vez, de la solución que tiene Android para el tema (la diversidad de pantallas de los dispositivos Android provoca vértigo y, en más ocasiones de las deseables, nauseas…). Copio-y-traduzco de la página de soporte para múltiples pantallas:

Density-independent pixel (dip)

Una unidad de píxel virtual que pueden utilizar las aplicaciones para definir su IU para expresar dimensiones de ‘layout’ o posicionado independientemente de la densidad.

El píxel independiente de densidad es equivalente a un píxel físico en una pantalla de 160 ppp, la densidad base asumida por la plataforma […]. Se recomienda fuertemente usar unidades dip para definir la IU de la aplicación, como forma de asegurar una buena presentación de la IU en diferentes pantallas.

Cosas veredes, Sancho…

El Opera Web Standards Curriculum, en español y catalán

Como sucede de vez en cuando, voy a juntar trabajo y blog en una entrada. Y es que parte de mi trabajo durante los últimos meses ha sido encargar y revisar la traducción, edición web y publicación del Opera Web Standards Curriculum, que desde hace unos días se encuentra disponible tanto en castellano como en catalán:

El Opera Web Standards Curriculum es una gran obra (por su calidad y su tamaño) para introducirse en el mundo del diseño y desarrollo web con estándares. Hace unos nueve meses ya (como un parto, oiga) comenzamos a buscar alternativas para la asignatura de Lenguajes y estándares web del grado de Multimedia de la UOC y el Curriculum, con su licencia Creative Commons, nos pareció una gran forma de dar a nuestros estudiantes un recurso de aprendizaje de calidad notable y, a la vez, contribuir a la comunidad en general con un recurso abierto.

«Sólo» tenemos los primeros 38 artículos y la cosa aún no está completamente acabada (¿qué lo está, en la web?). Para cualquier error que detectéis, tenéis los comentarios de esta entrada, mientras habilitamos un mecanismo mejor (sabemos, de momento, por ejemplo, que la navegación presenta algún problemilla en navegadores ‘webkit’ y que, precisamente con Opera :-S, el CSS para los <code> es más bien enorme…).

En unas semanas espero tener publicado en Mosaic algo un poco más extenso sobre el tema en un par de semanas pero, de momento, sirva esta entrada como anuncio no oficial. Espero que os sea de utilidad :-).

Frameworks CSS y clases semánticas

Habitualmente, habríamos dicho frameworks o clases semánticas: los frameworks CSS, inevitablemente, nos llevaban a nombres de clase poco semánticos como span-24 si pretendíamos que el div en cuestión ocupase 24 columnas de nuestra parrilla. Pero, como explican en Sitepoint, esto ya no es así. Por un lado, tenemos ‘scripts’ que ‘compilan’ los diseños sobre frameworks CSS a clases semánticas (como ejemplo citan el compress.rb de Blueprint, todo un descubrimiento del que no tenía constancia). Y por el otro, frameworks que no son CSS directamente, sino que funcionan sobre lenguajes de scripting de servidor, como Compass o CSScaffold.

Va a haber que actualizarse…

Grids CSS Blueprint con Boks

Captura de pantalla de la herramienta Boks, descrita en el texto de la entrada
Pues no es tan difícil, usar un framework CSS...

A la hora de maquetar una página usar uno de los muchos frameworks CSS que corren por ahí (más info en anieto2k, por ejemplo) puede ser una buena forma de ahorrar tiempo y esfuerzo. El problema, para los que no somos nada visuales, es la ausencia de herramientas intuitivas que te permitan maquetar de manera más o menos gráfica… o eso pensaba yo, hasta que he descubierto Boks, un ‘editor visual de parrilas’ (o ‘grids’, que queda más ‘cool’) que se basa en el framework Blueprint, uno de los más populares, por lo que parece.

Os dejo con un screencast introductorio (hay más):

[vimeo]http://www.vimeo.com/3944726[/vimeo]