Gestión de la Explosión CSS

Estos son 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 estilos CSS

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

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

• Use un preprocesador CSS y administre sus archivos como parciales (personalmente prefiero Sass con Compass, pero Menos también es bastante bueno y hay otros)
• Leer sobre conceptos como OOCSS, SMACSS, y BEM o getbem.
• Echa un vistazo a cómo populares marcos CSS como Bootstrap y Zurb Foundation están estructurados. Y no descuentes los frameworks menos populares - Inuit es interesante, 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

Simplemente divida secciones en archivos. Cualquier comentario CSS, debe ser solo eso, comentarios.

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

Use un script para combinarlos en uno; si es necesario. Incluso puede tener una buena estructura de directorios también, y simplemente hacer que su script busque recursivamente archivos .css.

Si debe escribir encabezados, tenga un ÍNDICE al inicio del archivo

Los encabezados en el Índice deben ser perfectamente iguales a los encabezados que escribas más adelante. Es un dolor para buscar títulos. Para agregar al problema, ¿cómo exactamente se supone que alguien sepa que tiene otro encabezado después de su primer encabezado? ps. no agregue doc-like * (star) al comienzo de cada línea al escribir TOCs, solo hace que sea más molesto seleccionar el texto.

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

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

En primer lugar, cuando editas el script hay una probabilidad 50/50 de que prestes 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" fuera. Si está fuera, es el 99% de las veces un título, así que manténgalo así.

Dividir la página en componentes

Los componentes deben tener position:relative, no padding y no margin, la mayoría de las veces. Esto simplifica mucho las reglas%, además de permitir mucho más simple absolute:position'ing de elementos, ya que si hay un contenedor posicionado absoluto el elemento posicionado absoluto utilizará el contenedor al calcular top, right, bottom, left propiedades.

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

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

Siguiendo el ejemplo de la página QA de nuevo:

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

Al dividir la página en componentes, se divide el trabajo en manejable unidad.

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

Por ejemplo border, margin y padding (pero no outline) se suman a las dimensiones y el tamaño del elemento que estilo.

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

Si no son tan legibles en una línea, al menos póngalos cerca: {[49]]}

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

Use taquigrafía cuando sea posible:

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

Nunca repita un selector

Si tienes más instancias del mismo selector, hay una buena probabilidad de que inevitable terminar con múltiples instancias de las mismas reglas. Por ejemplo:

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

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

En primer lugar, las etiquetas DIV y SPAN son la excepción: ¡nunca debes usarlas, nunca! ;) Solo utilícelos para adjuntar una clase / id.

Esto...

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;
}

Debe escribirse así: {[49]]}

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

Porque los DIVs que cuelgan extra no añaden nada al selector. También fuerzan una regla de etiqueta innecesaria. Si fueras para cambiar, por ejemplo, .answer de un div a un article su estilo se rompería.

O si prefiere 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 de ser de la propiedad border-collapse es una propiedad especial que solo tiene sentido cuando se aplica a un table. Si .statistics no es un table no debe aplicarse.

Las reglas genéricas son malas!

• evite escribir reglas genéricas/mágicas si puede
• a menos que sea para un CSS-reset / unreset, toda tu magia genérica debería aplicarse a at al menos un componente raíz

No le ahorran tiempo, hacen que su cabeza explote; así como hacen que el mantenimiento sea una pesadilla. Cuando escribas la regla, es posible que sepas dónde se aplican, sin embargo, eso no garantiza que tu regla no se meta contigo más adelante.

Añadir a estas reglas genéricas es confuso y difícil de leer, incluso si usted tiene alguna idea del documento que está estilizando. Esto no quiere decir que no deba escribir reglas genéricas, simplemente no las use a menos que realmente intenta que sean genéricos, e incluso agregan tanta información de alcance en el selector como puedas.

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 se lee como: {[49]]}

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

Me gusta usar IDs cada vez que un componente que conozco es un singleton en una página; sus necesidades pueden ser diferentes.

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

Supongamos que tiene un componente pagination. Usted lo utiliza en muchos lugares a través de su sitio. Este sería un buen ejemplo de cuándo escribirías una regla genérica. Digamos que display:block el número de página individual enlaza y les da un fondo gris oscuro. Para que sean visibles tienes que tener reglas como esta:

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

Ahora digamos que usas tu paginación para un lista de respuestas, usted puede encontrar algo como esto

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

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

La manera incorrecta de arreglarlo es:{[49]]}

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

La forma correcta de arreglarlo es:{[49]]}

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

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

