Gestionar la Explosión CSS

He estado confiando mucho en CSS para un sitio web en el que estoy trabajando. En este momento, todos los estilos CSS se están aplicando por etiqueta, por lo que ahora estoy tratando de moverlo a un estilo más externo para ayudar con cualquier cambio futuro.

Pero ahora el problema es que he notado que recibo una "Explosión CSS". Me resulta difícil decidir cómo organizar mejor y resumir datos dentro del archivo CSS.

Estoy usando una gran cantidad de divetiquetas dentro del sitio web, pasando de un sitio web basado en tablas. Así que obtengo muchos selectores CSS que se ven así:

div.title {
  background-color: blue;
  color: white;
  text-align: center;
}

div.footer {
  /* Styles Here */
}

div.body {
  /* Styles Here */
}

/* And many more */

Todavía no está tan mal, pero como soy un principiante, me preguntaba si se podrían hacer recomendaciones sobre la mejor manera de organizar las diversas partes de un archivo CSS. No quiero tener un atributo CSS separado para cada elemento en mi sitio web, y siempre quiero que el archivo CSS sea bastante intuitivo y fácil de leer.

Mi objetivo final es facilitar el uso de los archivos CSS y demostrar su poder para aumentar la velocidad del desarrollo web. De esta manera, otras personas que puedan trabajar en este sitio en el futuro también se acostumbrarán a usar buenas prácticas de codificación, en lugar de tener que aprenderlo como yo lo hice.

Esta es una muy buena pregunta. Dondequiera que miro, los archivos CSS tienden a perder el control después de un tiempo, especialmente, pero no solo, cuando se trabaja en equipo.

Las siguientes son las reglas a las que estoy tratando de cumplir (no es que siempre me las arreglo).

• Refactorizar temprano, refactorizar a menudo. Limpie con frecuencia los archivos CSS, fusione varias definiciones de la misma clase. Eliminar definiciones obsoletas de inmediato .

• Al agregar CSS durante la corrección de errores, deje un comentario sobre lo que hace el cambio ("Esto es para asegurarse de que el cuadro quede alineado en IE <7")

• Evite las redundancias, por ejemplo, definir lo mismo en .classnamey .classname:hover.

• Use comentarios /** Head **/para construir una estructura clara.

• Use una herramienta de prettifier que ayuda a mantener un estilo constante. Uso Polystyle , con lo que estoy bastante contento (cuesta $ 15 pero es dinero bien gastado). También hay otros gratuitos (por ejemplo, Code Beautifier basado en CSS Tidy , una herramienta de código abierto).

• Construye clases sensatas. Vea a continuación algunas notas sobre esto.

• Use semántica, evite la sopa DIV; use <ul>s para menús, por ejemplo.

• Defina todo en el nivel más bajo posible (por ejemplo, una familia de fuentes, color y tamaño predeterminados en el body) y utilícelo inheritsiempre que sea posible

• Si tiene CSS muy complejo, tal vez un precompilador CSS ayude. Estoy planeando investigar xCSS por la misma razón pronto. Hay varios otros alrededor.

• Si trabaja en equipo, resalte la necesidad de calidad y estándares para los archivos CSS también. Todos son grandes en los estándares de codificación en sus lenguajes de programación, pero hay poca conciencia de que esto también es necesario para CSS.

• Al trabajar en un equipo, no considerar el uso de control de versiones. Hace que las cosas sean mucho más fáciles de rastrear, y la edición de conflictos es mucho más fácil de resolver. Realmente vale la pena, incluso si eres "justo" en HTML y CSS.

• No trabajes con !important. No solo porque IE = <7 no puede manejarlo. En una estructura compleja, el uso de a !importantmenudo es tentador para cambiar un comportamiento cuya fuente no se puede encontrar, pero es un veneno para el mantenimiento a largo plazo.

Construyendo clases sensatas

Así es como me gusta construir clases sensatas.

Aplico primero la configuración global:

body { font-family: .... font-size ... color ... }
a { text-decoration: none; }

Luego, identifico las secciones principales del diseño de la página, por ejemplo, el área superior, el menú, el contenido y el pie de página. Si escribí un buen marcado, estas áreas serán idénticas a la estructura HTML.

Luego, comienzo a construir clases CSS, especificando la mayor cantidad de ascendencia posible, siempre que sea razonable, y agrupando las clases relacionadas lo más cerca posible.

div.content ul.table_of_contents 
div.content ul.table_of_contents li 
div.content ul.table_of_contents li h1
div.content ul.table_of_contents li h2
div.content ul.table_of_contents li span.pagenumber

