10 enero 2007

Una de las cuestiones que, he observado, menos respuestas ha obtenido cuando cuando en algún foro se ha preguntado, es la que tiene que ver con la organización de las hojas de estilo dentro de un proyecto de desarrollo web.

No es que sea cosa baladí, ni mucho menos, pero sí es cierto que si no estamos ante un proyecto de determinado volumen, estrujarse el cerebro para montar algo así como un framework CSS no es de mucha utilidad, a poca experiencia que tengamos en el uso y manejo de esta tecnología. De todos modos, puedo decir por la experiencia de trabajo que tengo, que cuando nos encontramos ante un proyecto de cierta envergadura, contar con un entorno controlado de CSS es una herramienta mucho más que útil. Casi diría que es vital.

Voy a tratar de desarrollar en este post una serie de ideas que tengo dispersas en mi cabeza, ordenarlas, y tratar de arrojar algo de luz en el tema de la organización y sistematización de las hojas de estilo cuando nos encontramos ante un proyecto de alcance medio-alto.

Los inicios

Cuando inciamos un proyecto, lo más habitual suele ser que empecemos por planificar las hojas de estilo en función de los elementos que nos vamos a encontrar, siguiendo la norma de dotar de estructura a la pantalla, y posteriormente dotar de un nivel de presentación a los elementos que hay en cada pantalla.

De ese modo, lo más habitual es que empecemos a escribir en el documento CSS todo lo necesario para posicionar la rejilla o layout de la pantalla. Así, situamos la cabecera, la navegación, la zona de contenidos, el pie de página, etc.

Luego vamos ajustando, si es que nos preocupamos de ello, los selectores para que todo se vea igual en los diferentes navegadores. Si es necesario hacemos uso de algún hack o, en el mejor de los casos, planteamos el uso de comentarios condicionales para discriminar, en el mejor sentido de la palabra, las reglas que usamos en función del navegador.

Hasta aquí las cosas se pueden desarrollar con cierto orden y podemos decir que tenemos la sensación de que controlamos el desarrollo del trabajo. En función de nuestra pericia a la hora de transformar lo que vemos en un psd en un set de HTML y CSS, llegamos a dominar la situación sin excesivos problemas que, como ya he dicho, controlamos gracias al uso de algún que otro hack, o a través de comentarios condicionales.

En cualquier caso, lo importante de esta fase es que, por norma general, las reglas CSS vienen determinadas por los elementos de la pantalla que nos vamos encontrando a la hora de maquetar o escribir el código.

El desarrollo y crecimiento

Una vez que hemos iniciado el proceso de trabajo, y ya tenemos una cierta base sobre la que desarrollar la codificación HTML+CSS, los elementos que nos vamos encontrando para dar la capa de presentación, van creciendo, y en función de la variabilidad de los mismos, vamos viéndonos en la obligación de diversificar las reglas CSS para dar solución a todas y cada una de las situaciones concretas que tenemos ante nosotros.

Digamos que podemos entender la situación como controlable en el momento en que la variabilidad de los elementos a los que tenemos que dotar de diseño a través de CSS no crece demasiado. Y estoy hablando, ahora, sólamente de los elementos que tenemos en un mismo tipo de pantalla; es decir, elementos que aparecen en una o varias pantallas que tienen un mismo esquema.

Pero, ¿qué sucede cuando nos encontramos con elementos que creíamos similares, o iguales, y que cuando nos ponemos a aplicarles reglas que ya tenemos hechas, éstas no nos terminan de servir porque hay ligeras diferencias? Es entonces cuando se inicia la ruleta rusa de la multiplicación de reglas CSS muy parecidas. Y es el inicio de nuestra perdición 🙂

El problema

La cuestión es que en ese punto del desarrollo del trabajo nos podemos encontrar, y de hecho es lo más normal, con que la multiplicidad de opciones y elementos, sumado a la variabilidad de los mismos, y junto con las excepciones que tenemos que contemplar para que la visualización sea óptima en varios navegadores, hace que haya muchas probabilidades de que nos encontremos con un crecimiento sustancial tanto de las reglas como, lógicamente, del tamaño de la hoja de estilos. Esto nos traerá la espantosa consecuencia de la bajada escandalosa en el nivel de “manejabilidad” de la hoja de estilos.

La facilidad en el manejo y edición del fichero CSS es una de las piezas clave en el éxito de la agilidad de desarrollo. Por lo tanto, controlarla será uno de los objetivos que tendremos que perseguir. Y para ello nada mejor que contar con una planificación de la hoja de estilos, previa al desarrollo.

Algunas soluciones

