Webmaster Libre

Las nubes de etiquetas son, sin lugar a dudas, una de las señas de identidad de la “web 2.0″. Las empezamos a ver en sitios como del.icio.us pero, entre servicios online que generarán una para tí, plugines para los CMS más populares y la nueva versión de WordPress con etiquetas integradas, pronto todo el mundo podrá disponer de una cómodamente.

Lo normal, a la hora de dar estilo a una nube de etiquetas, es utilizar variaciones en el tamaño de la tipografía y su grosor. Así, por norma general, las categorías más importantes, con más contenido, aparecen en un tamaño y grosor mayor. No obstante, esta aparente estandarización del aspecto de las nubes de etiquetas parece empezar a preocupar a los diseñadores.

Hoy en CSS Tricks he visto un planteamiento novedoso para las nubes de etiquetas: En lugar de jugar con el tamaño de las letras, han decidido jugar con el padding de las cajas. Así, a mayor caja, mayor importancia.

Es una solución interesante pero supone algunos inconvenientes:
En primer lugar se pierde la capacidad de identificar a simple vista y sin esfuerzo las categorías más relevantes.
Además, en el ejemplo se han apoyado en el uso del color lo cual nos hace más sencilla, a todos los que contamos con una visión correcta a nivel de colores, la comprensión de la idea pero ¿sería igual de comprensible visto en blanco y negro?
Y en tercer lugar, procurad emplear bien las pseudoclases para los enlaces, de tal forma que no haga falta tener ratón para apreciar el efecto mouse over (recordad, los selectores deben seguir un orden para que funcionen correctamente: link, visited, hover, active, focus)

El artículo con el código empleado y un ejemplo en funcionamiento lo tenéis, en inglés en: Tag Cloud with padding thickness

Con el furor de los frameworks para todos los lenguajes de programación era previsible que, tarde o temprano, alguien decidiera crear un framework para ensamblar hojas de estilo como churros (con todo mi respeto a los artesanos churreros). En principio suena bien, maquetar una página casi completa con facilidad mecánica empleando unas u otras clases e id predefinidos.

Blueprint, Tripoli, los grids de Yahoo… Todos ellos nos prometen sencillez y productividad, no obstante, el precio que suponen no vale el trato.

En primer lugar, cargar nuestros sitios con todo el código extra que contiene un framework completo (por muy modular que sea) es contraproducente. Pararnos a buscar por la hoja justo el trozo que vamos a usar es casi tanto trabajo o más que escribir los estilos nosotros mismos y, por muy comprimido que esté, es peso extra para nuestros sitios (con la consiguiente incomodidad para nuestros usuarios, costes extras en ancho de banda etc.).

Para empezar a ser realmente productivo con un framework es necesario aprender a utilizarlo, si ya sabemos escribir hojas de estilo será tiempo perdido en un conocimiento limitado.
Por supuesto, si no sabemos puede parecer muy buena idea empezar con gran parte del camino andado y dedicarnos sólo a lo bonito que queremos que sea el diseño y poco más. Por contra, tratar de eludir el aprendizaje puede suponernos serios quebraderos de cabeza.

Imagina que desaparece el framework, que no está demasiado bien documentado o que no tiene una comunidad fuerte alrededor. Todo tu esfuerzo para aprender a manejarlo habrá sido para nada y, tarde o temprano, tendras que afrontar el auténtico aprendizaje. Además, en caso de lenguajes complicados o con procesos de desarrollo largos y tediosos, es justificable el uso de frameworks e incluso recomendable. Escribir hojas de estilo es sencillo, comparado con los lenguajes de programación propiamente dichos es un juego de niños y, con un poco de práctica, escribiras tus estilos tan deprisa o más que apoyándote en frameworks.

Además, es imposible preveer todas las necesidades de maquetación y estilos que tendrá cada sitio. Si buscamos dotar a la web de un significado semántico tendremos que aprender a etiquetar las cosas correctamente y a emplear los elementos html de forma correcta. A apoyar nuestros estilos en ellos y no manchar todo el código con clases e id de nombre criptico y ningún significado (si aún no la habéis leído os recomiendo la traducción que hice del artículo: Div Mania).

No obstante, la idea que se trasluce de estos frameworks no es inútil en si misma. Disponer de un set de herramientas con el que aligerar ciertos trabajos rutinarios.
Me gusta entender al desarrollo web como una especie de artesanía de nueva generación. Los orfebres, artesanos de la plata, dentro de su proceso de aprendizaje y como conocimiento útil para el resto de su vida, aprenden y crean su juego de buriles. De esta manera, disponen de un set de herramientas tan completo y extensible como quieran. Sea cual sea la necesidad, buril más ancho, más estrecho, más o menos afilado, son capaces de crear uno y empezar a trabajar en seguida.
Por eso, lo que si me parece una idea genial, tanto para aprender como para aligerar trabajo es crearse una caja de herramientas con todos esos elementos que tú empleas tan a menudo. Sólo tu sabes tus manías, sólo tu conoces a fondo tu manera de escribir estilos. Al ser tu propio trabajo te resultará sencillo encontrar y emplear justo esa pieza de código que necesitas. Incluso, en lugar de crear archivos css enormes o decenas de ellos chiquititos, puede interesarte crear un wiki o algo por el estilo donde realizar consultas rápidas (puedes emplear alguna solución tipo TiddlyWiki que no necesita servidor web ni base de datos y es muy sencilla de utilizar).

Vosotros ¿qué opináis? ¿utilizáis frameworks para css? ¿tenéis un set de herramientas básico o empezáis de cero siempre?