El documento presenta los principios del CSS orientado a objetos. Explica que aunque CSS no tiene objetos reales, puede simular conceptos como herencia y composición mediante mecanismos como la especificidad y orden de aplicación de las reglas CSS. También cubre principios como DRY, responsabilidad única y legibilidad de nombres. El objetivo final es hacer que los estilos CSS sean reutilizables, extensibles y mantenibles.

1. Object Oriented CSS
(o sea, CSS mantenible)
@eamodeorubio

2. (o quién soy y por qué me decidí a hacer esta charla)
¿Qué haces tu aquí?
@eamodeorubio

3. Así parezco un to
Me presento interesante
Enrique Amodeo
 Me dedico al software
 En el negocio desde el año 2000
 Desarrollo y arquitectura de software
 Consultoría y formación
 Javascript/AJAX/RIA desde 2006
 Haciendo agilismo desde 2005
 Mail: eamodeorubio@gmail.com
 Blog: http://eamodeorubio.wordpress.com/
 Sígueme, leches: @eamodeorubio
@eamodeorubio

4. ¿Qué pinta un desarrollador
hablando de CSS?
●
Me hice un
framework AJAX/CSS
●
Pero mis CSS eran un
dolor
●
Dolor → Aprendizaje
●
Redescubrir la rueda
@eamodeorubio

5. (¿ein?)
¿Qué es CSS Orientado a Objetos?
@eamodeorubio

6. Un poco de marketing
• CSS Orientado a Objetos ← ¡Cool!
• CSS Mantenible y Reutilizable ← Un poco largo
• Clean CSS ← ¡Mejor!
• Popularizado por Nicole Sullivan
( @stubbornella ) → Escogió el nombre cool
@eamodeorubio

7. CSS es código
• Hay que mantenerlo → ¡Ojo a la calidad!
●
Extensible y reutilizable
●
Legible y predecible (no surprise!)
• Debe cumplir principios de diseño de código
●
DRY
●
SOLID (bueno, lo que se pueda)
●
Legibilidad
@eamodeorubio

8. DRY
Evitar duplicación de información
.left_corner {
background-image:url(img/cornerleft.gif);
width:9px;
height:9px;
float:left;
}
.top_corner {
background-image:url(img/cornertop.gif);
width:9px;
height:9px;
float:left;
}
@eamodeorubio

9. DRY
Evitar duplicación de información
.left_corner {
background-image:url(img/cornerleft.gif);
width:9px;
height:9px;
float:left;
}
.top_corner {
background-image:url(img/cornertop.gif);
width:9px;
height:9px;
float:left;
}
@eamodeorubio

10. DRY
Evitar duplicación de información
.corner_common {
width:9px;
height:9px;
float:left;
}
.left_corner {
background-image:url(img/cornerleft.gif);
}
.top_corner {
background-image:url(img/cornertop.gif);
}
@eamodeorubio

11. DRY
Después veremos como reutilizarlo
.corner_common {
width:9px;
height:9px;
float:left;
}
.left_corner {
background-image:url(img/cornerleft.gif);
}
.top_corner {
background-image:url(img/cornertop.gif);
}
@eamodeorubio

12. Single Responsability
Una única responsabilidad, un sólo motivo para cambiar
.important_notification {
color:blue;
background-color:yellow;
font-weight:bold;
text-decoration:underline;
}
@eamodeorubio

13. Single Responsability
Una única responsabilidad, un sólo motivo para cambiar
¿Qué ocurre si decidimos
.important_notification { cambiar el diseño de las
color:blue;
background-color:yellow; notificaciones?
font-weight:bold;
text-decoration:underline;
}
@eamodeorubio

14. Single Responsability
Una única responsabilidad, un sólo motivo para cambiar
.important_notification {
color:blue;
background-color:yellow;
font-weight:bold;
text-decoration:underline;
}
¿Qué ocurre si decidimos
cambiar el diseño de los
textos importantes?
@eamodeorubio

15. Single Responsability
Una única responsabilidad, un sólo motivo para cambiar
.notification {
color:blue;
.important_notification { background-color:yellow;
color:blue; }
background-color:yellow;
font-weight:bold;
text-decoration:underline;
} .important {
font-weight:bold;
text-decoration:underline;
}
@eamodeorubio

16. Legibilidad
Nombres deben expresar intención de uso
.bd { .main_content_section {
… …
} }
.h_levelA { .important_title {
… …
} }
.h_levelB { .normal_title {
… …
} }
@eamodeorubio

