Sass. Hojas de estilo, con estilo

En la anterior entrada hablé de Haml, en lenguaje de marcado para plantillas que las hace mas simples, concisas, estilizadas y legibles.

Una pagina web tiene 3 partes. El contenido, la presentación, y el comportamiento.

El contenido seria el HTML. Haml, igual que erb, crea plantillas que el servidor transforma en paginas que son servidas al navegador de quien visite la aplicación web.

El comportamiento es en parte las acciones que se desencadenen en el servidor por las acciones del usuario, el las acciones que se realizan en el navegador mediante javascript.

Nos queda la presentación. El contenido está ahí. Ahora queremos darle forma, estilo, y las buenas prácticas nos obligan a tener la presentación separada del contenido mediante las hojas de estilo, o CSS. Aquí entra SASS, el proyecto hermano de HAML.

Sass es el acrónimo de “Syntactically Awesome StyleSheets”. Hojas de estilo sintácticamente sorprendentes, podría traducirse. Explico como funciona.

Las hojas de estilo tradicionales tienen este aspecto.

#menusuperior{
	height: 150px;
	font-size: 10px;
	font-style: italic;
	font-weight: bold;
}
#menusuperior.submenu{
	font-size: 8px;
	background-color: lightgray;
	height: 100px;
}
#menusuperior.submenu a{ /* Enlaces de los submenus superiores */
	text-decoration: none;
	font-size: 11px;
	color: turquoise;
}
#menusuperior.submenu a:hover{ /* Enlaces de los submenus cuando el cursor los señala */
	font-size: 13px;
}
#menusuperior.title{
	font-size: 20px;
	font-weight: bolder;
}
#menulateral{
	width: 200px;
	float: left;
	font-size: 10px;
	font-style: italic;
	font-weight: bold;
}
#menulateral.submenu{
	font-size: 8px;
	background-color: palegreen;
	height: 20px;
}

Es un fragmento de una hoja de estilo bastante pequeño y simple. Las hojas de estilo son bastante tediosas de escribir, y hay que tener un buen método y estructura para cuando tienen 300 lineas de código saber donde encontrar cada cosa.
Utilizando la misma filosofía DRY (DON’T REPEAT YOURSELF) de ruby on rails y de haml, intentemos simplificarlas.¿Qué elementos se repiten inútilmente?
Primero, los puntos y coma. Fuera con ellos.
Segundo, las llaves. Usando indentación, no las necesitamos.
Tercero. Si a los elementos de clase submenu les aplicamos estilo cuando están dentro del menú superior o del lateral, podemos anidarlos y evitar repetir #menusuperior de cada vez. Y con los enlaces otro tanto.
Cuarto. Las propiedades font-weigth, font-size,font-style, son repetitivas. Anidemos el sufijo.
Quinto. Para afinar la propiedad, nos podemos referir a la clase padre y refinarla, con el símbolo “&”.

Nos quedamos con esto:

#menusuperior
	height: 150px
	font:
		size: 10px
		style: italic
		weight: bold
	.submenu
		font-size: 8px
		background-color: lightgray
		height: 100px
		a
			text-decoration: none
			font-size: 11px
			color: turquoise
			&:hover
				font-size: 13px
	.title
		font:
			size: 20px
			weight: bolder
			style: normal
#menulateral
	width: 200px
	float: left
	font:
		size: 10px
		style: italic
		weight: bold
	.submenu
		font-size: 8px
		background-color: palegreen
		height: 20px

Todo lo aplicado mejora el aspecto visual del código, pero sass pretende dotar al código modularidad. fijémonos que los tamaños de letra. En este ejemplo hay apenas un par de ellos, pero en una hoja de estilos extensa, podemos llegar a poner font-size: 10px en una docena de ocasiones. Si luego decidimos que la letra tamaño mediano, en lugar de 10px debería ser mayor, de 12px, deberemos cambiarlo en cada aparición. Deberíamos poder tener eso compartimentado. Como si declarásemos una variable.
Eso mismo pensaron los creadores de sass. Las variables se declaran y usan con $ antes del nombre. ¡Y lo mejor de todo, sus valores admiten operaciones aritméticas! Es posible hacer algo del estilo 10px + 2px y el resultado será 12px.
Tomando la letra base de n px, la pequeña es (n-2)px y la gigante de (n*2)px. Tal que así.
Vamos a usarlas.

$letrabase: 10px
$letrapequena: $letrabase - 2px
$letragigante: $letrabase * 2
#menusuperior
	height: 150px
	font:
		size: $letrabase
		style: italic
		weight: bold
	.submenu
		font-size: $letrapequena
		background-color: lightgray
		height: 100px
		a
			text-decoration: none
			font-size: 11px
			color: turquoise
			&:hover
				font-size: 13px
	.title
		font:
			size: $letragigante:
			weight: bolder
			style: normal
#menulateral
	width: 200px
	float: left
	font:
		size: $letrabase
		style: italic
		weight: bold
	.submenu
		font-size: $letrapequena
		background-color: palegreen
		height: 20px

