Volver un grid responsive y algo más semántico y cómodo con un poco de LESS

(Si con esta entrada no me llevo el premio al título más aburrido, ya no sé cómo hacerlo…)

Lo confieso: hasta hace un par de semanas el responsive y yo nos conocíamos, pero no teníamos la confianza deseable y los preprocesadores de CSS eran un concepto interesante pero a explorar. Afortunadamente, hace poco me ha surgido la oportunidad de hacer una web (muy en estado de work in progress, ahora mismo) que ha supuesto el momento perfecto para, si no aprender, al menos darme un chapuzón en el tema…

En las pocas ocasiones en que me ha tocado hacer una web, y no limitarme a parchear un tema de WordPress (de la última vez ya hace un año y medio) mi modus operandi habitual ha sido comenzar a base de un grid (para puristas, rejilla o cuadrícula, desde luego) generado con una herramienta bastante abandonada pero funcional, Boks. Una de las cosas que me atrae de la herramienta (a parte de la simplicidad de uso) es que cuenta con una herramienta en la que uno especifica qué ancho de página quiere en píxels, y cuántas columnas para la rejilla, y te ofrece todas las posibles alternativas:

Captura de pantalla de la herramienta boks
En el fondo, no es más que resolver una ecuación diofántica, pero uno es comodón…

Si sólo quieres hacer un diseño sencillo (y ya lo tienes en mente), en cinco minutos acabas con una estructura como esta:

Ejemplo de una cuadrícula generada con Boks
No va a ganar un premio de diseño, pero he visto cosas peores…

Boks te genera en un santiamén el HTML y el CSS (a partir del framework Blueprint) y a partir de ahí te pones a aplicarle un poco de diseño a las órdenes de alguien que sepa más del tema que tú.

Naturalmente, la cosa tiene limitaciones más que evidentes:

  • Por un lado, Blueprint te lo deja todo definido en píxels, con lo que el responsive queda muy lejos.
  • Por otro, y diría que como con casi todos los frameworks, el aspecto no se aplica exclusivamente desde el CSS: también necesitamos una ensalada de clases presentacionales en nuestro HTML: así, para la captura que tenéis ahí arriba, la cabecera se lleva un span-12 last, las caja grande un clear span-8, la de la derecha un span-4 last y las cajas pequeñas un span-4 que acompañamos de clear y last dependiendo de su posición… (La “sintaxis” de Blueprint, por cierto, se vuelve bastante intuitiva bastante deprisa, por cierto. No sé si otros frameworks son tan “naturales”, pero es algo a tener muy en cuenta a la hora de seleccionar uno).

Dicen los proponentes del object oriented CSS que unas cuantas clases presentacionales no nos van a matar y que permitirán reutilizar código y ser más eficientes. Pero estaremos todos de acuerdo que para lo que tenemos ahí arriba no nos hace falta y, además, que por debajo de una cierta resolución vamos a querer que los ítems de la barra de la derecha sean más bien span-6 y que los ítems a los que querremos aplicar clears y lasts no van a ser siempre los mismos…

Con todo ello en mente, unos abre el CSS y comienza a hacer cambios. El más evidente, desde luego, es cambiar el width: 960px; del contenedor por un max-width: 960px; y añadir el dichoso meta name="viewport" content="width=device-width, height=device-height" para que smartphones y demás dispositivos presuntamente inteligentes se den aludidos.

Pero luego viene el arduo trabajo de explorar el CSS a la caza de anchos en píxels y pasarlos a porcentajes… Con un poco de calculadora y mucha paciencia acabaremos convirtiendo cosas como

.span-1  {width: 69px;}
.span-2  {width: 150px;}
.span-3  {width: 231px;}
.span-4  {width: 312px;}
.span-5  {width: 393px;}
.span-6  {width: 474px;}
...
.span-12  {width: 960px;}

en

.span-1  {width: 7.1875%;}
.span-2  {width: 15.625%;}
.span-3  {width: 24.0625%;}
.span-4  {width: 32.5%;}
.span-5  {width: 40.9375%;}
.span-6  {width: 49.375%;}
...
.span-12  {width: 100%;}

Los que tengáis buena vista habréis notado que he usado columnas de 69 píxels y canales (gutters, si preferís el anglicismo) de 12, que convertimos a porcentajes dividiendo por 960 (el ancho total al que estaba trabajando) y multiplicando por 100: 69 pasa a convertirse en 7.1875%, 12 en 1.25% y… paciencia, que nos tocará arreglar así, además de los span-n, unos cuantos append-, prepend- y demás clases que use nuestro framework.