Piense en toda la estructura CSS como un árbol con definiciones cada vez más específicas cuanto más lejos esté de la raíz. Desea mantener el número de clases lo más bajo posible y desea repetirse tan pocas veces como sea posible.

Por ejemplo, supongamos que tiene tres niveles de menús de navegación. Estos tres menús se ven diferentes, pero también comparten ciertas características. Por ejemplo, son todos <ul>, tienen el mismo tamaño de fuente y los elementos están uno al lado del otro (en oposición a la representación predeterminada de un ul). Además, ninguno de los menús tiene viñetas ( list-style-type).

Primero, defina las características comunes en una clase llamada menu:

div.navi ul.menu { display: ...; list-style-type: none; list-style-image: none; }
div.navi ul.menu li { float: left }

luego, defina las características específicas de cada uno de los tres menús. El nivel 1 tiene 40 píxeles de altura; niveles 2 y 3, 20 píxeles.

Nota: también puede usar varias clases para esto, pero Internet Explorer 6 tiene problemas con varias clases , por lo que este ejemplo usa ids.

div.navi ul.menu#level1 { height: 40px; }
div.navi ul.menu#level2 { height: 20px; }
div.navi ul.menu#level3 { height: 16px; }

El marcado del menú se verá así:

<ul id="level1" class="menu"><li> ...... </li></ul>
<ul id="level2" class="menu"><li> ...... </li></ul>
<ul id="level3" class="menu"><li> ...... </li></ul>

Si tiene elementos semánticamente similares en la página, como estos tres menús, primero trate de resolver los puntos en común y colóquelos en una clase; luego, calcule las propiedades específicas y aplíquelas a las clases o, si tiene que admitir Internet Explorer 6, los ID.

Consejos HTML diversos

Si agrega estas semánticas a su salida HTML, los diseñadores pueden personalizar el aspecto de los sitios web y / o aplicaciones utilizando CSS puro, lo cual es una gran ventaja y un ahorro de tiempo.

• Si es posible, asigne una clase única al cuerpo de cada página: <body class='contactpage'>esto hace que sea muy fácil agregar ajustes específicos de la página a la hoja de estilo:

  body.contactpage div.container ul.mainmenu li { color: green }

• Al crear menús automáticamente, agregue la mayor cantidad de contexto CSS posible para permitir un estilo extenso más adelante. Por ejemplo:

  <ul class="mainmenu">
   <li class="item_first item_active item_1"> First item </li> 
   <li class="item_2"> Second item </li> 
   <li class="item_3"> Third item </li> 
   <li class="item_last item_4"> Fourth item </li> 
  </ul>

  De esta forma, se puede acceder a cada elemento del menú para diseñar de acuerdo con su contexto semántico: ya sea el primer o el último elemento de la lista; Si es el elemento actualmente activo; y por numero.

Tenga en cuenta que esta asignación de múltiples clases como se describe en el ejemplo anterior no funciona correctamente en IE6 . Hay una solución alternativa para que IE6 pueda manejar múltiples clases. Si la solución alternativa no es una opción, deberá establecer la clase que sea más importante para usted (número de artículo, activo o primero / último), o recurrir al uso de ID.

Aquí hay solo 4 ejemplos:

• Convenciones CSS / Modelos de diseño de código
• ¿Hay algún estándar CSS que deba seguir al escribir mi primera hoja de estilo?
• ¿Cuál es el mejor método para ordenar CSS?
• Mejores prácticas: formato de hoja de estilo CSS

En los 4 mi respuesta ha incluido el consejo de descargar y leer los sistemas CSS CSS de Natalie Downe . (El PDF incluye toneladas de notas que no están en las diapositivas, ¡así que lea el PDF!). Tome nota de sus sugerencias para la organización.

EDIT (05/02/2014) cuatro años después, diría:

• Use un preprocesador CSS y administre sus archivos como parciales (personalmente prefiero Sass con Compass, pero Less también es bastante bueno y hay otros)
• Lea sobre conceptos como OOCSS , SMACSS y BEM o getbem .
• Eche un vistazo a cómo se estructuran los marcos CSS populares como Bootstrap y Zurb Foundation . Y no descarte los marcos menos populares: los inuit son interesantes, pero hay muchos otros.
• Combine / minimice sus archivos con un paso de compilación en un servidor de integración continua y / o un corredor de tareas como Grunt o Gulp.

No escriba encabezados en CSS