Lo primero que se me ocurre que hay que tener en cuenta es una serie de puntos a controlar para que podamos construirnos un entorno de trabajo CSS que nos permita manejar y gestionar lo más posible todas las reglas a escrbir. Para ello se me ocurre que hagamos el ejercicio de responder a unas preguntas previas:

  • ¿Conocemos el mapa de la web que vamos a codificar?
  • ¿Conocemos el contenido real que va a tener el sitio web?
  • ¿Tenemos la posibilidad de contar con contenidos reales del sitio web?
  • ¿Existe un libro de estilo previo que describa los elementos que aparecerán en el sitio web?
  • ¿Conocemos la estructura modular del desarrollo previsto para el sitio web?

Si tenemos una respuesta afirmativa a todas esas cuestiones, tendremos el camino muy fácil para poder componer nuestro entorno CSS planificado con anterioridad. Y si no lo tenemos, no nos quedará más remedio que hacer un ejercicio de imaginación racional para tratar de dar una respuesta lo más consecuente posible.

De ese modo, podremos componer una serie de reglas predefinidas, sin valores de aributos, que observemos que se repiten y son de uso frecuente.

Lógicamente cuantos más proyectos abordemos con esta metodología, más ajustaremos el entorno CSS y la velocidad de trabajo aumentará sin que se resienta la calidad del resultado final.