Si escribes algo como: "este valor depende de bla-bla combinado con la altura de bla-bla", es inevitable que cometas un error y todo se caerá como una casa de tarjeta.

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

¿Cómo escribo 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 sobrescribirse. Selectores de cadena que utilizan un padre de muy alto nivel componente (eg. #page) y luego escribe tu estilo como un bloque de reglas autosuficiente. Puede ser solo color o algo más.

Eg.

#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 estilos independiente del estilo base, en la que se conecta en cascada.

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

Usar menos nombres es mejor. Lo ideal es utilizar muy simple (y corto!) palabras: texto, cuerpo, encabezado.

También encuentro 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 viene a leer su sopa de estilo (como usted después de unas semanas ;)) solo necesita entender dónde se usan las palabras en lugar de donde se usa cada selector. Por ejemplo, utilizo .this cuando un elemento es supuestamente "el elemento seleccionado" o "el elemento actual", etc.

Limpiar después yourself

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

Si, como sugerí, tratas algunos contenedores como cajas negras (componentes) en tu estilo, utilizas esos componentes en tus selectores y guardas todo en uno dedicado archivo (o dividir correctamente un archivo con un índice y encabezados), entonces su trabajo es sustancialmente más fácil...

Puede usar una herramienta como los selectores de extensión de Firefox Dust-Me (consejo: apunte a su mapa del sitio.xml) para ayudarte a encontrar algo de la basura escondida en tus nukes y feriantes css.

Mantener un archivo unsorted.css

Supongamos que está diseñando un sitio de control de calidad y ya tiene una hoja de estilos para la "página de respuestas", a la que llamaremos answers.css. Si ahora necesita agregar un montón de css nuevo, agréguelo a la hoja de estilos unsorted.css luego refactoriza en tu hoja de estilos answers.css.

Varias razones para esto:

• es más rápido refactorizar una vez que haya terminado, entonces 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
• añadir al archivo original conduce fácilmente a la duplicación de reglas/selectores

Echa un vistazo a 1. SASS 2. Compás

La mejor manera que he visto para contrarrestar CSS la hinchazón es usando principios CSS Orientados a Objetos.

Incluso hay un OOCSS framework 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 diseñar CSS de una manera orientada a objetos, verá que realmente funciona para mantener el código lean & mean.

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). Sí, en realidad puede obtener ahorros no solo en su CSS, sino también en su HTML, lo que por su sonido, es muy posible para usted al mencionar la conversión de un diseño basado en table en muchos 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 hecho una brillante escritura 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)
CSS Bloat - (Diapositivas)

Usted también debe entender la cascada, y el peso, y cómo funcionan.

Noto que está utilizando solo identificadores de clase (div.titular). ¿Sabías que también puedes usar IDs, y que un ID 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 cualquiera que sean sus reglas. Incluso puedes hacer que todos los DIVs que son descendientes de #page1 obtengan ciertas reglas.

En cuanto al peso, recuerde que los ejes CSS se mueven de más general / más ligero a más específico / más pesado. Es decir, en un selector CSS un especificador de elemento es anulado por un especificador de clase es anulado por un especificador de ID. Los números cuentan, por lo que un selector con dos especificadores de 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 es todavía menor que un uno en la columna de las decenas. Un selector con un especificador de ID, un especificador de clase y dos elementos prescriptores, tendrá más peso que un selector sin ID, 500 prescriptores de clase y 1.000 prescriptores de elemento. Este es un ejemplo absurdo, por supuesto, pero entiendes la idea. El punto es, la aplicación de este concepto le ayuda a limpiar una gran cantidad de CSS.

POR cierto, añadiendo el elemento especificador a la clase (div.title) no es necesario a menos que tenga conflictos con otros elementos que tengan class="title". No agregue peso innecesario, porque es posible que necesite usar ese peso más adelante.

Puedo sugerir Menos CSS Dynamic framework

Es similar a SASS como se mencionó anteriormente.

Ayuda a mantener CSS por clase padre.

Por ejemplo

 #parent{     
  width: 100%;

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

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

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

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

Esto rendiría a

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

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

Me parece difícil traducir el diseño requerido para un sitio en una serie de reglas. Si el diseño del sitio es claro y basado en reglas, entonces los nombres de las clases y la estructura CSS pueden fluir de eso. Pero si las personas, con el tiempo, agregan al azar pequeños bits al sitio que no tienen mucho sentido, no hay mucho que puedas hacer al respecto en el CSS.

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

1. Reset CSS, basado en de Eric Meyer. (Porque de lo contrario, me parece que, para la mayoría de los elementos, tengo al menos una o dos reglas que solo están restableciendo los estilos predeterminados del navegador - la mayoría de mis listas no se parecen al estilo HTML predeterminado para las listas, por ejemplo.)