Solo divide las secciones en archivos. Cualquier comentario CSS, debería ser solo eso, comentarios.

reset.css
base.css
somepage.css
someotherpage.css
some_abstract_component.css

Use un guión para combinarlos en uno; si necesario. Incluso puede tener una buena estructura de directorios, y simplemente hacer que su script escanee de forma recursiva en busca de .cssarchivos.

Si debe escribir encabezados, tenga una tabla de contenido al comienzo del archivo

Los encabezados en la tabla de contenido deben ser perfectamente iguales a los encabezados que escriba más adelante. Es un dolor buscar encabezados. Para agregar al problema, ¿cómo exactamente se supone que alguien sabe que tiene otro encabezado después de su primer encabezado? PD. no agregue doc-like * (estrella) al comienzo de cada línea cuando escriba TOC, solo hace que sea más molesto seleccionar el texto.

/* Table of Contents
   - - - - - - - - -
   Header stuff
   Body Stuff
   Some other junk
   - - - - - - - - -
 */
...
/* Header Stuff 
 */
...
/* Body Stuff 
 */

Escriba comentarios con o dentro de las reglas, no fuera del bloque

En primer lugar, cuando edita el script hay una posibilidad de 50/50 de que preste atención a lo que está fuera del bloque de reglas (particularmente si es una gran cantidad de texto;)). En segundo lugar, no hay (casi) ningún caso en el que necesite un "comentario" afuera. Si está afuera, es el 99% del tiempo un título, así que manténgalo así.

Dividir la página en componentes.

Los componentes deberían tener position:relative, no paddingy no margin, la mayor parte del tiempo. Esto simplifica% gobierna mucho, así como lo que permite mucho más simple absolute:position'ing de elementos, ya que si hay un recipiente posicionado absoluto el elemento posicionado absoluto utilizará el contenedor cuando se calcula top, right, bottom, leftpropiedades.

La mayoría de los DIV en un documento HTML5 suelen ser un componente.

Un componente también es algo que puede considerarse una unidad independiente en la página. En términos simples, tratar algo como un componente si tiene sentido tratar algo como una caja negra .

Yendo con el ejemplo de la página QA nuevamente:

#navigation
#question
#answers
#answers .answer
etc.

Al dividir la página en componentes, divide su trabajo en unidades manejables.

Ponga reglas con un efecto acumulativo en la misma línea.

Por ejemplo border, marginy padding(pero no outline) todos se suman a las dimensiones y el tamaño del elemento que está diseñando.

position: absolute; top: 10px; right: 10px;

Si simplemente no son tan legibles en una línea, al menos colóquelos cerca:

padding: 10px; margin: 20px;
border: 1px solid black;

Use la taquigrafía cuando sea posible:

/* the following... */
padding-left: 10px;
padding-right: 10px;
/* can simply be written as */
padding: 0 10px;

Nunca repitas un selector

Si tiene más instancias del mismo selector, hay una buena posibilidad de que inevitablemente termine con varias instancias de las mismas reglas. Por ejemplo:

#some .selector {
    margin: 0;
    font-size: 11px;
}
...
#some .selector {
    border: 1px solid #000;
    margin: 0;
}

Evite usar TAG como selectores, cuando puede usar id / classes

En primer lugar, las etiquetas DIV y SPAN son la excepción: ¡nunca debe usarlas, nunca! ;) Úselos solo para adjuntar una clase / id.

Esta...

div#answers div.answer table.statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
div#answers div.answer table.statistics thead {
    outline: 3px solid #000;
}

Debería escribirse así:

#answers .answer .statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

Debido a que los DIV colgantes adicionales no agregan nada al selector. También fuerzan una regla de etiqueta innecesaria. Si tuviera que cambiar, por ejemplo, .answerde a diva a, articlesu estilo se rompería.

O si prefieres más claridad:

#answers .answer .statistics {
    color: pink;
    border: 1px solid #000;
}
#answers .answer table.statistics {
    border-collapse: collapsed;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

La razón es que la border-collapsepropiedad es una propiedad especial que solo tiene sentido cuando se aplica a a table. Si .statisticsno es un, tableno debería aplicarse.

¡Las reglas genéricas son malas!

• evite escribir reglas genéricas / mágicas si puede
• a menos que sea para un reinicio / reinicio de CSS, toda su magia genérica debe aplicarse al menos a un componente raíz

No te ahorran tiempo, hacen explotar tu cabeza; así como hacer que el mantenimiento sea una pesadilla. Cuando esté escribiendo la regla, es posible que sepa dónde se aplican, sin embargo, eso no garantiza que su regla no lo moleste más adelante.