Pero claro… seguimos teniendo esas clases presentacionales que no nos van a ayudar nada cuando nos pongamos con el responsive… ¿Qué se le ocurre a uno? Pues bien, si tenemos un div (sí, debería haber usado articles y sections… prometo que estoy en ello) con clases div span-4 last itemagenda, ¿no podríamos buscar el CSS que aplican las presentacionales clear y span-4 y aplicarlo desde la muy semántica itemagenda? De hecho, sí podemos, y acabamos con algo como

#itemagenda {
    /* span-4 */
        float: left;
        /* margin-right: 1.25%; */
        width: 32.5%;
    /* last */
        margin-right: 0%;
}

Así resultará más fácil, además, aplicar una media query que, pongamos por caso, coja esos ítems de agenda que ahora viven a la derecha de los destacados en fila de a uno y los ponga, si la resolución baja de 800 píxels, bajo esos mismos destacados, en fila de a dos (aplicando clears y lasts según convenga a base de pseudoclases :nth-of-type).

¿Y no habrá una forma más eficiente?

Porque si a estas alturas estás pensando que esto es picar piedra de muy mala manera… de hecho tienes razón. Para esto se han inventado los preprocesadores de CSS.

Ahora mismo el “mercado” de los preprocesadores lo copan Sass y LESS. Me gustaría poder decir que elegí uno tras un detallado análisis de sus respectivas ventajas y desventajas, pero voy a confesar que opté por LESS porque encontré muy fácilmente la manera de usarlo con mi editor favorito del momento, el gratuito Komodo Edit. En cualquier caso, queda aclarar que Sass resuelve tan bien como LESS (tengo entendido :-)) los problemas que detallo a continuación:

No copies y pegues tú

#itemagenda {
    /* span-4 */
        float: left;
        /* margin-right: 1.25%; */
        width: 32.5%;
    /* last */
        margin-right: 0%;
}

…no es terrible, pero seguro que te gusta más…

#itemagenda {
    .span-4
    .last
}

¿Verdad? El preprocesador de turno ya se encargará de ir a buscar qué hay definido en span-4 y last y hacer con ello lo que convenga (ahora mismo LESS añadirá tanto el margin-right: 1.25%; como el margin-right: 0%; y te tocará a ti limpiarlo más tarde (o no), cosa que no resulta especialmente elegante, pero me han pasado cosas más graves).

Todas esas divisiones

Sé que estoy usando columnas de 7.1875% y canales de 1.25%. Sé que un span-4 son cuatro columnas y tres canales… ¿por qué debería hacer yo todas las divisiones? ¿No se supone que para esto están los ordenadores? Efectivamente. Con LESS (y con Sass también) podemos definir un par de variables

@column-width: 7.1875%;
@gutter-width: 1.25%;

(por si en algún momento queremos cambiar las dimensiones de la cuadrícula), después definir

.span( @columns )  {
    width: (@columns * @column-width) + ((@columns - 1) * @gutter-width)}
}

y finalmente usar

#itemagenda {
    .span(4)
    .last
}

para conseguir exactamente el mismo resultado que antes, pero con mucho menos dolor e inútil picado de teclas… :-)


Y hasta aquí mis primeros pinitos con las cuadrículas responsive y los preprocesadores. Seguro que hay muchas cosas que podría hacer mucho mejor, y para eso están los comentarios :-). Me gustaría decir, eso sí, que me he inclinado por tomar Blueprint como fuente porque ya me lo conocía, pero también que no he elegido ninguno de los frameworks responsive que corren por ahí porque los que he visto tienden a definirte unos breakpoints dados y a decidir por ti qué hacen con la cuadrícula a medida que cae la resolución, cosa que no me gusta nada. Si alguien sabe de algún framework (tiene que haberlos, sencillamente es que no he buscado mucho) responsive que no imponga tales limitaciones, que avise :-).

El -webkit-problema

El que confíe, espere y desee que algún día desarrollar para la web sea una tarea fácil porque sólo hay que comprobar las cosas en un pequeño número de circunstancias debería tener en cuenta que eso ya pasó una vez: cuando Internet Explorer 6 dominaba la Tierra. Que nadie se llame a engaño: cuando Explorer 6 salió al mercado (un 27 de agosto de 2001, no ha llovido…) fue lo mejor que le podía pasar a la web en aquel momento y, cuando un par de años más tarde alcanzó una cuota de mercado del 90%, diseñadores y desarrolladores web pudieron, por primera vez, vivir tranquilos con un navegador decente (para la época). Hoy sabemos que el monocultivo IE6, de hecho, ahorró bastante trabajo a corto plazo… y tuvo tantos efectos perniciosos para la web que hoy en día renegamos de él como si nunca debiese haber pasado (con bastante razón, además).

Un panorama muy Webkit

