Ahora que empiezo con este blog tengo que ponerlo a punto, dejarlo tal y como realmente me gustaría que estuviera, partiendo del aspecto visual que tiene ahora mismo por defecto (la versión de WordPress que tengo instalada trae por defecto el template “WordPress Default 1.6″). El header con tal imagen, el footer en tal color, los posts con tal borde…
Resulta que el código es de lo menos legible y usable que me he encontrado por ahí, y para explicar por qué, antes explicaré unas nociones muy básicas de CSS
Peleas con el CSS
Es lo que se llama el estilo, diseño o maquetación del blog. En los blogs, este estilo se suele definir con un
template o plantilla común para todas las páginas, gracias al lenguaje de programación estándar CSS, que permite definir el aspecto visual (entre otras cosas) de los elementos que componen una página web. Obviamente, y como ocurre con todo lenguaje de programación, cada programador lo escribe de una manera. Es la ventaja y la desventaja de un lenguaje que ofrece el mismo resultado cuando lo escribes de distinta manera. Explicaré esto con dos ejemplos equivalentes:
/* Tamaños */
div .caja1, div .caja2{
width: 50em;
}
div .caja3{
width: 30em;
}table{
width: 80%;
}
/* Fondos */
div .caja1{
background-color: #32CD32;
}
div .caja3{
background-image: url(’http://farm1.static.flickr.com/195/462569506_f904acd3dc_m.jpg’);
}
/* Márgenes y paddings */
div .caja3{
padding: 1em;
}
table{
margin: 0 2em;
}
En el ejemplo anterior se puede ver cómo definimos el tamaño, fondo y márgenes y padding de los elementos div que tienen las clases caja1, caja2 y caja3 respectivamente y del elemento table. Por un lado definimos el ancho de cada división (en este caso, caja1 y caja2 tienen el mismo ancho) y de la tabla; por otro definimos el aspecto que tendrá el fondo de estos elementos, y por otro lado, los márgenes y paddings.
/* Método 2 */
/* Divs */
div .caja1{
width: 50em;
background-color: #32CD32;
}div .caja2{
width: 50em;
}div .caja3{
width: 30em;
background-image: url(’http://farm1.static.flickr.com/195/462569506_f904acd3dc_m.jpg’);
padding: 1em;
}
/* Tablas */
table{
width: 80%;
margin: 0 2em;
}
En este otro ejemplo, en vez de agrupar las definiciones por su característica (tamaño, fondo…) lo hacemos por el elemento al que dan formato, por lo que ganamos en muchos aspectos. No tenemos en un sitio el tamaño de un elemento y en otra parte del código (quizá separados por más de 80 líneas de código) el color de sus bordes, sino que tenemos toda la información referente a un mismo elemento en un mismo sitio.
- Ventajas del método 1
- Podemos cambiar, por ejemplo, el color los bordes de todos los elementos de la página fácilmente
- Ventajas del método 2
- Podemos cambiar completamente la apariencia de cualquier elemento fácilmente
- Aumenta la legibilidad del código: si alguien quiere ver cómo se implementa tal característica de un elemento, sólo tiene que buscar la parte del código en que aparece ese elemento (que solo aparecerá una vez). De la otra manera tendría que navegar entre las siete veces que puede aparecer el elemento, o las cincuenta que puede aparecer el término
background, por ejemplo.
- Reduce el tamaño del archivo .css al no tener que repetir varias veces los nombres de los elementos. Esto es una ventaja menor, pero no deja de ser una ventaja :D
Teniendo en cuenta que lo normal no es querer cambiar solamente todos los márgenes de los elementos de una página (normalmente si queremos cambiar alguna característica de todos los elementos es para hacer un rediseño total de la web, y entonces querremos cambiar casi todas las características de los elementos), la ventaja del método 1 parece que casi nunca nos va a beneficiar, y sin embargo la primera ventaja del método 2 casi multiplica su valor por el doble.
Pues bien, volviendo al asunto principal, el template de WordPress que viene instalado por defecto, implementa el método 1, por lo que yo me encuentro las dos desventajas que comentaba antes, mala legibilidad del código y dificultad para rehacer completamente el diseño y adaptarlo a lo que yo quiero. Y lo peor de todo es que, como ya he dicho, este es un diseño que está pensado para ser mostrado, estudiado y modificado.
Lo principal al programar es resolver el problema que se nos plantea, pero cuando se programa un código que después va a ver (y sobre todo modificar) mucha gente, igual o casi igual de importante es la legibilidad de este.
Nota: la imagen a la que referencio en el código de ejemplo tiene licencia CC by-nc 2.0, y pertenece al usuario de Flickr InertiaCreeps.