17. Legibilidad
Nombres deben ser semánticos
.bd { .main_content_section {
… …
} }
.h_levelA { .important_title {
… …
} }
.h_levelB { .normal_title {
… …
} }
@eamodeorubio

18. Legibilidad
¿Y qué es eso de “nombres semánticos”?
.high_contrast {
...
}
.main_content {
...
}
¿Son estos nombres
.column { semánticos?
...
}
.contact_info {
...
}
@eamodeorubio

19. Legibilidad
• Representan conceptos del dominio del problema
• Podemos tener varios problemas distintos:
●
Layout
●
Esquema de colores
●
Estructura de contenidos
●
Tipos de contenidos
• Cada uno tiene un vocabulario diferente
@eamodeorubio

20. Legibilidad
Distintos problemas, distinto vocabulario
.high_contrast { Esquema de
...
}
colores
.main_content {
... Estructura
}
.column {
... Layout
}
.contact_info {
... Tipo de datos
}
@eamodeorubio

21. Pero, ¿el HTML no era semántico?
• Sí, pero no lo cubre todo.
• HTML4: p, strong, etc
• HTML5 es bastante mejor.
●
Estructura: detail, section, article, aside,
nav...
●
Contenido: audio, video, address
@eamodeorubio

22. CSS para HTML5 y 4
●
Sustituir clases redundantes con CSS5 por selectores tipo elemento
(article, nav, …)
●
Usar clases sólo para hacer distinciones más finas
●
Usar div y span en HTML4 en combinación de clases
.articulo, article {
...
}
.pie, footer {
...
}
@eamodeorubio

23. Open Closed
Cerrado a modificación pero abierto a extensión
● HTML cerrado pero “extensible”: Cambiar el
diseño sin cambiar la estructura HTML
• CSS cerrado: Cambiar la estructura HTML no
debería implicar cambiar CSS
• CSS extensible:
● Estilos deben poder componerse, y aprovechar
la estructura HTML para ello
● Plugins (temas, skins, ...)
@eamodeorubio

24. Open Closed
Cerrado a modificación pero abierto a extensión
CSS y estructura HTML deben independizarse al
máximo
@eamodeorubio

25. Open Closed
Cerrado a modificación pero abierto a extensión
CSS y estructura HTML deben independizarse al
máximo
Independizar estlos del
contenido de los del
contenedor
@eamodeorubio

26. Open Closed
Cerrado a modificación pero abierto a extensión
CSS y estructura HTML deben independizarse al
máximo
Evitar (en lo posible)
Independizar estlos del selectores que acoplen a la
contenido de los del estructura HTML: tag,
contenedor descendant, child, ...
@eamodeorubio

27. (si no tienes objetos...)
CSS Reutlizable y Extensible
@eamodeorubio

28. Límites del CSS
• Los estilos CSS no son paramétricos
• No hay “instancias” ni “objetos” ni
“interfaces”
• No existe el concepto de colaboración
@eamodeorubio

29. Límites del CSS
• Los estilos CSS no son paramétricos
• No hay “instancias” ni “objetos” ni
“interfaces”
• No existe el concepto de colaboración
¿Como lo hacemos para reutlizar código?
@eamodeorubio

30. Límites del CSS
• Los estilos CSS no son paramétricos
• No hay “instancias” ni “objetos” ni
“interfaces”
• No existe el concepto de colaboración
ON
CI
¿Como lo hacemos para reutlizar código?
SI
PO
M
CO
@eamodeorubio

31. Composición
• Varias reglas CSS pueden aplicarse sobre un
mismo elemento HTML
• Las declaraciones de las reglas CSS se fusionan
• Si hay conficto, la declaración de la regla con
mayor precedencia gana (override)
• Similar a la herencia múltiple
@eamodeorubio

32. Precedencia
1. Media-type
2. Autor e importancia:
●
Usuario e !important (accesibilidad)
●
Autor de la página e !important (overrides in-style) ← :-/
●
Autor de la página
●
Usuario
●
Navegador
3. Especificidad ← Lo que nos interesa en el 80% de los casos
4. Orden de aplicación ← El último gana
@eamodeorubio

33. Especificidad
1. Estilos en línea (<div style=”color:red”>)
2. Selector #id
3. Clases, pseudo-clases, atributos (.importante,
a:visited, a[rel=author])
4. Elementos (a, div, p...) y pseudo elementos
(p:first-line)
@eamodeorubio

34. Especificidad
¡ Hay que contar el número de items de cada
categoría!
#id1 {
...
}
.class1 .class2 {
...
}
p.column {
...
}
.main_content {
...
}
p {
...
}
@eamodeorubio