La situación actual, a primera vista, no tiene muchos puntos en común con la de principios de siglo, pero determinadas prácticas —y, sobre todo, el advenimiento imparable de la web móvil y el cambio de panorama que supone— nos están poniendo en una situación de riesgo que gira alrededor de Webkit, el motor que mueve a Chrome y Safari, principalmente, en el escritorio, pero sobre todo a los navegadores por defecto de iOS y Android. Por poner unos números (y dibujitos) al asunto, en enero de 2011, en este modesto blog estábamos así (disculpas por el uso de tartas, se aceptan sugerencias de mejora):

Cuota de navegadores en obm. Enero de 2011. IE: 42.4, Firefox: 30.1, Webkit: 25.3

Un reparto no óptimo (sobre todo porque la cantidad de IE6 era no negligible), pero diverso. Pero si miramos el mismo reparto en los últimos 31 días, el vuelco ha sido más que notable:

Cuota de navegadores en obm. Enero de 2011. IE: 42.4, Firefox: 30.1, Webkit: 25.3

Esa brutal subida de los navegadores Webkit tiene dos vectores principales: Chrome, por sus avances tecnológicos y la pasta en publicidad que se deja Google, por un lado, y los navegadores móviles, por el otro, como ya comentábamos.

No, no estamos como en 2001 o 2002: de momento la cosa es muchísimo más diversa y, además, no podemos acusar a Google ni a Apple (ni a Adobe, que también invierte lo suyo en el desarrollo de Webkit) de las prácticas monopolísticas que usó Microsoft en su momento. En ocasiones Google juega de manera discutible, al menos en mi opinión, pero es innegable que Webkit avanza más deprisa que Firefox y Opera (Microsoft es capítulo aparte) en bastantes aspectos relevantes (no todos, pero esa es otra historia). Si a eso le sumamos el músculo económico para el marketing del que disponen y la inteligencia que demuestran en usarlo, el resultado no es precisamente de extrañar.

Y luego queda, claro, el tema de la web móvil (y para otros dispositivos, como las teles “conectadas”, que cada día abundan más). Ahí el iPhone, el iPod, el iPad y todo el ecosistema Android han hecho maravillas por Webkit. Su dominio no es absoluto (de hecho, Statcounter afirma que Opera sigue siendo el navegador móvil más usado globalmente) pero sí lo es en mindshare: si alguien encarga una web y llega a preguntar por la posibilidad de consultarla desde el móvil lo más probable es que en su bolsillo haya un iPhone o, en su defecto, un móvil Android; en ambos casos, el navegador que usará para sus pruebas será Webkit.

-propiedades-avanzadas-css

Volvamos a los navegadores y su evolución. Ya hemos comentado en alguna ocasión por aquí (y no deja de ser una obviedad) que los comités son lentos. Los grupos de trabajo del W3C son incapaces de seguir el ritmo que marcan los navegadores (de hecho, tampoco es su cometido correr detrás de estos cual galgo tras liebre), especialmente en lo que respecta a los avances en la creación e implementación de nuevas propiedades CSS (ejemplos paradigmáticos: border-radius o gradient). Una vez constatado este punto, se hizo necesario establecer un mecanismo para que los diferentes motores puedan implementar nuevas características sin que todos muramos en el intento… y se llegá la [aparentemente inofensiva] idea de los prefijos de fabricante: si Webkit decide implementar border-radius experimentalmente, lo hace prefijando un -webkit-. Mozilla usa -moz-, Opera -o- y Microsoft -ms-. La idea es que, en algún momento, border-radius pasará a ser una propiedad estandarizada CSS y nos podremos olvidar de los dichosos prefijos (pensad que implementar cuatro propiedades con prefijo más la oficial es más bien incómodo…).

border-radius es un ejemplo en el que todo el mundo se pone de acuerdo más o menos rápida y eficientemente (y un caso en el que, de hecho, nos podríamos haber saltado el proceso de los prefijos). gradient es un ejemplo de lo que pasa cuando cada fabricante tiene sus propias ideas sobre cómo debería funcionar algo: si os pasáis por el Ultimate CSS Gradient Generator podréis comprobar que Microsoft usaba una sintaxis atroz para conseguirlo desde los tiempos de IE6, los Webkits usaban otra sintaxis no tan fea pero que tampoco era ninguna virguería, que Mozilla comenzó a usar una sintaxis algo más razonable con Firefox 3.6 y que, después, esta sintaxis la fueron adoptando sucesivamente Opera, Webkit a partir de una cierta versión (desde Chrome 10 y Safari 5.1), Microsoft con IE10 (el día que salga) y que ahora hasta al W3C le parece bien la sintaxis, con lo que deberíamos poder utilizarla, en los navegadores modernos, sin semejante pesadilla de prefijos…

border-radius, pues, demuestra la necesidad de este mecanismo para introducir, poco a poco, propiedades experimentales

¿Y el problema?

[Un buen trozo de lo que sigue sale, en gran parte, de Vendor Prefixes – about to go south, de Remy Sharp.]