De todos modos, y como un modestísimo consejo de uso, podemos empezar por trazar unas líneas de trabajo básicas para diseñar un framework CSS que nos sea de utilidad:

  1. Establezcamos un modelo de layout que contemple las siguientes características:
    • Que sea flexible
    • Que contemple al menos 3 columnas de organización de contenidos
    • Que las columnas laterales sean intercambiables en su posición (derecha-izquierda) tan sólo cambiando los atributos de posición de las mismas
    • Que contemple:
      • Cabecera
      • Navegación global
      • Navegación local
      • Contenido
      • Zona de información relacionada y/o complementaria
      • Pie de página
  2. Establezcamos una serie de rejillas de disposición de contenidos:
      • Rejilla en columnas fijas
      • Rejilla en columnas flexibles
      • Rejilla en columnas fijas y flexibles
      1. Establezcamos una serie de patrones de diseño codificados:
        • Logotipo con texto asociado
        • Login
        • Menú horizontal
        • Menú vertical
        • Párrafo de texto
        • Párrafo de texto con imágen y pie de foto
        • Listado simple vertical
        • Listado simple vertical en varias columnas
        • Serie de imágenes a modo de galería
        • Tabla de datos

      Con la definición de reglas para todos estos elementos podemos considerar que tenemos una serie de elementos más que resueltos, de tal modo que “sólo” nos quede pendiente asignar los valores de los atributos que las definan en cada proyecto.

      Lógicamente esto es sólo un punto de partida, pero a medida que avancemos en el desarrollo del proyecto iremos definiendo las variaciones que de cada uno de estos elementos necesitemos.

      Pero claro, con esto no está todo dicho. Ahora tenemos que considerar que las reglas ya definidas, o más bien predefinidas, pueden aparecer en diversas zonas o secciones del sitio web. Y es muy deseable que tengamos presente que los atributos asignados a cada una puedan variar en función del módulo o sección en la que se deban aplicar.

      Por ello lo que propongo es que hagamos un ejercicio de dispersión de las reglas CSS en función de los módulos en los que podamos seccionar el sitio web. Así las cosas no deberíamos tener complejos, y diseñar una serie de ficheros CSS específicos para cada sección del sitio web, adaptando las reglas a definir en cada uno de ellos, de tal modo que cuando estemos en faena, es decir, asignando atributos a las reglas, tengamos la libertad de elección suficiente como para que los atributos que usemos para una sección no interfieran cuando los usemos en otra.

      Lógicamente, deberemos hacer un cuidado trabajo de nomenclatura en las reglas, de tal modo que éstas tengan una serie de propiedades:

      • Que tengan un marcado carácter semántico
      • Que sean únicas
      • Que su nomenclatura permita relacionarlas entre sí
      • Que sean cortas (tengan el mínimo de caracteres posible)
      • Que sean universales, es decir, que sirvan para todos los proyectos

      Del tema semántico en las reglas CSS hablaré en el siguiente post de esta mini-serie.

        Comentarios

        1. Daniel, buenísimo el tema que vas a tratar en esta serie de posts.

          Solo dar un par de apuntes.

          Jugar con el id y las clases en el body, siempre, será una gran factor determinate para aplicar los diferentes estilos que comentas.

          Voy a decir una perogrullada, pero hacer esto y medianamente bien al principio del proyecto será de gran ayuda para el que lo hace y para el que venga detrás a tocar. Yo he intentado hacer algo parecido en un proyecto grande, ya con tiempo corriendo, e intentar rehacerlo todo puede llegar a ser una pesadilla y una tarea imposible por muchas variables.

          Espero el siguiente con impaciencia 😉

        2. Excelente síntesis de los problemas que se producen en torno a las horas de estilo en proyectos medios o grandes.

          Me parece muy acertada la aproximación de hacer un framework y sobre todo el partir de ciertos patrones de diseño que serán los que luego presentemos especificando sus CSS.

          Y no puedo estar más de acuerdo con la técnica de usar ficheros CSS específicos para secciones o tipos de páginas. Esto facilita muchísimo el mantenimiento posterior del proyecto y además podemos sobreescribir las reglas generales con reglas específicas que solventen problemas de una determinada página o sección.

          Sobre las preguntas previas… el problema suele estar siempre en la falta de conocimiento sobre los contenidos reales y en mi caso que exista un libro de estilo es una quimera.

          Espero con impaciencia la segunda parte!

        3. Sensacional, es un placer ver la claridad con la que expones los contenidos en el articulo.

          Mas, por favor!

        4. Muy bueno.
          A veces el cliente ni sospecha los contenidos !

        5. Es estupendo como sintetizas los problemas con los que hay que enfrentarse y encima aportas las soluciones.

          Ahora mi pregunta ¿usáis alguna plantilla tipo como de la que habla Daniel (cabecera, 3 columnas…)? o por el contrario os enfrentáis a cada diseño, creo que en alguna lista lo planteo alguien de Simplelógica, pero con mi memoria nula no recuerdo como terminó la conversación.

        6. Muy interesante el artículo y muy prometedores los siguientes ;D.

          Tan sólo apuntar lo interesante que puede llegar a ser aplicar, en la hoja de estilos principal, ciertas reglas para normalizar el aspecto de los elementos típicos (h, p, ul,…) entre diferentes navegadores. Es un engorro ver como, por ejemplo, la etiqueta , con los estilos por defecto, tiene comportamientos muy diferentes entre navegadores.

          Para ello, un copy & paste de ciertas reglas para normalizar los estilos nunca está de más. En su día me apunte estas reglas y las tengo en SNIPPLR:

          http://snipplr.com/view/516/normalizar-css-tantek-celik–equiparar-ems-y-pxs/

          Saludos y felicidades por el artículo!!!

          Sendoa Portuondo

          Sendoa Portuondo 12 enero 2007, 9:34
        7. […] quienes siguen fielmente este weblog, es que se que tengo pendiente la segunda parte de la serie Frameworks CSS. No me olvido de […]

        8. En Neurotic usamos una “guía de estilo” para el CSS y de esta manera tenemos una base común con los elementos que acostumbramos a usar.

          También me gusta ordenar los atributos según su “poder de modificación” del elemento para ver de un vistaz la definición de un atributo.

          Sobre lo de dividir los estilos en diferentes hojas hemos usado varias técnicas… una vez para un proyecto muy grande el cliente nos pidió separar las hojas según atributos: los que modificaban el layout en un CSS, los que modificaban los colores en otro y uno con el resto (texto, bordes…)

          La experiencia no fue muy positiva ya que se hace muy pesado sobretodo cuando creas un estilo ya que tienes que crear los identificadores en las tres hojas, poner cada atributo en la hoja correspondiente y subir las diferentes hojas así que al final lo que haces es crear un estilo en cualquiera de las tres hojas y cuando crees que has acabado con él pasar cada atributo a cada hoja.

          Para hacer cambios sí que va bien (sobretodo si es algo tan sencillo como cambiar el color de un elemento) pero como tengas que cambiar varias cosas estamos en lo mismo.

          Otro sistema que hemos probado es dividir los elementos según donde van a aparecer (tablas.css, formularios.css, foros.css) pero al final siempre encuentras elementos que aparecen en distintos sitios y tienes que ponerlo en una hoja general.

          El problema viene cuando quieres cambiar uno de estos elementos ya que al final no sabes si buscarlo en la hoja de estilos de formularios, la de tablas, la de foros o la general con lo que vuelves a perder el tiempo.

          Espero la continuación de tu tema ya que estaría bien ver una forma más o menos útil de clasificar los CSS que te permita estar más tiempo codificando que organizando.

          Un saludo,

          Jordi Bufí Caballero – Neurotic

        9. […] Combatir procrastinación / El Canasto. “El hábito de posponer tareas hasta el último minuto, puede ser un problema grave en tu carera profesional y vida personal. Oportunidades perdidas, horas extra de trabajo, estrés, resentimiento y culpabilidad son solo algunos de los síntomas”. Un artículo para tratar de evitar caer en los hábitos de la procrastinación. Blueprint, un CSS Framework / Olav Frihagen Bjørkøy. Un framework para hojas de estilo ha sido desarrollado, en Subtraction hacen una entrevista al creador Olav y en Game Makker hacen un pequeño tutorial de como poder usarlo. Me gusta por estar basado en conceptos de retícula y tipografía, como se puede ver en la imagen. Recordé que Daniel Torres Burriel ya había hablado de algunos puntos para diseñar un Framework CSS. […]

        En Torresburriel Estudio desarrollamos las capacidades técnicas de tu equipo en temas de usabilidad, experiencia de usuario y diseño de producto a través de nuestros cursos online y presenciales.