Para agregar a esto, las reglas genéricas son confusas y difíciles de leer, incluso si tiene alguna idea del documento que está diseñando. Esto no quiere decir que no deba escribir reglas genéricas, simplemente no las use a menos que realmente tenga la intención de que sean genéricas, e incluso que agreguen tanta información de alcance en el selector como sea posible.

Cosas como esta...

.badges {
    width: 100%;
    white-space: nowrap;
}

address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

... tiene el mismo problema que usar variables globales en un lenguaje de programación. ¡Tienes que darles alcance!

#question .userinfo .badges {
    width: 100%;
    white-space: nowrap;
}

#answers .answer .userinfo address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

Básicamente eso se lee como:

components                   target
---------------------------- --------
#answers .answer   .userinfo address
-------- --------- --------- --------
domain   component component selector 

Me gusta usar ID cuando un componente que conozco es un singleton en una página; Sus necesidades pueden ser diferentes.

Nota: Idealmente, debería escribir lo suficiente. Sin embargo, mencionar más componentes en el selector es el error más indulgente, en comparación con mencionar menos componentes.

Supongamos que tiene un paginationcomponente. Lo usas en muchos lugares de tu sitio. Este sería un buen ejemplo de cuándo escribiría una regla genérica. Digamos display:blocklos enlaces de los números de página individuales y proporcione un fondo gris oscuro. Para que sean visibles, debes tener reglas como esta:

.pagination .pagelist a {
    color: #fff;
}

Ahora digamos que usa su paginación para una lista de respuestas, puede encontrar algo como esto

#answers .header a {
    color: #000;
}
...
.pagination .pagelist a {
    color: #fff;
}

Esto hará que tus enlaces blancos sean negros, lo que no quieres.

La forma incorrecta de solucionarlo es:

.pagination .pagelist a {
    color: #fff !important;
}

La forma correcta de solucionarlo es:

#answers .header .pagination .pagelist a {
    color: #fff;
}

Los comentarios "lógicos" complejos no funcionan :)

Si escribe algo como: "este valor depende de bla-bla combinado con la altura de bla-bla", es inevitable que cometa un error y todo se caerá como un castillo de naipes.

Mantenga sus comentarios simples; si necesita "operaciones lógicas", considere uno de esos lenguajes de plantillas CSS como SASS o LESS .

¿Cómo se escribe una paleta de colores?

Deja esto para el final. Tenga un archivo para toda su paleta de colores. Sin este archivo, su estilo aún debería tener una paleta de colores utilizable en las reglas. Su paleta de colores debe sobrescribir. Encadena selectores utilizando un componente principal de muy alto nivel (p. Ej. #page) Y luego escribe su estilo como un bloque de reglas autosuficiente. Puede ser solo color o algo más.

p.ej.

#page #header .description,
#page #categories .description,
#page #answers .answer .body
{
    color: #222; background: #fff; 
    border-radius: 10px;
    padding: 1em;
}

La idea es simple, su paleta de colores es una hoja de estilo independiente del estilo base, en el que se conecta en cascada .

Menos nombres, requiere menos memoria, lo que hace que el código sea más fácil de leer

Usar menos nombres es mejor. Idealmente use palabras muy simples (¡y cortas!): Texto, cuerpo, encabezado.

También encuentro que la combinación de palabras simples es más fácil de entender que tener una sopa de palabras largas "apropiadas": postbody, posthead, userinfo, etc.

Mantenga el vocabulario pequeño, de esta manera, incluso si algún extraño que viene a leer su sopa de estilo (como usted después de algunas semanas;)) solo necesita entender dónde se usan las palabras en lugar de donde se usa cada selector. Por ejemplo, lo uso .thissiempre que un elemento supuestamente sea "el elemento seleccionado" o "el elemento actual", etc.

Limpia después de ti

Escribir CSS es como comer, a veces dejas un desastre. Asegúrate de limpiar ese desastre, o el código de basura simplemente se acumulará. Elimina las clases / identificadores que no uses. Elimina las reglas CSS que no uses. Asegúrese de que todo esté bien y que no tenga reglas en conflicto o duplicadas.

Si, como sugerí, trató algunos contenedores como cajas negras (componentes) en su estilo, usó esos componentes en sus selectores y guardó todo en un archivo dedicado (o dividió adecuadamente un archivo con un TOC y encabezados), entonces su el trabajo es sustancialmente más fácil ...