2. Sistema de cuadrícula CSS, si el sitio lo requiere. (Yo baso el mío en 960.gs)

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

4. Estilos para los componentes que se utilizan en varios lugares a través de la 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, tu 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 de organización de bajo nivel y ajustes que puede hacer para hacerlo más bonito, pero ninguno de ellos puede corregir 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.

Usted parece estar en el camino correcto con nombrar la semántica, pero se puede dar un paso más allá. Las secciones de HTML que aparecen repetidamente en el sitio sin modificación estructural (conocidas como "módulos") se pueden considerar raíces selectoras, y desde allí puede abarcar el diseño interno en relación con esa raíz. Este es el principio básico de CSS orientado a objetos , y puedes leer/ver más sobre esto en esta charla de un ingeniero de Yahoo .

Es importante tener en cuenta que este enfoque limpio puede ir en contra de la preocupación de rendimiento, que favorece selectores cortos basados en id o nombre de etiqueta. Encontrar ese equilibrio depende de usted, pero a menos que tenga un sitio masivo, esto debería ser una guía en la parte posterior de su cabeza que le recuerde que debe mantener sus selectores cortos. Más sobre 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 sección)? El archivo único es mejor para rendimiento, pero podría ser más difícil de entender / mantener con varios miembros del equipo, y podría ser más difícil de probar. Para probar, te recomiendo que tengas una única página de prueba de CSS que incluya todos los módulos CSS compatibles para probar colisiones y cascadas no deseadas.

Alternativamente, puede tener un enfoque de archivo múltiple , para aplicar las reglas CSS a una página o una sección. Esto requiere que el navegador descargue varios archivos, lo que es un problema de rendimiento. Puede utilizar el lado del servidor programación para especificar y agregar (y minificar) los archivos CSS en un solo archivo dinámicamente. Pero como 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: 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. pruebe Google Page Speed y lea lo que los Souders han 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 rejillas.

Revolucionará cada bit sobre escribir css. Estoy totalmente renovado y me encanta.

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

Los principios básicos para CSS sensible, extraídos de Refactorización CSS: De solo anexar a CSS modular

Escribe con SASS. Sería una locura renunciar a las ventajas de las variables, mixins, y así sucesivamente.

Nunca use un ID HTML para el estilo; siempre use clases . Los IDS HTML, cuando se usan correctamente, aparecen solo una vez en toda la página, que es el completamente opuesto a la reutilización-uno de los productos más básicos en ingeniería sensible. Además, es muy difícil anular selectores que contiene IDs y, a menudo, la única manera de dominar un ID HTML es crear otro ID, haciendo que los ID se propaguen en la base de código como el son plagas. Mejor dejar los IDS HTML para Javascript inmutable o 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 ".resaltado-caja" en lugar de".bundle-product-discount-box". Codificación en esta manera significa que puede reutilizar sus hojas de estilo existentes cuando se role out negocios secundarios. Por ejemplo, empezamos vendiendo billetes de ley, pero recientemente se trasladó a tutores de derecho. Nuestras antiguas clases CSS tenían nombres como ".download_document_box", un nombre de clase que tiene sentido al hablar acerca de los documentos digitales, pero solo confundiría cuando se aplica a la nueva dominio de tutores privados. Un mejor nombre que se adapte a ambos existentes servicios-y los futuros - serían ".pretty_callout_box".

Evite nombrar clases CSS después de información de cuadrícula específica. Hubo (y sigue habiendo) un terrible anti-patrón en las comunidades CSS por el que diseñadores y creadores de marcos CSS (cough Twitter Bootstrap) cree que "span-2" o "cols-8" son nombres razonables para CSS clase. El punto de CSS es darle la posibilidad de modificar su diseño sin afectar el marcado (mucho). Rejillas de codificación dura tamaños en el HTML frustra este objetivo, por lo que se aconseja en contra en cualquier se espera que el proyecto dure más de un fin de semana. Más sobre cómo evitamos grid clases más tarde.

Divide tu CSS en archivos. Lo ideal sería dividir todo en "componentes" / "widgets" y luego componer páginas de estos átomos de diseño. Sin embargo, de manera realista, notarás que parte de tu sitio web las páginas tienen idiosincrasias (por ejemplo, un diseño especial o una foto extraña galería que aparece en un solo artículo). En estos casos usted podría crear un archivo relacionado con esa página específica, solo refactorizando en un widget en toda regla cuando se hace claro que el elemento será reutilizado en otro lugar. Este es un compromiso, uno que está motivado por preocupaciones presupuestarias prácticas.