35. Especificidad
¡ Hay que contar el número de items de cada
categoría!
#id1 {
...
}
.class1 .class2 {
...
OVERRIDES
}
p.column {
...
}
.main_content {
...
}
p {
...
}
@eamodeorubio

36. El último gana
<div class="skinA">
<p class="nota importante">Urgente</p>
OVERRIDES
</div>
@eamodeorubio

37. El último gana
<div class="skinA">
OVE
RRI
DES
<p class="nota importante">Urgente</p>
</div>
@eamodeorubio

38. ¿Y eso del inheritance?
• ¡En realidad, no!
• Todo elemento HTML tiene valores CSS por
defecto que dependen del browser
• Pero el valor por defecto de algunos atributos
CSS se pueden heredar del padre
• Podemos forzar que una propiedad se herede
con el valor “inheritance”
@eamodeorubio

39. ¿Y eso del inheritance?
<div class="skinA">
DEFAULT
<p class="nota importante">Urgente</p>
OVERRIDES
<p class="nota">Esto es otra nota</p>
</div>
@eamodeorubio

40. ¡ Todo junto ! → “Plugins”
.email {
... <div class="cool_skin">
}
<span class="email">
.tfno {
...
} eamodeorubio@gmail.com
.cool_skin { </span>
...
} <span class="tfno">
.cool_skin .email {
...
+34 563 564 567
}
</span>
.cool_skin .tfno {
... </div>
}
@eamodeorubio

41. ¡ Todo junto ! → “Plugins”
.email {
<div class="cool_skin">
}
...
Estilos básicos, abstractos y
semánticos
<span class="email">
.tfno {
...
} eamodeorubio@gmail.com
.cool_skin { </span>
...
} <span class="tfno">
.cool_skin .email {
...
+34 563 564 567
}
</span>
.cool_skin .tfno {
... </div>
}
@eamodeorubio

42. ¡ Todo junto ! → “Plugins”
.email {
... <div class="cool_skin">
}
<span class="email">
.tfno {
...
} eamodeorubio@gmail.com
Valores por defecto globales
.cool_skin { para el</span>
plugin 'cool_skin'
...
} <span class="tfno">
.cool_skin .email {
...
+34 563 564 567
}
</span>
.cool_skin .tfno {
... </div>
}
@eamodeorubio

43. ¡ Todo junto ! → “Plugins”
.email {
... <div class="cool_skin">
}
<span class="email">
.tfno {
...
} eamodeorubio@gmail.com
El plugin 'cool_skin' extiende
.cool_skin { </span>
las clases base. Sus reglas
...
} son <span class="tfno">
más específicas
.cool_skin .email {
...
+34 563 564 567
}
</span>
.cool_skin .tfno {
... </div>
}
@eamodeorubio

44. Organizar reglas CSS en niveles de
abstracción
Cuanto más abstracta sea una regla:
• Menor precedencia debería poseer
• Menor cantidad de declaraciones debería
tener
• Su ámbito de aplicación será mayor
@eamodeorubio

45. ¿Es CSS capaz de OO?
• No, pero posee mecanismos capaces de simular la herencia
simple, múltiple y mixins.
• La precedencia nos permiten simular la cadena de herencia y
abstracción
• La composición nos permite simular la herencia múltiple y/o los
mixins:
●
Mediante “inheritance”
●
Usando class=”claseX claseY claseZ”
●
Mediante selectores no disjuntos
●
A veces es necesario acoplarse algo a la estructura de HTML
(plugins y contenido semántico de HTML)
@eamodeorubio

46. Soy desarrollador, ¿y a mi qué?
• Desarrolladores y diseñadores deben cooperar
●
HTML → Diseñador
●
Contenido reglas CSS → Diseñador
●
Comportamiento (JavaScript) →
Desarrollador
@eamodeorubio

47. Soy desarrollador, ¿y a mi qué?
• Desarrolladores y diseñadores deben cooperar
●
HTML → Diseñador
●
Contenido reglas CSS → Diseñador
●
Comportamiento (JavaScript) →
Desarrollador
¡Los selectores CSS son el contrato!
(usa jQuery o Sizzle)
@eamodeorubio

48. Soy desarrollador, ¿y a mi qué?
Esto déjaselo a los diseñadores
.email {
... <div class="cool_skin">
}
<span class="email">
.tfno {
...
} eamodeorubio@gmail.com
.cool_skin { </span>
...
} <span class="tfno">
.cool_skin .email {
...
+34 563 564 567
}
</span>
.cool_skin .tfno {
... </div>
}
@eamodeorubio