Puede usar una herramienta como la extensión Dust-Me Selectores de firefox (consejo: apúntelo a su sitemap.xml) para ayudarlo a encontrar parte de la basura oculta en sus armas nucleares y carnies css.

Mantener un unsorted.cssarchivo

Supongamos que está diseñando un sitio de control de calidad y que ya tiene una hoja de estilo para la "página de respuestas", a la que llamaremos answers.css. Si ahora necesita agregar una gran cantidad de CSS nuevo, agréguelo a la unsorted.csshoja de estilo y luego refactorice en su answers.csshoja de estilo.

Varias razones para esto:

• es más rápido refactorizar una vez que haya terminado, luego es buscar reglas (que probablemente no existan) e inyectar código
• escribirás cosas que eliminarás, inyectar código solo hace que sea más difícil eliminar ese código
• agregar al archivo original conduce fácilmente a la duplicación de regla / selector

Echa un vistazo a 1. SASS 2. Brújula

La mejor manera que he visto para contrarrestar la CSShinchazón es utilizando los principios CSS orientados a objetos.

Incluso hay un marco OOCSS que es bastante bueno.

Algunas de las ideologías van en contra de mucho de lo que se ha dicho aquí en las respuestas principales, pero una vez que sepa cómo CSSdiseñar de manera orientada a objetos, verá que realmente funciona para mantener el código magro y malo.

La clave aquí es identificar 'Objetos' o patrones de bloques de construcción en su sitio y arquitecto con ellos.

Facebook contrató a la creadora de OOCSS, Nicole Sullivan para obtener muchos ahorros en su código front-end (HTML / CSS). Si en realidad se puede conseguir un ahorro no sólo en el CSS, pero en su HTML también, que por el sonido de la misma, es muy posible que usted como usted menciona la conversión de un tablediseño basado en un montón de div's

Otro gran enfoque es similar en algunos aspectos a OOCSS, es planificar y escribir su CSS para que sea escalable y modular desde el principio. Jonathan Snook ha realizado una excelente redacción y libro / libro electrónico sobre SMACSS - Arquitectura escalable y modular para CSS

Déjame conectarte con algunos enlaces:
5 errores de CSS masivo - (Video)
5 errores de CSS masivo - (Diapositivas)
Bloat CSS - (Diapositivas)

También debe comprender la cascada, el peso y cómo funcionan.

Noto que está utilizando solo identificadores de clase (div.title). ¿Sabía que también puede usar identificaciones y que una identificación tiene más peso que una clase?

Por ejemplo,

#page1 div.title, #page1 ul, #page1 span {
  // rules
}

hará que todos esos elementos compartan un tamaño de fuente, digamos, o un color, o cualesquiera que sean sus reglas. Incluso puede hacer que todas las DIV que son descendientes de # page1 obtengan ciertas reglas.

En cuanto al peso, recuerde que los ejes CSS se mueven del más general / más ligero al más específico / más pesado. Es decir, en un selector CSS, un especificador de elemento anula un especificador de clase y un especificador de ID anula. Los números cuentan, por lo que un selector con especificadores de dos elementos (ul li) tendrá más peso que uno con un solo especificador (li).

Piense en ello como dígitos. Un 9 en la columna de las unidades sigue siendo menor que uno en la columna de las decenas. Un selector con un especificador de ID, un especificador de clase y dos de elementos tendrá más peso que un selector sin ID, 500 de clase y 1.000 de elemento. Este es un ejemplo absurdo, por supuesto, pero entiendes la idea. El punto es que aplicar este concepto te ayuda a limpiar mucho CSS.

Por cierto, no es necesario agregar el especificador de elemento a la clase (div.title) a menos que tenga conflictos con otros elementos que tienen class = "title". No agregue peso innecesario, ya que puede necesitar usar ese peso más tarde.

¿Puedo sugerir menos marco dinámico CSS

Es similar a SASS como se mencionó anteriormente.

Ayuda a mantener CSS por clase principal.

P.ej

 #parent{     
  width: 100%;

    #child1
    {    
     background: #E1E8F2;    
     padding: 5px;    
    }

    #child2
   {
     background: #F1F8E2;
     padding: 15px
   }
 }

Lo que hace esto: aplica el ancho: 100% a # child1 y # child2.

Además, # child1 CSS específico pertenece a #parent.

Esto llevaría a

#parent #child1
{
 width: 100%;
 background: #E1E8F2;
 padding: 5px;
}

#parent #child2
{
 width: 100%;
 background: #F1F8E2;
 padding: 15px;
}