Minimizar la anidación. Introduzca nuevas clases en lugar de los selectores de anidamiento. El hecho de que SASS elimina el dolor de repetir selectores cuando anida no significa que tenga que anidar cinco niveles de profundidad. Nunca sobre-calificar a selector (por ejemplo, no use " ul.nav "dónde".nav" podría hacer el mismo trabajo.) Y no especifique elementos HTML junto con el nombre de clase personalizado (por ejemplo, " h2.destacar"). En su lugar, simplemente use la clase nombre solo y suelte el selector base (por ejemplo, el ejemplo anterior debería ser ".destacar"). Los selectores de calificación excesiva no agregan ninguno valor.

Cree estilos para elementos HTML (por ejemplo, "h1") solo cuando estile componentes base que deben ser consistentes en toda la aplicación. Evitar selectores amplios como "header ul" porque es probable que usted tengo que anularlos en algunos lugares de todos modos. Como seguimos diciendo, la mayoría del tiempo que desea utilizar una clase específica y bien nombrada cada vez que quiero un estilo particular.

Adopta los conceptos básicos de Block-Element-Modifier. Puedes leer sobre ello, por ejemplo, aquí. Lo usamos a la ligera, pero aún así ayudó nosotros mucho en la organización de estilos CSS.

Muchas veces veré individuos dividir el archivo en secciones, con un comentario de encabezado entre 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 hacer que sea fácil volver más tarde y encontrar lo que 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 las cosas más reutilizables y modulares y evitar choques entre selectores del tipo que a menudo conduce a código 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 filtran y afectan solo a lo que se agregan{[19]]}
• Los estilos están completamente desacoplados de la estructura del documento
• Los estilos no necesitan ser forzados a sobreponerse unos a otros{[19]]}

BEM funciona bien con SASS para traer un estilo casi orientado a objetos a CSS. Puede crear archivos modulares, que manejan la visualización de un solo elemento de la interfaz de usuario y contienen variables, como colores y 'métodos', como cómo se manejan los elementos internos. Mientras que un hardcore OO el programador podría rechazar esta idea, de hecho, los conceptos aplicados traen muchas de las partes más agradables de las estructuras OO, como la modularidad, el acoplamiento suelto y la cohesión estrecha y la reutilización sin contexto. Incluso puede construir de una manera que se parezca a un objeto encapsulado usando Sass y el & operato r.

Un artículo más en profundidad de Smashing Magazine se puede encontrar aquí ; y uno de Harry Roberts de CCS Wizardry (quien cualquiera involucrado en css debe tener una lectura de) está aquí .

En La Práctica

He utilizado esto, varias veces, junto con haber utilizado SMACSS y OOCSS lo que significa que tengo algo para compararlos también. También he trabajado en algunos grandes líos, 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 wrapper:

.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 especificidad. Aquí el módulo BEM sería .primary-box y el .header sería el contexto para un over-ride específico

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

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

Un punto final que me gustaría hacer 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 sentar buenas bases es importante, css incluido
• incluso un proyecto que parece simple porque está construido en WordPress tiene poco JavaScript todavía puede ser muy complejo en el CSS - OK, no tienes que hacer ninguna codificación del lado del servidor, por lo que esa parte es simple, pero el front-end de brochure-wear tiene veinte módulos y tres variaciones de cada uno: ¡tienes algunos CSS muy complejos allí!

Componentes web

En 2015 estamos empezando a mirar los componentes web. Yo no saber una gran cantidad sobre estos todavía, pero buscan reunir toda la funcionalidad del front-end en módulos autónomos, tratando efectivamente de aplicar el tipo de principios de BEM al front-end como un todo y componentisse dispersos pero totalmente acoplados elementos tales como DOM fragments, Js (MVC) y CSS que todos construyen el mismo widget de interfaz de usuario.

Al hacer esto theyb abordará algunos de los problemas originales que existen con css que hemos tratado de resolver con cosas como BEM, mientras que a lo largo de la manera de hacer que algunas de las otras arquitecturas de front-end sean más sanas.

Hay algunas lecturas adicionales aquí y también un polímero de marco aquí que bien vale la pena ver

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 desordenen. Trato de seguir la mayoría de estos.

Te recomiendo que mires "Compass Style" CSS framework.

Hay un gran material aquí y algunos han tomado mucho tiempo en responder a 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 tener todo su css genérico utilizado en el sitio fusionado 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 las preocupaciones de código mientras desarrollar.