Object Oriented CSS (OOCSS)

Object Oriented CSS (OOCSS) es una técnica muy interesante para trabajar con CSS.

malevich

archivado en: HTML/CSS / 10 diciembre, 2012

En una entrada de la serie de WordPress salió el tema de la Object Oriented CSS (OOCSS), que trataré de desarrollar con más detalle en esta entrada, cuya principal referencia bibliográfica es el artículo An Introduction To Object Oriented CSS (OOCSS) de Louis Lazaris.

La OOCSS es una técnica para optimizar el trabajo con CSS  desarrollada por Nicole Sullivan y es importante  aclarar cuanto antes que no tiene la menor relación con la programación orientada a objetos, a pesar de su nombre, atinado por llamativo, pero desafortunado por confuso ya que se basa en una analogía discutible.

La filosofía de esta técnica se fundamenta en un concepto de programación denominado Don't Repeat Yourself (DRY), «no te repitas a ti mismo», al parecer a partir de un ensayo de  Andrew Hunt y David Thomas titulado The Pragmatic Programmer: From Journeyman to Master. En esencia, la programación DRY consiste en no escribir una línea de código igual que otra o que sirva para lo mismo, lo cual permite optimizar el esfuerzo en desarrollo y mantenimiento.

A partir de este principio, la OOCSS plantea un método de trabajo cuyas dos premisas básicas son: separar la estructura de la piel y separar el contenido del contenedor.

Separate structure and skin

Las propiedades relacionadas con la estructura son las que afectan a la posición de un elemento en la página, como margin, position, left, top, bottom o right.

Las propiedades de la piel, skin en inglés, son las que definen su aspecto gráfico, como el color de fondo, el color o el tamaño de la fuente, el interlineado, el color y tipo de borde, etcétera. Como eso de la piel no me gusta demasiado como traducción, de aquí en adelante me referiré a estas propiedades como «gráficas».

Entonces, según la OOCSS nunca hay que mezclar las definiciones estructurales con las gráficas. Esto se entiende bien con un ejemplo. Imaginemos que tenemos tres elementos, un botón, un contenedor y un párrafo, que tienen las mismas propiedades gráficas, pero distintas definiciones estructurales:

  • .boton {
  • position: absolute;
  • left: 10px;
  • border: 1px solid #900;
  • background-color: #c00;
  • }
  • .mi_contenedor {
  • margin-right: 20px;
  • width: 200px;
  • border: 1px solid #900;
  • background-color: #c00;
  • }
  • .mi_parrafo {
  • margin-top: 5px;
  • height: 300px;
  • border: 1px solid #900;
  • background-color: #c00;
  • }

Este código plantea dos problemas: uno, si dentro de un tiempo queremos cambiar el color de fondo, tenemos que modificar tres estilos; y, dos, hemos repetido tres veces la misma instrucción para el borde y el fondo. Es decir, hemos triplicado nuestro trabajo ahora y en el futuro y, además, hemos enviado más código al dispositivo cliente y, por lo tanto, hemos ralentizado nuestra página. Y hay que tener en cuenta que en este ejemplo solo hay unas pocas líneas, pero una web compleja puede tener centenares, miles...

Por el contrario, separando la estructura de la apariencia gráfica, podemos optimizar el código:

  • .boton {
  • position: absolute;
  • left: 10px;
  • }
  • .mi_contenedor {
  • margin-right: 20px;
  • width: 200px;
  • }
  • .mi_parrafo {
  • margin-top: 5px;
  • height: 300px;
  • }
  • .bordes_rojos {
  • border: 1px solid #900;
  • }
  • .fondos_rojos {
  • background-color: #c00;
  • }

Luego en el HTML basta con indicar todas las clases que se necesiten separadas por espacios:

  • <p class="mi_parrafo bordes_rojos fondos_rojos">Soy un párrafo con los bordes y el fondo rojo</p>

Separate container and content

Es frecuente definir algunos estilos en función del contenedor. Por ejemplo, imaginemos que tenemos unos enlaces dentro de un nav que sirve de barra de navegación:

  • <nav id="barra_de_navegacion">
  • <a href="#">enlace 1</a>
  • <a href="#">enlace 3</a>
  • <a href="#">enlace 2</a>
  • </nav>

Para definir el estilo del enlace, se puede seleccionar la etiqueta <a>, el contenido, haciendo referencia a su contexto, el nav barra_de_navegacion, que es su contenedor.

  • #barra_de_navegacion a {
  • background-color: #900;
  • }