Creo que lo difícil es traducir el diseño requerido para un sitio en una serie de reglas. Si el diseño del sitio es claro y está basado en reglas, entonces los nombres de clase y la estructura CSS pueden fluir a partir de eso. Pero si las personas, con el tiempo, agregan aleatoriamente pequeños bits al sitio que no tienen mucho sentido, no hay mucho que pueda hacer al respecto en el CSS.

Tiendo a organizar mis archivos CSS más o menos así:

1. Restablecimiento de CSS, basado en Eric Meyer . (Porque de lo contrario, encuentro que, para la mayoría de los elementos, tengo al menos una o dos reglas que simplemente restablecen los estilos predeterminados del navegador; por ejemplo, la mayoría de mis listas no se parecen al estilo HTML predeterminado para las listas).

2. Sistema de rejilla CSS, si el sitio lo requiere. ( Baso el mío en 960.gs )

3. Estilos para componentes que aparecen en cada página (encabezados, pies de página, etc.)

4. Estilos para componentes que se utilizan en varios lugares del sitio.

5. Estilos que solo son relevantes en páginas individuales

Como puede ver, la mayor parte de eso depende del diseño del sitio. Si el diseño es claro y organizado, su CSS puede serlo. Si no, estás jodido.

Mi respuesta es de alto nivel para abordar las preocupaciones de alto nivel que ha planteado en su pregunta. Puede haber trucos y ajustes organizativos de bajo nivel que puede hacer para que sea más bonito, pero ninguno de ellos puede solucionar las deficiencias metodológicas. Hay varias cosas que afectan la explosión de CSS. Obviamente, la complejidad general del sitio, pero también cosas como la semántica de nombres, el rendimiento de CSS, la organización de archivos CSS y la capacidad de prueba / aceptabilidad.

Parece que está en el camino correcto con la semántica de nombres, pero puede ir un paso más allá. Las secciones de HTML que aparecen repetidamente en el sitio sin modificaciones estructurales (conocidas como "módulos") pueden considerarse raíces selectoras, y desde allí puede abarcar el diseño interno relativo a esa raíz. Este es el principio básico de CSS orientado a objetos , y puede leer / ver más sobre esto en esta charla de un ingeniero de Yahoo .

Es importante tener en cuenta que este enfoque limpio puede ser contrario a la preocupación por el rendimiento, lo que favorece a los selectores cortos basados ​​en la identificación o el nombre de la etiqueta . Encontrar ese equilibrio depende de usted, pero a menos que tenga un sitio masivo, esto debería ser solo una guía en la parte posterior de su cabeza que le recuerde que debe mantener cortos sus selectores. Más sobre el rendimiento aquí .

Por último, ¿va a tener un único archivo CSS para todo su sitio o varios archivos (un único archivo base utilizado con archivos por página o por sección)? El archivo único es mejor para el rendimiento, pero puede ser más difícil de entender / mantener con varios miembros del equipo, y puede ser más difícil de probar. Para las pruebas, le recomiendo que tenga una sola página de prueba CSS que incluya todos los módulos CSS compatibles para probar colisiones y cascadas involuntarias.

Alternativamente, puede tener un enfoque de múltiples archivos , para abarcar las reglas CSS a una página o sección. Esto requiere que el navegador descargue varios archivos, lo cual es un problema de rendimiento. Puede usar la programación del lado del servidor para especificar y agregar (y minimizar) los archivos CSS en un solo archivo de forma dinámica. Pero dado que estos archivos están separados y las pruebas para ellos estarían separadas, introduce la posibilidad de una apariencia inconsistente en las páginas / secciones. Por lo tanto, las pruebas se vuelven más difíciles.

Depende de usted analizar las necesidades específicas del cliente, equilibrar estas preocupaciones en consecuencia.

Como dije antes que yo: Entra en OOCSS. Sass / Less / Compass es tentador de usar, pero hasta que se use CSS vainilla de la manera correcta, Sass / Less / Compass solo empeorará las cosas.

En primer lugar, lea sobre css eficiente. prueba Google Page Speed ​​y lee lo que Souders ha escrito sobre css eficiente.

Luego, ingrese OOCSS.

• Aprende a trabajar con la cascada. (Después de todo, lo llamamos hojas de estilo en cascada ).
• Aprenda cómo obtener la granularidad correcta (de abajo hacia arriba en lugar de de arriba hacia abajo)
• Aprenda a separar la estructura y la piel (¿qué es único y cuáles son las variaciones de estos objetos?)
• Aprenda a separar el contenedor y el contenido.
• Aprende a amar las redes.

Revolucionará cada parte de la escritura de CSS. Estoy totalmente renovado y me encanta.

ACTUALIZACIÓN: SMACSS es similar a OOCSS, pero en general es más fácil de adaptar.

Los principios básicos para CSS sensible, extraídos de la refactorización de CSS: de CSS de solo agregado a CSS modular

Escribe en SASS. Sería una locura renunciar a las ventajas de las variables, mixins, etc.

Nunca use una identificación HTML para diseñar; siempre use clases . Las ID de HTML, cuando se usan correctamente, aparecen solo una vez en toda la página, lo que es todo lo contrario a la reutilización, uno de los productos más básicos en ingeniería sensible. Además, es realmente difícil anular los selectores que contienen ID y, a menudo, la única forma de dominar una ID HTML es crear otra ID, haciendo que las ID se propaguen en la base de código como las plagas que son. Es mejor dejar las ID de HTML para cambiar JavaScript o los ganchos de prueba de integración.

Nombre sus clases CSS por su función visual en lugar de por su función específica de la aplicación. Por ejemplo, diga ".highlight-box" en lugar de ".bundle-product-discount-box". La codificación de esta manera significa que puede reutilizar sus hojas de estilo existentes cuando descarta negocios paralelos. Por ejemplo, comenzamos vendiendo notas legales pero recientemente pasamos a ser tutores legales. Nuestras antiguas clases de CSS tenían nombres como ".download_document_box", un nombre de clase que tiene sentido cuando se habla de documentos digitales, pero que solo se confunde cuando se aplica al nuevo dominio de tutores privados. Un nombre mejor que se ajuste tanto a los servicios existentes, como a los futuros, sería ".pretty_callout_box".

Evite nombrar clases CSS después de información de cuadrícula específica. Hubo (y todavía hay) un antipatrón terrible en las comunidades CSS mediante el cual los diseñadores y creadores de marcos CSS (tos Twitter Bootstrap ) creen que "span-2" o "cols-8" son nombres razonables para las clases CSS. El objetivo de CSS es darle la posibilidad de modificar su diseño sin afectar el marcado (mucho). El tamaño de las cuadrículas codificadas en el HTML frustra este objetivo, por lo que se desaconseja en cualquier proyecto que dure más de un fin de semana. Más sobre cómo evitamos las clases de cuadrícula más adelante.

Divide tu CSS en archivos . Lo ideal sería dividir todo en "componentes" / "widgets" y luego componer páginas a partir de estos átomos de diseño. Sin embargo, de manera realista, notará que algunas de las páginas de su sitio web tienen idiosincrasias (por ejemplo, un diseño especial o una galería de fotos extraña que aparece en un solo artículo). En estos casos, puede crear un archivo relacionado con esa página específica, solo refactorizando en un widget completo cuando quede claro que el elemento se reutilizará en otro lugar. Esta es una compensación, motivada por preocupaciones presupuestarias prácticas.

Minimiza la anidación.Introducir nuevas clases en lugar de anidar selectores. El hecho de que SASS elimine el dolor de los selectores repetidos al anidar no significa que tenga que anidar a cinco niveles de profundidad. Nunca sobrecalifique un selector (por ejemplo, no use "ul.nav" donde ".nav" podría hacer el mismo trabajo). Y no especifique elementos HTML junto con el nombre de la clase personalizada (por ejemplo, "h2.highlight"). En su lugar, use solo el nombre de la clase y suelte el selector base (por ejemplo, el ejemplo anterior debería ser ".highlight"). Los selectores sobrecalificados no agregan ningún valor.

Cree estilos para elementos HTML (por ejemplo, "h1") solo cuando diseñe componentes base que deberían ser coherentes en toda la aplicación. Evite selectores amplios como "encabezado ul" porque es probable que tenga que anularlos en algunos lugares de todos modos. Como seguimos diciendo, la mayoría de las veces desea utilizar una clase específica y bien nombrada siempre que desee un estilo particular.

Abrace los conceptos básicos de Block-Element-Modifier. Puedes leer sobre esto, por ejemplo, aquí. Lo usamos con bastante ligereza, pero aun así nos ayudó mucho a organizar los estilos CSS.

Muchas veces veré a personas dividir el archivo en secciones, con un comentario de encabezado entre las secciones.

Algo como

/* Headings and General Text */

.... stuff here for H1, etc..

/* Main page layout */

.... stuff here for layout page setup etc.

Funciona bastante bien y puede facilitarle regresar más tarde y encontrar en qué está trabajando.

