Las estructuras simples no existen con CSS
Publicado el Sábado 20 de Enero del 2007 @ 7:35 por Armonth.
Cuando escribo una hoja de estilo en cascada o CSS a menudo me encuentro que, si bien existen estándares sobre los elementos que la forman, no existe casi ninguna recomendación sobre su estructuramiento, jerarquía, etcétera…
A menudo pasa que vas añadiendo apaños, quitando y poniendo y lo que en principio era una hoja de estilos simple se vuelve compleja y sobretodo difícil de leer…
La verdad es que no estaría mal compartir consejos sobre cómo mejorar este punto que a veces convierte lo que debería ser un apaño puntual en un infierno…
Antes de nada, destacar que nada de lo que digo a continuación lo he puesto en SigT, más que nada por falta de tiempo y/o ganas (ya se sabe: los proyectos o se hacen siempre con la mitad del tiempo necesario o no se hacen… al menos en España).
Crear una jerarquía: separación en ficheros “temáticos”
Lo más difícil es decidirse por un patrón a seguir, tendemos demasiado a juntar pegotes: ahora el contenedor del sidebar, ahora los estilos de dicho contenedor, luego los estilos de tags de texto (<p>, <acronym>…), etcétera.
Una buena solución pasa por dividirlos en distintos ficheros: por ejemplo un style.css que importe los ficheros CSS:
- screen.css: el cuerpo (body) y contenedores para el diseño o layout para la pantalla, lo típico: cabecera, contenido, menú, pie de página. Solamente aquello que sea de estructura (margenes, anchos, altos, etcétera).
- content.css: el contenido y las reglas especificas del mismo, tales como
div#sidebar a:hover { }odiv#footer blockquote strong { }. Con éste y el screen.css se forma el diseño final. - hacks.css: hacks específicos para ciertos navegadores. Éste último en lugar de cargarse con
@importdebería cargarse vía PHP si el navegador es el que va a usar los hacks…
Con esta división podemos por ejemplo aprovechar el contenido cacheado de content.css y una versión alternativa del screen.css para la impresión.
También, entiendo que el usar varios ficheros pueda ser más una molestia que una ventaja, en ese caso pasamos a otra idea a la que he llamado modelo DEC (Diseño-Etiquetas-Compuesto).
Jerarquía: modelo DEC
El modelo DEC es básicamente lo anteriormente dicho pero teniéndolo todo en un mismo fichero: primero lo específicamente de diseño, luego las etiquetas que forman XHTML definidas de forma estándar y luego las excepciones que son etiquetas a aplicar en ciertas partes del diseño (compuesto). Un ejemplo de la estructura con un diseño típico de los de WordPress:
/* Diseño */
body {}
div#wrap {}
div#content {}
div#sidebar {}
div#footer {}
/* Etiquetas */
a {}
a:hover {}
a:visited {}
abbr {}
/* Compuesto */
div#content a {}
div#content abbr {}
div#sidebar ul li {}
.clear { clear: both; }
.especial {}
Reglas especificas para hacks...
Lo cual nos lleva al siguiente punto, usemos esté modelo, el de ficheros temáticos (o directamente pero ordenados por grupos temáticos más precisos: formularios, contenidos, listas, etcétera…) o el que sea debemos hacerlo en orden alfabético y nos vendrá de perlas tener una lista de las etiquetas XHTML más comunes:
a {}
abbr {}
acronym {}
address {}
big {}
blockquote {}
body {}
br {}
button {}
caption {}
cite {}
code {}
col {}
colgroup {}
dd {}
del {}
div {}
dfn {}
dl {}
dt {}
em {}
fieldset {}
h1 {}
h2 {}
h3 {}
h4 {}
h5 {}
h6 {}
hr {}
img {}
input {}
ins {}
kbd {}
label {}
legend {}
li {}
ol {}
p {}
pre {}
q {}
small {}
span {}
strike {}
strong {}
sub {}
sup {}
table {}
tbody {}
td {}
textarea {}
tfoot {}
th {}
thead {}
tt {}
ul {}
Está organización por orden alfabetico es importante para evitar repetir un elemento y que esté nos cause problemas por estar definido anteriormente. Por no hablar de las redundancias de código…
¿Cual es vuestra receta? ¿usáis alguna o cómo salga?
7 Comentarios (feed)
-
corsaria nos comenta:
Pues mi método es añadir… añadir y añadir… jeje. Aunque lo mejor es estructurarlo todo y comentarlo para en caso de necesidad poder hacer modificaciones de forma rápida y sencilla.
Por aquí ví algunas ideas:
http://icebeat.bitacoras.com/post/224/organizar-un-cssSaludos. :-)
-
Sergio nos comenta:
Hola!
A mi me funciona muy bien separar las css como has dicho (sobre todo poner los hacks aparte), incluso por módulos de la página.
Y luego cada CSS la separo, primero los estilos generales de etiquetas, luego las clases y luego las ids.
También intento indetar en función de los padres, en plan:
.contenedor {
}
.header{
}
.logo{
}
etc…Ayuda a mantener el código estructurado y encontrar bien las cosas.
-
Sergio nos comenta:
Vale, intenté que pareciera que header tiene un tabulador respecto a contenedor y lo mismo resp. a logo, pero ha quedado así. La idea es esa, vaya (reminiscencias de programador de toda la vida ;)
-
InKiLiNo nos comenta:
Es lo mejor tener el código bien separado por partes y estructurado, asi cuando buscas algo no te vuelves loco ;)
-
Sergio de la Torre nos comenta:
A veces la opción de búsqueda de mi editor echa humo :S
-
Armonth nos comenta:
A mí lo que me gustaría para GNU/Linux es un editor CSS que guarde los ficheros con estructura “ligera” (campo { unidad:valor; unidad2:valor2; }) y luego te lo desglosará al editarlo para ver los cambios fácilmente…
Sé que para algunos el tener 1 línea por cada campo hace difícil la lectura pero al menos a mí no me lo hace y es mejor eso que tener 200km de scrolling…
-
José R. Quevedo nos comenta:
Dave Shea, habló sobre este tema en Fundamentos Web 2006. Algunas de sus ideas eran interesantes.