Pero aún hay más. La verdadera potencia de sass reside en los mixins.
Desde siempre se ha hecho el, digamos truquillo, de crear una clase, por ejemplo, la clase “bordeazul”, que define unas propiedades, y luego al escribir html se aplica ese atributo class="bordeazul" en repetidos sitios. El problema es que, aun sin hacerlo explícitamente, estamos rompiendo el principio de encapsulación (contenido en el html, presentación en las hojas de estilo).

Hoy en día la tendencia es intentar que la web (su código html) sea lo más semántico posible. Las clases deberían definir el rol de un elemento, y no su presentación. Por ejemplo, crear una clase menu, una clase post o una clase avatar parecen buena ideas, mientras que crear clases como bordeazul, letrapequena o alineadoaladerecha no lo parece.
Un mixin es un fragmento de código nombrado que puede contener agrupadas propiedades y selectores, y de forma que se pueden reutilizar o usar para agrupar propiedades comunes.

Sass tiene en los mixins una herramienta que nos permite obtener el mismo objetivo de una forma elegante.
Vemos que en ejemplo de arriba, tanto #menusuperior como #menulateral tienen en común el tipo de letra. Más aun. Tienen en común que sus tags-hijo de clase submenu comparten también el tamaño de letra. Definamos un mixin que encapsule este comportamiento, y llamémosle menu.
Los mixins se definen con la directiva @mixin NombreDelMixin y se usan dentro de un tag con +NombreDelMixin.

$letrabase: 10px
$letrapequena: $letrabase - 2px
$letragigante: $letrabase * 2
@mixin menu
	font:
		size: $letrabase
		style: italic
		weight: bold
		.submenu
			font-size: $letrapequena

Una vez definido, normalmente al comienzo de la hoja de estilo, cuando llega la hora de usarlo, solo tenemos esto:

#menusuperior
	+menu
	height: 150px
	.submenu
		background-color: lightgray
		height: 100px
		a
			text-decoration: none
			font-size: 11px
			color: turquoise
			&:hover
				font-size: 13px
	.title
		font:
			size: $letragigante:
			weight: bolder
			style: normal
#menulateral
	+menu
	width: 200px
	float: left
	.submenu
		background-color: palegreen
		height: 20px

Pero mejor todavía. Los mixins se comportan como funciones, aceptan parámetros para personalizar su comportamiento. Supongamos que queremos usar la propiedades css avanzadas para la transparencia. Su soporte entre navegadores varía entre IE, firefox, webkit y konkeror. En ese caso creamos el mixin transparencia.

@mixin transparencia($value: 0.5)
	filter: alpha(opacity=#{$value * 100})
	-moz-opacity: $value
	-khtml-opacity: $value
	opacity: $value

Este mixin admite un valor entre 0 y 1 para la transparencia, y aplica todos los estilos para que funcione en todos los navegadores. Después en lugar de escribir esas 4 lineas allá donde queramos dar transparencia, solo invocamos a este mixin con un valor. Si lo invocamos sin valor, toma el valor por defecto (0.5).

#tagquequierohacertransparente
     +transparencia(0.3)

La potencia que dan los mixins a la hora de reutilizar fragmentos de código y crear hojas de estilo modulares es increíble, y aun queda la posibilidad de importar archivos sass ya creados con la directiva @import, o extender clases ya existentes con la directiva @extend. De hecho gracias a estos principios han nacido frameworks css como Compass.

Llegados a este punto hay que explicar que sass no es un lenguaje que un navegador entienda, ni un lenguaje que admita cambios en tiempo de ejecución. Los archivos sass se compilan, y de ellos salen hojas de estilo CSS tradicionales. Las variables solo son variables conceptualmente, en la práctica son constantes, y en el archivo CSS complilado $letrapequena volverá a ser 8px. Pero lo que a nosotros nos importa es lo que nosotros vemos.

Usando sass podemos tener nuestros estilos divididos en múltiples archivos, con mixins, imports, y organizado de forma modular a nuestro antojo, que luego todo puede ser compilado en una sola hoja de estilo, optimizando ancho de banda y numero de conexiones.

Sass actualmente tiene dos sintaxis. La que yo he usado en este tutorial, que son archivos .sass, y se basa en indentación, y la sintaxis de los archivos .scss, que prescinde de la indentación y utiliza llaves y algunas diferencias más. La sintaxis scss es más cercana a la sintaxis css de toda la vida, y a la gente le cuesta menos acostumbrarse al cambio. La sintaxis sass sin embargo, me parece mas elegante y legible. Pero todo va en gustos.

Sass se instala junto con haml, e instala también algunos comandos para transformar ficheros sass/css.

podéis encontrar información largo y tendido en la pagina web del proyecto y en su referencia.

Con esta segunda parte termina el primer acercamiento al proyecto HAML/SASS.

Bienvenidos al mundo del “Write less, do more”

Anuncios

, , , ,

  1. Deja un comentario

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: