Contenido

Útiles pautas para conseguir un CSS mantenible

19 Nov

+ 18

La gente de Woork ha escrito un interesante artículo en el que nos cuentan unas pautas con las que conseguir un CSS más fácil de mantener. A simple vista son unas pautas lógicas y que con un poco de experiencia consigues aplicarlas y optimizas sustancialmente el tiempo de mantenimiento de tu código.

Intentaré hacer una pequeña traducción de las mias, aportando mi visión del tema.

1) ¿Uno o multiples ficheros?

Muchos son los desarrolladores que usan multiples ficheros CSS para tener el código separado y quizas así consigan un poco más de control sobre el código, por otro lado he visto larguísimos ficheros CSS con miles y miles de líneas para evitar esto, lo que supone otro problema.

@import "file1.css";
@import "file2.css";
@import "file3.css";

Mi opinión? Pues depende mucho del proyecto, la complejidad del mismo y de la optimización que deseemos aplicar a cada una de las páginas. Si estamos desarrollando un theme para WordPress quizas la opción más apropiada se la de usar un solo CSS ya que este no va a crecer exageradamente, pero si por contra estamos desarrollando una página con una cantidad considerable de secciones/opciones sería conveniente dividir y pensar en optimizar la carga de cada una de las secciones/opciones.

2) Tabla de contenidos, ¿Sirven para algo?

Hace poco más de un año debatimos sobre el tema de los comentarios en el CSS, y la opinión general sobre el tema fué que había que encontrar un término médio y no crear una página CSS con más comentarios que código CSS.

En Woork explican que en alguna ocasión las han usado para los casos en los que se ha usado un único fichero CSS y de esa forma consiguen un poco de claridad del código insertado despues. Por contra en el caso de múltiples ficheros te ves obligado a ir actualizando varios ficheros cada vez que realizas un cambio en la estructura. 

/**
* @style       Standard Layout
* @media       screen
* @version     1.0
* @author      Franky
* @copyright   Franky’s pwn comp-a-ni
* @licensor    da customa
* @layout      in pixels:
*              |            788            |
*              | 10  |      768       | 10 |
*              | 10  | 27 |    741    | 10 |
*/

Mi opinión? El documentar es bueno, hay que documentar nuestro código en medida que sea fácilmente comprensible por una persona ajena a lo que estás haciendo pero nada más. Osea hay que decir lo justo, ni más ni menos, pero hay que decir algo. Usando un sistema jerarquico lógico bastaría para clarificar nuestro código.

3) Crear secciones para agrupar atributos similares

Una técnica que tambien te encuentras mucho por Internet es la de separar en secciones el CSS. Estas separaciones tienen un sentido y es el de agrupar atributos similares. Por ejemplo los que definen el tamaño, posición y aspecto.

#content {
	height:200px;
	width:760px;
	margin:0 auto;

	background-color:red;
	color:#000;
}

Mi opinión? Implica un reciclaje para los que no lo hacen, pero ayuda. El ver a simple vista todos los atributos que hacen un elemento esté en esa posición o tenga ese tamaño es un ahorro de tiempo considerable para futuras actualizaciones del código.

4) Tabular el código

Una técnica que da una calidad estética a los ficheros CSS es el tabular los valores de los atributos frente a los atributos. Esto muestra muy claramente el código de nuestro fichero.

#content {
	height:		    200px;
	width:		    760px;
	margin:		    0 auto;

	background-color:   red;
	color:		    #000;
}