El problema es múltiple. Resulta ser que, naturalmente, siempre hay un navegador que hace las cosas antes que los demás. Y que, además, ese navegador tiene la manía de ser Webkit y, por tanto, acostumbra a llegar al usuario con las marcas Safari y/o Chrome. Y que Firefox y Opera suelen llevar un retraso notable (a ver quién es el guapo que le aguanta el ritmo a Google + Apple + Adobe…). Y que Internet Explorer suele llegar a la fiesta cuando se ha largado hasta el personal de limpieza (estos no tienen la excusa de la falta de recursos, pero también lidian con sus problemas: si fuera por el equipo de desarrollo de IE la cosa sería diferente, pero los ciclos de Microsoft y las necesidades del soporte corporativo son un tema en el que mejor no entrar, si no es estrictamente necesario)…

En algún momento, además, las propiedades experimentales (con prefijo) deberían o bien dejar de existir porque se demuestran poco útiles o bien dejar de existir porque han pasado a ser de uso general y, por tanto, a implementarse sin prefijo. Esto es, que sí o sí, las propiedades experimentales deberían venir con fecha de caducidad, por un motivo u otro.

¿Qué pasa? Los diseñadores, natural y comprensiblemente, implementan las nuevas características que trae Webkit para mejorar sus diseños, tan pronto como les resultan útiles. No importa si uno es de la escuela hard boiled, si predica el progressive enhancement o si es fiel a la doctrina de la graceful degradation, se trata de una práctica extendida y aceptable y respetable… siempre que uno sea consciente de que se trata de propiedades experimentales. ¿Qué significa esto? Que mientras sólo Webkit tira de la propiedad, usamos -webkit-propiedad. Y al cabo de un tiempo, cuando Mozilla y Opera la implementan, añadimos las correspondientes -moz-propiedad y -o-propiedad. Si, por algún milagro, Microsoft finalmente hace lo propio antes de que llegue el W3C, añadimos la -ms-propiedad. Y cuando llega, parsimonioso como debe, el W3C, añadimos la propiedad… y con un poco de suerte, hasta vamos eliminando las propiedades con prefijo a medida que los navegadores anticuados van desapareciendo del mercado.

¿Da miedo el procedimiento del párrafo anterior? Si no miedo, como mínimo una inmensa pereza, ¿no? Si no disponemos de alguna manera automatizada de hacerlo (posibles herramientas son Prefixr o -prefix-free), y tenemos unos cuantos diseños que mantener, el trabajo es digno de Job (siempre he sospechado que Job, de hecho, era front end de profesión). El resultado es que todo el mundo (todos los buenos diseñadores, al menos) corre a implementar las -webkit-. Pero que con cada paso posterior se pierden muchos, muchísimos trabajos. Y no sólo trabajos de demostración, sino sitios en producción, que deberían dar la mejor experiencia posible a todos los usuarios, independientemente del navegador que estén usando en ese momento…

¿Es tan grave la cosa?

Depende del punto de vista, desde luego. Si eres desarrollador en Mozilla y Opera y te acabas de pasar una noche sin dormir para colar en la última release la propiedad CSS de moda, y luego resulta que la mayoría de diseños que la usan en en Webkit pasa de tu cara, tiene que doler mucho.

Pero hasta a los desarrolladores de Webkit les tiene que doler tener que mantener sus -webkit-propiedades en el código: si las quitan, sus navegadores “romperán” muchos sitios que ahora usan toda la potencia de CSS, pero al mantenerlas pierden un milisegundo por aquí, otro por allá… Poco, quizás, pero con la lucha por la velocidad entre navegadores (y la creciente complejidad de los diseños de las páginas), hasta la última centésima cuenta…

Y si eres un diseñador, el dolor de cabeza de seguir la carrera metro a metro y decidir en cada punto cuál es la menos mala de las soluciones tampoco acaba de ser el más deseable de los futuros…

La cosa ha llegado, en los últimos días, a que los no-webkit se planteen (públicamente, en las discusiones del correspondiente grupo de trabajo del W3C) dar soporte a las -webkit-propiedades en su código. Si somos benevolentes, un parche horroroso. Siendo muy estrictos, una vulneración durísima de todo el proceso de estandarización. En cualquier caso, un efecto no previsto y muy poco deseable del proceso de innovación de los navegadores… :-(

Esperemos que el curso de la cosa comience a corregirse. De otra forma, los resultados previsibles (soporte incompleto a navegadores que cumplen los estándares, código spaguetti por todos lados, ineficiencias a mansalva) van a complicar la vida de desarrolladores y usuarios. Poco a poquísimo, pero la situación se iría haciendo más y más insostenible con el tiempo.

Seguiremos informando.


Lecturas y recursos recomendados y recomendables

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 :-).