Pero eso es justo lo que no hay que hacer según la segunda regla de la OOCSS, ya que así: «todos los elementos sin clase <h2> son iguales; (2) todos los elementos con la misma clase son iguales y (3) no se necesita sobrescribir un estilo cuando se quiera modificar».

La suma de estos dos principios, junto a una serie de reglas, como no usar nunca IDs para aplicar estilos, que van siempre en clases, conforman lo que Sullivan denomina «objetos CSS». Un «objeto CSS», por ejemplo, sería este estilo para aplicar a los elementos multimedia, como los vídeos.

  • .media {
  • overflow:hidden;
  • *overflow:visible;
  • zoom:1;
  • }

Plantillas, preprocesadores y las reglas de CSS Lint

A partir de estas reglas, Sullivan y otros programadores han diseñado una serie de plantillas para definir las CSS, que si fueran universales facilitarían la comprensión del código por cualquier persona. Por ejemplo, si usamos la plantilla table, nada más ver una tabla con clase .txtC, alguien sabría que define un estilo text-align:center.

Al parecer, las plantillas van muy bien con los preprocesadores de CSS Less y Sass. Como no los uso ni creo que vaya a emplearlos a medio plazo, me limito a sugerir la lectura del artículo The relationship between OOCSS and CSS preprocessors de Criss Webb;  Sass vs. LESS en CSS Triks y este otro de Jeremy Hixon en Smashing Magazine: An Introduction To LESS, And Comparison To Sass.

Además, en torno a la OOCSS se ha desarrollado en git hub un proyecto para realizar hojas de estilo más limpias y sólidas, el cual consiste en seguir una serie de reglas que puedes validar en la aplicación CSS Lint. Muchas son las que ya usamos al margen de esta técnica, pero, en cualquier caso, vale la pena echarles un vistazo.  Si acaso, otro día las comento con calma.

¿Son realmente tan formidables?

Las OOCSS cuentan con entusiastas seguidores, pero también hay voces críticas, como la de Jeffrey Zeldman, que en un artículo titulado In defense of descendant selectors and id elements defiende los selectores cuando están bien empleados, ya que sostiene son más semánticos y consumen menos recursos.

In this particular (and rare) circumstance, where dueling developers have added rule after rule to a huge, shapeless style sheet that is more of an archeological artifact than a reasonable example of modern code, Nicole’s admonition to avoid descendant selectors based on id is probably wise. If you have the misfortune to work on a huge, poorly developed site where you will never have permission to refactor the templates and CSS according to common sense and best practices, you may have to rely on class names and avoid descendant selectors andids.

But under almost any other circumstance, properly used ids with descendant selectors are preferable because more semantic and lighter in bandwidth.

Mi opinión es que la OOCSS tiene propuestas muy interesantes. Con esto no quiero decir que se deban adoptar y seguir a rajatabla, sino que es algo que vale la pena conocer, pues nos puede aportar información valiosa para optimizar el trabajo, ya sea siguiendo este método o cualquier otro.

Los dos planteamientos iniciales me parecen muy aconsejables en líneas generales, aunque a partir de ahí ya no tengo tan clara su utilidad, sobre todo en el caso de sitios pequeños, donde me parece que es matar moscas a cañonazos. De hecho, creo que sobre todo debemos ser flexibles. No es lo mismo diseñar Facebook, que sigue la técnica OOCSS, como recuerdan con insistencia sus partidarios, que una web corporativa para una pyme local. Para las webs ciclópeas es probable que resulte útil, pero para las pequeñas y medianas no veo nada claro que las plantillas no terminen siendo un obstáculo antes que una utilidad.

En síntesis, los dos principios están muy bien y me parecen muy útiles para muchas cosas, como los colores de los textos. Sin embargo, para otros elementos, como los cuatro o cinco contenedores básicos de un tema de WordPress (la cabecera, el cuerpo central, el sidebar, el sidebar inferior y el pie), me resulta más cómodo trabajar con IDs, que, entre otras facilidades, me permiten tener agrupado los respectivos estilos y así localizarlos con rapidez.

|| Tags: ,

valoración de los lectores sobre Object Oriented CSS (OOCSS)

  • estrellica valoración positiva
  • estrellica valoración positiva
  • estrellica valoración positiva
  • estrellica valoración positiva
  • estrellica valoración positiva
  • 4.8 sobre 5 (11 votos)

¿Te ha parecido útil o interesante esta entrada?
dormido, valoración 1 nadapensativo, valoración 2 un poco sonrisa, valoración 3 a medias guiño, valoración 4 bastante aplauso, valoración 5 mucho

Tú opinión es muy importante, gracias por compartirla!

2 respuestas a “Object Oriented CSS (OOCSS)