Mi opinión? Pese a no hacerlo nunca, reconozco que más que una mejora visual es una ayuda a la comprensión del código para alguien ajeno a él.

  • Todas estas técnicas me parecen esenciales a la hora de mantener cualquier tipo de código, llámese CSS o JavaScript.
    Pero quería compartir mi opinión sobre el tema de un único archivo CSS o múltiples.
    Generalmente tengo cuatro archivos:
    1) CSS para la estructura.
    2) CSS para las fuentes y sus tamaños.
    3) CSS para los colores.
    4) CSS único con tres @import para agregar los anteriores.
    Sé que para mucho esto será tedioso, pero simplifica enormemente mi mantenimiento y posibles cambios futuros. Ya sean colores, cambio de alguna fuente o estructura.
    Un saludo a todos y enhorabuena por la página.

  • @LaStLiFe: Muy interesante la separación, aunque como bien dices tiene pinta de ser bastante tedioso.

    Me imagino hacer una cambio que afecte a los 3 ficheros, osea cambiar un elemento de color de fondo, de texto y de tamaño. Implica tener 3 ficheros abiertos con la misma definición del mismo elemento y hacer el cambio en 3 ficheros diferente, frente a una sola definición y todos los atributos en ella misma.

    Está claro que luego depende del proyecto, la persona y la rutina que hemos creado. Por eso existen las dos opciones 😀

    Gracias por compartir tu visión. ¿Alguna más? 😀

  • El otro día tuve una discusión parecida con mi jefe. Para los desarrolladores nos es más comodo tener los css los más organizados posibles para facilitarnos el trabajo y a veces creamos 3-4 css diferentes para grandes proyectos. Él sin embargo me decía que efectivamente sería más cómodo para nosotros pero el tener que realizar llamadas al servidor no es bueno para el usuario (aquí es donde me convencio). Incluso según que caso lo ideal sería meter el css en el propio html (por ejemplo) tal y como hace Yahoo aunque no sé hasta que punto esto es bueno para el SEO.

    Un ejemplo es que desde España tu maquina tarda 30ms en hacer una llama al servidor que por 4 son 120ms, inapreciable, pero si se hace desde Japon tarda 300ms que por 4 son 1200ms (algo si se nota). Teniendo en cuenta la cantidad de usarios que puede haber imaginaros.

    Conclusión: Para pequeñas webs siempre es mejor tener un solo css porque tampoco va a ser muy grande y para grandes webs también mejor un único css por mucho que nos cueste trabajar luego con él beneficiamos a nuestros usuarios y bajamos las llamadas a nuestros servidores.

  • Yo lo que tengo es algo un poco más simple y que me facilita bastante la vida:

    – un css para la estructura
    – un css para tags html (este cambia pocas veces)
    – un css para clases específicas

    Tambien los importo desde un cuarto css.
    Comentar que el estructura muchas veces tengo que duplicarlo para lidiar con ie6.

    Saludos

  • Aun teniendo varios css estoy completamente de acuerdo con Darklords y su jefe, cada petición al servidor implica una penalización en el rendimiento, siempre se podría tener varias css’s en producción y convertirla en una al pasar el sitio a explotación, llevo mucho tiempo pensando una pequeña aplicación que realize unas cuantas acciones en el paso a explotación de mis sitios, esta es otra tarea que apunto en el documento de análisis =).

    Saludos

  • @Darklords: Hombre aqui, y para hacer de abogado del diablo, os pongo una duda.

    ¿que nos interesa más?

    Tener 4 ficheros de 1kb que tardan 10ms cada uno
    Tener un fichero de 4kb que tarda 40ms

    Y más dificil todavía, ¿cual es la barrera entre que interese más dejarlo en 1 o en varios? (A peso me refiero)

    @carlos: Tu sistema me recuerda al que se consigue usando un framework CSS. Evidentemente el framework lo has desarrollado tu, muy interesante 😀

  • Yo sólo utilizo dos archivos css. Uno para la estructura del layout y reseteo css y el otro para el resto de elementos contenidos en ese layout. Eso si, cada sección o zona van separados por comentarios en los que procuro indicar a que parte pertenecen.

  • @Darklords: Bueno, reconozco que, obviamente, son 4 llamadas distintas, pero volveríamos a un poco lo mismo de siempre.
    ¿Páginas completas? ¿O peticiones por AJAX? ¿Siempre o a veces? ¿Calculamos si nos merece la pena cada vez que queramos introducir un nuevo módulo en la página o lo hacemos siempre por AJAX?
    Yo, personalmente, prefiero las llamadas, a pesar de que el servidor sufra. Para eso están 😛
    @carlos: Yo hice algo parecido para mi proyecto actual, aunque reconozco que con el poco tiempo que me dan para desarrollar cosas nuevas, es muy concreto. Pero es la mejor opción, sin duda.

  • Me alegra leer post justo cuando llevo unos días intentando estructurar mis CSS de manera que nos facilite el trabajo a mi compañera y a mí.
    Comparto la visión de LaStLiFe, incluso la llevo un poco más allá y estructuro en base a anchuras, alturas colores y fuentes, dentro de diferentes archivos:

    reset
    menu
    formularios
    estructura
    tema

    Todos ellos enlazados desde «general.css»

    Acabo de empezar a probar este sistema que todavía tengo que probar y perfeccionar, y la verdad es que es bastante tedioso. Pero el fin es crear una especie de plantillas a las que luego sea fácil de cambiar unos pocos valores dentro de la estructura. Me inspiro en la forma de pensar a la hora de trabajar:

    Creo la estructura, la dimansiono, y le aplico los colores yla imágenes. A los menus y fomularios les doy una importancia especial.

  • @aNieto2k te respondo al ejemplo que me dices porque hicimos una prueba para ver como funcionaba mejor.

    Hicimos 5 test:

    1- Un html con css de peso 360 Kb
    2- Un html con un css externo siendo la suma 360kb
    3- Un html con 3 css externos siendo también la suma 360kb

    El más rápido en cargar fué el primero.

    También hicimos la siguiente prueba para comparar la relacion tiempo/peso.

    1- Un html de 200kb
    2- Un html con 800 kb
    3- Un html con 1,6 Mb

    El resultado fue que el 2º no cargo 4 veces mas lento que el 1º ni que el 3º cargara 8 veces más lento que el 1º o 4 veces más lento que el 2º sino en algo menos. Con lo que conluimos que una vez establecido el canal y gracias a las lineas de hoy en dia (supongo que esto influira al igual que otros factores) el tiempo no es proporcional al peso.

    Independientemente de esto también quiero decir que otro factor que puede influir en hacer uno o varios css es la cantidad de gente que tenga que tocarlos. Creo que no es lo mismo que sea sólo una persona que lo ha hecho y sabe donde esta todo a una persona que no lo ha visto nunca y tiene que enfrentarse a ello. En este caso el tenerlo lo más fácil posible facilita el trabajo y si el tiempo de desarrollo es muy importante pues un factor más a tener en cuenta para decidirse por una opción u otra.

  • Buenas noches

    Te sigo desde hace algun tiempo, aunque creo que no habia comentado anteriormente.

    Aprovecho que publicas este post, y te planteo unas dudas, con respecto a CSS que me se plantean.

    Que es mejor, usar propiedades generales, o mas concretas?
    Me explico, que es mejor, usar:

    background: url(../img/background.png) 0 0 repeat-x #FFFFFF;

    O usar:

    background-image: url(../img/background.png);
    background-position: 0 0;
    background-repeat: repeat-x;
    background-color: #FFFFFF;

    ?

    Y relacionado con esto, en cuanto a los colores, es mejor usar #FFFFFF o #FFF ?

    Y que es mejor, usar

    @import "file1.css";

    O usar:

    link rel="stylesheet" href="style.css" type="text/css" media="screen"

    ?

  • supuestamente, mientras menos caracteres tenga la hoja de estilos, mas liviano el archivo css, por lo tanto conviene escribir las propiedades resumidas, es decir, para el ejemplo del post anterior conviene usar
    background: url(../img/background.png) 0 0 repeat-x #FFFFFF;

    En cuanto a la cantidad de archivos css, personalmente uso 2, uno con toda la estructura, fuentes y colores, separado por secciones y ordenado por tags html, divs y clases (screen.css), y otro con los estilos para imprimir la pagina (print.css).

  • Adhiero a la consulta de Laegnur.

    Sé que usar sentencias abreviadas reduce el peso del archivo resultante, y de esta forma se reduce el tiempo de descarga. Pero, será por maña o por costumbre, prefiero utilizar las sentencias completas, ya que la lectura me resulta mucho más simple y noto más ordenado el CSS.

    De todas formas es obvio que en sitios con CSS demasiado extensos o con alto tráfico, cada byte cuenta, y probablemente lo mejor sería usar sentencias abreviadas.

    ¿Qué opinan sobre esto?

  • @Darklords: Muy interesante, ha quedado realmente claro que lo pesado es abrir la conexión. Después ya las líneas hacen su trabajo.

    El problema que nos podemos encontrar es que haya países en los no haya una conexión rápida y entonces si que sería mejor reducir al máximo el peso para evitar hacerles sufrir esa odiada larga espera.
    @Laegnur: Pues a ver, vayamos por partes 😀

    1) Es mejor minimizar el espacio ocupado para el CSS. Osea que dejarlo todo en una línea por norma general es la mejor forma. Luego dependerá de la claridad que se le quiera dar al código para trabajar con él.

    2) Los colores, pasa exactamente lo mismo. Personalmente usaría la nomenclatura corta, pero es por no escribir más de lo necesario.

    3) Pues nunca he hecho pruebas al respecto, pero a simple vista debería ser más óptimo usar <link /> ya que simplemente enlaza el fichero CSS y posteriormente crea el contexto necesario para ejecutar el código que haya dentro.

    En el otro caso, deberá crear el contexto para luego interpretar el @import y cargar el fichero, que posteriormente creará (o reaprovechará) el contexto CSS necesario para comprender el código.

    ¿Quizás deberíamos hacer unas pruebas?
    @Luciano Nicolás: Obviamente la claridad es muy superior, además es más sencillo después modificar cualquier atributo ya que los tienes todos estos atributos desplegados y ordenados.

    Yo generalmente uso una sola línea, pero soy consciente de que para equipos de desarrollo donde varios meten mano no es quizás la mejor opción.

    Bueno, yo no lo había dicho, pero generalmente uso 3 ficheros 😛

    style.css: Con todo lo que necesita la aplicación para verse perfectamente. Aquí intento definir la estructura primero y poco a poco voy concretando más dentro de cada sección. Como guión intento seguir el que he dejado en el HTML.
    print.css: Aquí defino la plantilla de impresión. Generalmente oculto cosas y meto separaciones más claras, al ir detrás de la primera CSS este fichero suele tener unas pocas líneas.
    IE.js: Usando condicionales CSS añado una CSS más para navegadores IE y allí añado los hacks necesarios para que no se descuajaringue todo 😀

  • @Darklords sólo le veo un pero al buen ejemplo que has puesto, y es el de la caché. Si incluímos el css en cada fichero html generado este css se cargará una y otra vez sin tener en cuenta la caché, por el contrario cuando tú cargas mediante un link ese fichero queda en caché así que sólo tendríamos que cargarlo la primera página que visitemos con lo que a nivel global el rendimiento sería mucho mejor con el css cargado desde un fichero que desde el propio html.

    No sé que opinais acerca de esto 😀 Saludos

  • Nuevo en los comentarios pero todo un veterano en RSS, este blog me ha servido de mucha ayuda, y para hacer mas grande el tema. creo que con 3 CSS estaria bien.

    – estructura y formato
    – impresion
    – reseto

    Pero vamos que soy novato en el CSS, como opcion para meter 4 css el ultimo seria un archivo de hack para el intento de navegador llamado IE, aunque tambien si el proyecto es muy extenso, separaria estructura de formato, gracias por estos post, realmente son de mucha ayuda.

    Saludos desde Puebla, Mexico.

  • Aún al día de hoy sigo usando dos ficheros css: el de reseteo y el de estilos, a veces un tercero para IE (%$&*·$). Jamas habia hecho uno para la impresión, pero después de leer los comentarios, quizás deba cambiar un poco mis hábitos…

    Ah, Andrés, tampoco he dejado todo en una sola línea, seguro tiene sus beneficios, pero como siempre estoy modificando algo, creo que me volvería loco 😀 aún si se tratase de mantener uno bien claro y después guardarlo, como otro fichero, en una sola linea.

    Saludos… desde Río Grande, Tierra del Fuego, Argentina (habia que meter el chivo xD)

    Luxiano…

Comentar

#

Me reservo el derecho de eliminar y/o modificar los comentarios que contengan lenguaje inapropiado, spam u otras conductas no apropiadas en una comunidad civilizada. Si tu comentario no aparece, puede ser que akismet lo haya capturado, cada día lo reviso y lo coloco en su lugar. Siento las molestias.