49. Soy desarrollador, ¿y a mi qué?
En esto ponéos de acuerdo
.email {
... <div class="cool_skin">
}
<span class="email">
.tfno {
...
} eamodeorubio@gmail.com
.cool_skin { </span>
...
} <span class="tfno">
.cool_skin .email {
...
+34 563 564 567
}
</span>
.cool_skin .tfno {
... </div>
}
@eamodeorubio

50. Soy desarrollador, ¿y a mi qué?
Y esto es todo tuyo
jQuery('.email').makeEditableField();
// Not specially good code!
jQuery('.email').change(function() {
if(!isValidEmail(jQuery(this).val()))
markAsInvalid(jQuery(this), "Invalid email");
});
// Etc..
@eamodeorubio

51. Soy desarrollador, ¿y a mi qué?
JS Frontend Application Logic
Arquitectura HMVC
Controller
●
Bajo acoplamiento
HTML ↔ JS Logic View Model
●
Selectores CSS
actúan como
interface DOM View (a.k.a. Widget)
JQuery (Controller)
●
Desacoplarnos del
DOM → CSS
(View)
HTML
(Model)
HTML/CSS/JS
@eamodeorubio

52. (tenía que pasar...¿será un framework evil?)
¿Nos hacemos unos frameworks?
@eamodeorubio

53. Problemas a resolver
• X-Browser (reset)
• Layout (en cooperación con HTML5)
• Contenedores (en cooperación con HTML5)
• Widgets reutilizables
• Skins
• Representar contenido de negocio de forma
consistente
@eamodeorubio

54. Reset
• Cada browser da una regla CSS para cada
elemento
• Es de baja prioridad, pero sobreescribe los
valores por defecto
• Si quieres X-Browser CSS y evitar sorpresas lo
mejor es anular este CSS por defecto
• http://meyerweb.com/eric/tools/css/reset/
• http://developer.yahoo.com/yui/reset/
@eamodeorubio

55. Grids
960.gs, YUI, OOCSS, etc.
@eamodeorubio

56. Grids
From @stubornella
(https://github.com/stubbornella/oocss/wiki/Grids)
<div class="line">
<div class="unit size1of3">
<h3>1/3</h3>
<p>Lorem ipsum dolor sit amet...</p>
</div>
<div class="unit size2of3 lastUnit">
<h3>2/3</h3>
<p>Lorem ipsum dolor sit amet...</p>
</div>
</div>
@eamodeorubio

57. Containers
• Agrupan contenido y widgets de forma
homogénea
• No son relevantes para el usuario por si
mismos, sino por el contenido
• Deben aceptar cualquier contenido
• No interferir con su contenido
• Ej. pestañas, barra lateral, “portlet”
@eamodeorubio

58. Containers
From @stubornella
(https://github.com/stubbornella/oocss/wiki/Module)
<div class="mod">
<b class="top"><b class="tl"></b><b class="tr"></b></b>
<div class="inner">
<div class="bd">
<p>Lorem ipsum.</p>
</div>
</div>
<b class="bottom"><b class="bl"></b><b class="br"></b></b>
</div>
@eamodeorubio

59. Widgets
• Controles de usuario
• Pueden ser simples o complejos
• Interacción con el usuario homogénea
• Foco de atención de los desarrolladores
• Bien cubiertos por frameworks existentes
• Ej. boton, botonera, menu, enlace, campo de
importes, etc....
@eamodeorubio

60. Contenido
• Específico de cada aplicación
• Layout y aspecto visual de entidades de negocio
• Relevantes para el usuario
• Ej. “contacto”, “dirección”, “tweet”, etc.
• Microformatos (http://microformats.org)
●
hCard
●
hCalendar
●
rel-nofollow
●
rel-tag
@eamodeorubio

61. Contenido
<div class="vcard">
<a class="fn org url" href="http://www.commerce.net/">CommerceNet</a>
<div class="adr">
<span class="type">Work</span>:<div class="street-address">169 University Avenue</div>
<span class="locality">Palo Alto</span>, <abbr class="region"
title="California">CA</abbr>&nbsp;&nbsp;
<span class="postal-code">94301</span><div class="country-name">USA</div>
</div>
<div class="tel"><span class="type">Work</span> +1-650-289-4040</div>
<div class="tel"><span class="type">Fax</span> +1-650-289-4041</div>
<div>Email: <span class="email">info@commerce.net</span></div>
</div>
@eamodeorubio

62. Skins
• Colores, lineas, fuentes...
• Totalmente independientes de la estructura
• Extienden a todos los demás elementos del
framework
• No afectan al layout
@eamodeorubio

63. ¿Q & A?
@eamodeorubio