Deberías mirar BEM .

Teoría

BEM es un intento de proporcionar un conjunto de instrucciones para organizar y nombrar selectores css en un intento de hacer que las cosas sean más reutilizables y modulares y para evitar enfrentamientos entre los selectores del tipo que a menudo conduce a códigos de espagueti y dolores de cabeza de especificidad.

Cuando se usa correctamente, en realidad tiene algunos efectos muy positivos.

• Los estilos hacen lo que esperas cuando se agregan a un elemento
• Los estilos no se filtran y afectan solo a lo que se agregan
• Los estilos están completamente desacoplados de la estructura del documento.
• Los estilos no necesitan ser forzados a anularse

BEM funciona bien con SASS para brindar un estilo casi orientado a objetos a CSS. Puede crear archivos modulares, que manejan la visualización de un único elemento de la IU y contienen variables, como colores y 'métodos', como la forma en que se manejan los elementos internos. Si bien un programador de OO incondicional podría rechazar esta idea, de hecho, los conceptos aplicados incorporan muchas de las partes más bonitas de las estructuras de OO, como la modularidad, el acoplamiento suelto y la cohesión ajustada y la reutilización sin contexto. Incluso puede construir de una manera que se parece a un objeto encapsulado utilizando Sass y el &operato r.

Un artículo más detallado de la revista Smashing se puede encontrar aquí ; y uno de Harry Roberts de CCS Wizardry (de quien cualquier persona involucrada en CSS debería leer) está aquí .

En la práctica

He usado esto, varias veces, junto con haber usado SMACSS y OOCSS, lo que significa que también tengo algo para compararlos. También he trabajado en algunos grandes problemas, a menudo de mi propia creación, sin experiencia.

Cuando uso BEM en el mundo real, aumento la técnica con un par de principios adicionales. Utilizo clases de utilidad: un buen ejemplo es una clase de contenedor:

.page-section {
    width: 100%;
}
@media screen and (min-width: 1200px) {
    margin: 0 auto;
    width: 1200px;
}

Y también confío un poco en la cascada y la especificidad. Aquí el módulo BEM sería .primary-boxy .headersería el contexto para una anulación específica

.header {
  .primary-box {
    color: #000;
  }
}

(Intento hacer todo lo posible para que todo sea lo más genérico y libre de contexto posible, lo que significa un buen proyecto, casi todo está en los módulos que son reutilizables)

Un punto final que destacaría aquí es que, por pequeño y poco complejo que parezca su proyecto, debe hacerlo desde el principio, por dos razones:

• los proyectos aumentan en complejidad, por lo que es importante establecer buenos cimientos, incluido CSS
• incluso un proyecto que parece simple porque está construido en WordPress tiene poco JavaScript, aún puede ser muy complejo en el CSS: OK, no tiene que hacer ninguna codificación del lado del servidor, por lo que esa parte es simple, pero el front-end del folleto se desgasta tiene veinte módulos y tres variaciones de cada uno: ¡tienes algunos css muy complejos!

Componentes web

En 2015 comenzamos a analizar los componentes web. Todavía no sé mucho sobre esto, pero buscan unir todas las funcionalidades de front-end en módulos autónomos, intentando efectivamente aplicar el tipo de principios de BEM al front-end como un todo y componentes dispersos pero totalmente acoplados elementos como fragmentos DOM, Js (MVC) y CSS que construyen el mismo widget de UI.

Al hacer esto, abordarán algunos de los problemas originales que existen con css que hemos tratado de resolver con cosas como BEM, mientras que en el camino hace que algunas de las otras arquitecturas front-end sean más sensatas.

Hay algunas lecturas adicionales aquí y también un polímero Framework que vale la pena echarle un vistazo.

Finalmente

También creo que esta es una excelente y moderna guía css de mejores prácticas , diseñada específicamente para evitar que los grandes proyectos css se vuelvan desordenados. Intento seguir la mayoría de estos.

Te recomendaría que mires el marco CSS "Compass Style" .

hay un gran material aquí y algunos han tomado mucho tiempo para responder esta pregunta, sin embargo, cuando se trata de hojas de estilo separadas o individuales, iría con archivos separados para el desarrollo y luego pasaría a tener todos sus CSS genéricos utilizados en la fusión fusionada. en un solo archivo cuando se implementa.

de esta manera, tiene lo mejor de ambos mundos, aumenta el rendimiento (menos solicitudes HTTP que se solicitan desde el navegador) y la separación de problemas de código durante el desarrollo.