Gestionar la explosión de CSS

689

He dependido mucho de 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 y abstraer mejor los datos dentro del archivo CSS.

Estoy usando una gran cantidad de divetiquetas dentro del sitio web, moviéndome de un sitio web basado principalmente en tablas. Así que obtengo muchos selectores de 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 es tan malo, pero como soy un principiante, me preguntaba si se podrían hacer recomendaciones sobre la mejor manera de organizar las distintas partes de un archivo CSS. No quiero tener un atributo CSS separado para cada elemento de 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 pondrán en práctica de usar buenas prácticas de codificación, en lugar de tener que retomarlo como lo hice yo.

7
  • 123
    Esta es una gran pregunta, pero para muchas empresas es un problema realmente irresoluble. Principalmente porque CSS está siendo gestionado por el autor y diseñadores gráficos que pueden no ser conscientes de los términos simplicity, complexity, maintenance, structurey refactoring. 5/11/10 a las 10:31
  • 8
    @cherouvim - Es gracioso que digas eso porque toda mi razón para hacer esta pregunta comenzó con ver un CSS aterrador diseñado por un artista gráfico. ¿Quizás necesitamos una mejor formación para ellos?
    JasCav
    6/11/10 a las 15:27
  • 13
    Mi solución (en un mundo ideal) es tener personas dedicadas en su equipo que corten el PSD en html + css y lo mantengan después. Estas personas deberían estar cerca de los programadores y diseñadores. 6/11/10 a las 15:52
  • @cherouvim Tengo que estar de acuerdo: así es como van las agencias, especialmente a medida que CSS se vuelve más complejo. 27/01/11 a las 17:21
  • 27
    @JasCav, los artistas gráficos no deberían tocar el CSS. Los diseñadores web y los desarrolladores web front-end deben ocuparse de CSS. El trabajo del diseñador gráfico es hacer los gráficos.
    zzzzBov
    28 de enero de 2011 a las 0:01
572

Esta es una muy buena pregunta. Dondequiera que mire, 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 que yo mismo estoy tratando de cumplir (no es que siempre logre cumplir).

  • Refactorice temprano, refactorice a menudo. Limpia archivos CSS con frecuencia, fusiona varias definiciones de la misma clase. Elimine las definiciones obsoletas de inmediato .

  • Cuando agregue 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 a la izquierda en IE <7")

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

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

  • Utilice una herramienta de embellecimiento que ayude a mantener un estilo constante. Yo uso Polystyle , con el 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 le ayude un precompilador de CSS. Estoy planeando investigar xCSS por la misma razón pronto. Hay varios más alrededor.

  • Si trabaja en equipo, destaque también la necesidad de calidad y estándares para los archivos CSS. A todo el mundo le gustan mucho 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 los conflictos de edición mucho más fáciles de resolver. Realmente vale la pena, incluso si estás "solo" en HTML y CSS.

  • No trabaje con !important. No solo porque IE = <7 no puede lidiar con eso. 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 la configuración global primero:

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, empiezo a construir clases CSS, especificando la mayor cantidad de ascendencia posible siempre que sea sensato 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 a medida que se aleja de la raíz. Quiere mantener el número de clases lo más bajo posible y quiere repetir lo menos posible.

Por ejemplo, digamos 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, todos son <ul>, todos tienen el mismo tamaño de fuente y los elementos están todos uno al lado del otro (a diferencia de 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 }

a continuación, defina las características específicas de cada uno de los tres menús. El nivel 1 tiene 40 píxeles de alto; 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 para el 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, intente resolver los puntos en común primero y colóquelos en una clase; luego, calcula las propiedades específicas y aplícalas a las clases o, si tienes que admitir Internet Explorer 6, a los ID.

Sugerencias de HTML misceláneas

If you add these semantics to your HTML output, designers can later customize the look of web sites and/or apps using pure CSS, which is a great advantage and time-saver.

  • Si es posible, asigne al cuerpo de cada página una clase única: <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 }
    
  • Cuando cree menús automáticamente, agregue tanto contexto CSS como sea 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 manera, se puede acceder a cada elemento del menú para diseñarlo de acuerdo con su contexto semántico: si es el primer o el último elemento de la lista; Si es el elemento activo actualmente; y por número.

Note that this assigning of multiple classes as outlined in the example above does not work properly in IE6. There is a workaround to make IE6 able to deal with multiple classes. If the workaround is not an option, you will have to set the class that is most important to you (item number, active or first/last), or resort to using IDs.

20
  • 3
    @Andrew principalmente porque en un entorno dinámico (como un CMS), el uso de una ID podría provocar fácilmente colisiones (por ejemplo, un usuario que cambia el nombre de una página a "contacto", lo que hace que ese nombre se utilice como la ID del cuerpo, colisionando con el formulario de contacto también llamado "contacto"). Por lo general, recomiendo usar las identificaciones con la mayor moderación posible por ese motivo.
    Pekka
    14 de abril de 2010 a las 8:53
  • 4
    @Pekka, deberías visitar www.oocss.org. Mucho de esto va en contra de lo que has mencionado aquí, pero es la mejor manera que he visto de administrar la hinchazón de CSS. Vea mi respuesta a continuación también: stackoverflow.com/questions/2253110/how-to-manage-css-explosion/… 27/01/11 a las 5:24
  • 2
    @Sam gracias! Me gusta bastante, aunque a veces encuentro estas pautas muy difíciles de seguir. Las hojas de estilo CSS son tan fáciles de estropear con el tiempo: un cambio de color aquí, un font-weight: boldallá ... la disciplina es la única medicina :)
    Pekka
    3/04/11 a las 17:33
  • 1
    Hablando como alguien nuevo en el estudio de la explosión de CSS, la frase "clase única" es confusa. Tengo la sensación de que eso no es un problema, idpero seguro que lo parece. ¿Quizás se podría aclarar el concepto? 16 de ene. De 2017 a las 21:57
  • 2
    @ari, tienes razón en que eso técnicamente también podría ser un problema id.
    Pekka
    16 de enero de 2017 a las 23:24
89

Aquí hay solo 4 ejemplos:

En los 4, mi respuesta ha incluido el consejo de descargar y leer los sistemas PDF 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 de organización.

EDITAR (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 están estructurados los marcos CSS populares como Bootstrap y Zurb Foundation . Y no descarte los marcos 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 ejecutor de tareas como Grunt o Gulp.
2
  • Los preprocesadores CSS son la causa del problema más que la solución. Domina verdaderamente el concepto de cascada y reducirás la hinchazón. 4 dic 2018 a las 14:33
  • @DanielSokolowski cualquier herramienta utilizada incorrectamente puede ser un problema más que una solución. Pero el 100% está de acuerdo en el punto de dominar la cascada. 5/12/18 a las 15:23
73

No escriba encabezados en CSS

Simplemente divida las secciones en archivos. Cualquier comentario de 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 hacer que su script busque .cssarchivos de forma recursiva .

Si debe escribir títulos, tenga una tabla de contenido al comienzo del archivo

Los títulos de la tabla de contenido deben ser perfectamente iguales a los títulos que escriba más adelante. Es un dolor buscar títulos. Para agravar el problema, ¿cómo se supone que alguien sepa exactamente que tienes otro encabezado después del primer encabezado? PD. no agregue doc-like * (estrella) al comienzo de cada línea al escribir 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, existe una probabilidad del 50/50 de que preste atención a lo que está fuera del bloque de reglas (especialmente si se trata de una gran cantidad de texto;)). En segundo lugar, no hay (casi) ningún caso en el que necesite un "comentario" externo. Si está afuera, el 99% de las veces es un título, así que manténgalo así.

Divida 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 de 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 sencillos, trate algo como un componente si tiene sentido tratar algo como una caja negra .

Continuando con el ejemplo de la página de control de calidad nuevamente:

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

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

Coloque reglas con 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;

Utilice 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 tiene más instancias del mismo selector, es muy probable 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 el uso de 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;
}

Porque los DIV extra colgantes no agregan nada al selector. También fuerzan una regla de etiqueta innecesaria. Si cambiaras, por ejemplo, .answerde a diva a, articletu 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 es que la border-collapsepropiedad es una propiedad especial que solo tiene sentido cuando se aplica a un table. Si .statisticsno es tableasí, no debería 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 su magia genérica debería aplicarse al menos a un componente raíz

No te ahorran tiempo, te hacen explotar la cabeza; además de hacer del mantenimiento una pesadilla. Cuando escriba 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. ¡Necesitas 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 cada vez que 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 usa en muchos lugares de su sitio. Este sería un buen ejemplo de cuándo estaría escribiendo una regla genérica. Digamos que display:blocklos enlaces de los números de página individuales y les dan 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 sus enlaces blancos sean negros, lo que no desea.

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 complejos de "lógica" 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 derrumbará 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 debería sobrescribir. Encadena selectores utilizando un componente principal de muy alto nivel (por ejemplo #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. Lo ideal es utilizar 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 y "apropiadas": postbody, posthead, userinfo, etc.

Mantenga el vocabulario pequeño, de esta manera, incluso si un extraño que 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 dónde se usa cada selector. Por ejemplo, utilizo .thiscada vez que un elemento es supuestamente "el elemento seleccionado" o "el elemento actual", etc.

Limpia después de ti mismo

Escribir CSS es como comer, a veces dejas un desastre. Asegúrese de limpiar ese desorden, o el código de basura simplemente se acumulará. Elimina las clases / identificadores que no usas. Elimina las reglas CSS que no usas. Asegúrese de que todo esté bien y ajustado 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 mantuvo todo en un archivo dedicado (o dividió correctamente 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 de Firefox Dust-Me Selectors (consejo: apúntelo a su sitemap.xml) para ayudarlo a encontrar algo de la basura escondida en sus css nukes y carnies.

Mantenga un unsorted.cssarchivo

Supongamos que está diseñando un sitio de control de calidad y ya tiene una hoja de estilo para la "página de respuestas", a la que llamaremos answers.css. Si ahora necesita agregar muchos CSS nuevos, agréguelos 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, la inyección de 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 reglas / selectores
7
  • 1
    Los selectores sin etiquetas son mucho más lentos que los basados ​​en etiquetas. Todos los navegadores tienen métodos nativos para obtener un 'div', por ejemplo (o cualquier otra etiqueta). Si deja que sea demasiado genérico ('.class'), el motor de renderizado tendrá que recorrer todos los elementos del DOM para ver si existe una coincidencia. 27/01/11 a las 17:45
  • @Miguel ¿Por qué el motor de renderizado no tendría que recorrer todos los elementos del DOM para ver si son un DIV? Si hay alguna optimización especial, ¿por qué no se aplica a las clases / ids? Tienes una fuente? El único asesino visible del rendimiento que noté con CSS fue el spam flotante: puede hacer que el motor de renderizado se retrase horriblemente en algunos navegadores al desplazarse por la página (probablemente demasiados cálculos). 27/01/11 a las 18:53
  • 3
    Iba a votar esto por decir que no apuntes a tagNames (¡yay!) Pero luego estaba la parte de no ser genérico (¡boo!)
    mwilcox
    27/01/11 a las 19:02
  • 1
    @Miguel, no funciona de esa manera. Los navegadores leen una cadena CSS al revés, por lo que tomaría: "div .myclass" y buscar todas las clases ".myclass", y luego comprobar si es un antepasado de un div.
    mwilcox
    27/01/11 a las 19:04
  • 5
    Comparar reglas genéricas con variables globales es el mayor error que he escuchado sobre CSS.
    gblazex
    28 de enero de 2011 a las 1:12
55

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

5
  • 11
    Un millón de veces esto. Usar Sass me ha convertido en un wrangler css más organizado y poderoso que nunca. Me permite organizar estilos en varios archivos, anidar estilos, usar variables, etc., etc., etc.
    Alan H.
    27/01/11 a las 7:35
  • 2
    sass, compass y menos, todos producen CSS normal al final del día que aún podría ser feo y explotar. No es una solución para la hinchazón de CSS en sí misma. 28 de enero de 2011 a las 3:40
  • 9
    @Moin_Zaman En mi humilde opinión, señor, su declaración es pura patraña. escribe en sass / compass / less y organiza su código en sus archivos. no le importa cómo se ve el CSS de salida. Además, al menos menos (a través de menos aplicaciones) puede minimizar la salida, lo cual es genial.
    bzx
    6 de mayo de 2011 a las 17:52
  • 1
    @bzx estás demostrando mi punto :) Un navegador no entiende sass / compass / less. todos estos deben compilarse en CSS antiguo, ya sea en el lado del cliente o como parte de su compilación. Usar herramientas como estas sin saber lo que producen como CSS al final hace que sea muy fácil abusar de ellas sin saberlo y terminar con archivos CSS más grandes que los óptimos. 12/10/11 a las 13:33
  • Ahí es donde entra en juego la compresión gzip ... La mayoría de los servidores web y navegadores se comunicarán con el contenido comprimido con gzip cuando sea posible. Si termina repitiendo un fragmento de selector varias veces, se comprimirá en una sola entrada de tabla hash. El único problema real entonces es la cantidad de RAM necesaria para analizar las reglas CSS en el navegador. 26 de diciembre de 2013 a las 20:52
31

La mejor forma que he visto de contrarrestar la CSShinchazón es utilizando los principios de CSS orientado a objetos.

Incluso existe 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 una manera orientada a objetos, verá que realmente funciona para mantener el código delgado y medio.

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

Facebook contrató a la creadora de OOCSS, Nicole Sullivan para ahorrar mucho en su código de interfaz (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 escrito un brillante libro y un 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)

16

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

Noto que está usando solo identificadores de clase (div.title). ¿Sabías que también puedes 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 todos los DIV que son descendientes de # page1 tengan 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 de 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 sigue siendo menor que uno en la columna de las decenas. Un selector con un especificador de ID, un especificador de clase y dos especificadores de elementos tendrá más peso que un selector sin ID, 500 especificadores de clase y 1000 especificadores de elementos. Este es un ejemplo absurdo, por supuesto, pero entiendes la idea. El caso 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, porque es posible que deba usar ese peso más adelante.

20
  • Usar ID es malo al igual que usar variables globales en su código de Visual Basic.
    alpav
    9/03/10 a las 22:21
  • 2
    @alpav: Lo siento, eso es incorrecto. Los ID son una excelente manera de hacer que los elementos similares aparezcan de manera diferente en diferentes partes de una página sin volverse loco inventando nuevos nombres de clases.
    Robusto
    10/03/10 a las 0:35
  • @Robusto: ¿Por qué crear un nuevo nombre de identificación es más difícil que crear un nuevo nombre de clase?
    alpav
    10/03/10 a las 18:42
  • @Robusto: hacer nuevos nombres de clase es en realidad más fácil que los nombres de ID porque con los ID tienes que preocuparte por el alcance global y con los nombres de clases debes preocuparte solo por la unicidad en el alcance local, el mismo beneficio que con las variables locales.
    alpav
    10/03/10 a las 18:51
  • 1
    @alpav "Eso contradice el propósito de la encapsulación: poder nombrar localmente sin pensar globalmente". Correcto, pero los selectores de CSS son inherentemente globales: cuando escribes .myclass, seleccionas todo con la clase myclass. En CSS, las clases son idénticas a los identificadores en ese sentido. 5/11/10 a las 16:20
12

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

Qué hace esto: aplica ancho: 100% tanto a # child1 como a # child2.

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

Esto se traduciría en

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

#parent #child2
{
 width: 100%;
 background: #F1F8E2;
 padding: 15px;
}
1
  • 1
    uso sass y puede ser que esta sea una diferencia entre sass y less, pero estoy bastante seguro de que se compilará como `#parent {width: 100%; } # parent # child1 {background: # E1E8F2; relleno: 5px; } # parent # child2 {antecedentes: # F1F8E2; relleno: 15px; } `
    emik
    26 de septiembre de 2013 a las 15:54
12

Encuentro 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 las clases y la estructura CSS pueden fluir a partir de eso. Pero si las personas, con el tiempo, agregan al azar pequeños fragmentos 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. Reinicio 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; la mayoría de mis listas no se parecen al estilo HTML predeterminado para las listas, por ejemplo).

  2. CSS del sistema de cuadrícula, si el sitio lo requiere. (Yo 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 depende del diseño del sitio. Si el diseño es claro y organizado, su CSS puede serlo. Si no, estás jodido.

7

Mi respuesta es de alto nivel para abordar las preocupaciones de alto nivel que ha planteado en su pregunta. Puede haber trucos organizativos de bajo nivel y ajustes que puede hacer para hacerlo 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 estar en el camino correcto con la semántica de nombres, pero se puede dar un paso más. Las secciones de HTML que aparecen repetidamente en el sitio sin modificación estructural (conocidas como "módulos") pueden considerarse raíces de selector y, desde allí, puede determinar el diseño interno relativo a esa raíz. Este es el principio básico del CSS orientado a objetos , y puede leer / ver más sobre él en esta charla de un ingeniero de Yahoo .

Es importante tener en cuenta que este enfoque limpio puede funcionar en sentido 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 sus selectores cortos. Más sobre el rendimiento aquí .

Por último, ¿tendrá un solo archivo CSS para todo su sitio o varios archivos (un solo archivo base utilizado con archivos por página o 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 no deseadas.

Alternativamente, puede tener un enfoque de archivos múltiples para aplicar 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 utilizar 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 la prueba para ellos sería separada, introduce la posibilidad de una apariencia inconsistente en todas 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 y equilibrar estas preocupaciones en consecuencia.

5

Como dije antes que yo: entra en OOCSS. Sass / Less / Compass es tentador de usar, pero hasta que se use CSS vanilla 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 Souders ha escrito sobre CSS eficiente.

Luego, ingrese OOCSS.

  • Aprenda a trabajar con la cascada. (Después de todo, lo llamamos Hojas de estilo en cascada ).
  • Aprenda a 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 contenedor y contenido.
  • Aprende a amar las cuadrículas.

Revolucionará cada parte de la escritura de 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.

3
  • 2
    "Sass / Less / Compass solo empeorará las cosas", eso es bastante subjetivo y depende del proyecto. Propondría que el uso de uno de estos junto con OOCSS realmente beneficiaría la capacidad de mantenimiento de muchos proyectos grandes (especialmente aquellos cuyos estilos se pueden cambiar con frecuencia) 15 feb 2013 a las 14:52
  • Zach L: OOCSS (o para el caso, SMACSS) usado correctamente hace que Compass / Less / Sass sea necesario solo para prefijos de proveedores.
    madr
    18 feb 2013 a las 11:59
  • No intentaré discutir esto demasiado (especialmente porque actualmente no uso un preprocesador), pero estoy bastante seguro de que hay un montón de personas que SÍ encuentran útiles estas cosas, incluso en combinación. con OOCSS / SMACSS fuera de los problemas de prefijo del proveedor 18 feb 2013 a las 16:12
4

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

Write in SASS. You'd be insane to forego the advantages of variables, mixins, and so on.

Never use an HTML ID for styling; always use classes. HTML IDs, when used correctly, appear only once in the whole page, which is the complete opposite of re-usability — one of the most basic goods in sensible engineering. Moreover, it's really hard to override selectors containing IDs and often the only way to overpower one HTML ID is to create another ID, causing IDs to propagate in the codebase like the pests they are. Better to leave the HTML IDs for unchanging Javascript or integration test hooks.

Name your CSS classes by their visual function rather than by their application-specific function. For example, say ".highlight-box" instead of ".bundle-product-discount-box". Coding in this way means that you can re-use your existing style-sheets when you role out side-businesses. For example, we started out selling law notes but recently moved into law tutors. Our old CSS classes had names like ".download_document_box", a class name that makes sense when talking about digital documents but would only confuse when applied to the new domain of private tutors. A better name that fits both existing services — and any future ones — would be ".pretty_callout_box".

Avoid naming CSS classes after specific grid information. There was (and still is) a dreadful anti-pattern in CSS communities whereby designers and creators of CSS frameworks (cough Twitter Bootstrap) believe that "span-2" or "cols-8" are reasonable names for CSS classes. The point of CSS is to give you the possibility to modify your design without affecting the markup (much). Hardcoding grids sizes into the HTML thwarts this goal, so it is advised against in any project expected to last longer than a weekend. More on how we avoided grid classes later.

Split your CSS across files. Ideally you would split everything into "components"/"widgets" and then compose pages from these atoms of design. Realistically though, you'll notice that some of your website pages have idiosyncrasies (e.g. a special layout, or a weird photo gallery that appears in just one article). In these cases you might create a file related to that specific page, only refactoring into a full-blown widget when it becomes clear that the element will be re-used elsewhere. This is a tradeoff, one that is motivated by practical budgetary concerns.

Minimise nesting. Introduce new classes instead of nesting selectors. The fact that SASS removes the pain of repeating selectors when nesting doesn't mean that you have to nest five levels deep. Never over-qualify a selector (e.g. don't use "ul.nav" where ".nav" could do the same job.) And don't specify HTML elements alongside the custom class name (e.g."h2.highlight"). Instead just use the class name alone and drop the base selector (e.g. the previous example should be ".highlight"). Over-qualifying selectors doesn't add any value.

Create styles for HTML elements (e.g. "h1") only when styling base components which should be consistent in the whole application. Avoid broad selectors like "header ul" because it's likely that you have to override them in some places anyway. As we keep saying, most of the time you want to use a specific, well-named class whenever you want a particular style.

Embrace the basics of Block-Element-Modifier. You can read about it for example on here. We used it quite lightly, but still it helped us a lot in organising CSS styles.

2

Muchas veces veré a las personas dividir el archivo en secciones, con un comentario de título 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 hacer que sea más fácil volver más tarde y encontrar en qué está trabajando.

1
  • Esto no dice nada acerca de la preocupación del autor de la pregunta por tener "un atributo CSS separado para cada cosa".
    G-Wiz
    12/02/10 a las 16:53
1

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 choques entre selectores del tipo que a menudo conduce a códigos espaguetis y dolores de cabeza por 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 entre sí.

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 la forma en que se manejan los elementos internos. Si bien un programador de OO incondicional podría resistirse a esta idea, de hecho, los conceptos aplicados incorporan muchas de las partes más agradables de las estructuras de OO, como la modularidad, el acoplamiento flexible y la cohesión ajustada y la reutilización sin contexto. Incluso puede construir de una manera que parezca un objeto encapsulado usando Sass y el &operato r.

Puede encontrar un artículo más detallado de Smashing Magazine aquí ; y uno de Harry Roberts de CCS Wizardry (de quien cualquier persona involucrada en CSS debería haber leído) está aquí .

En la práctica

He usado esto varias veces, además de haber usado SMACSS y OOCSS, lo que significa que también tengo algo para compararlos. También he trabajado en grandes líos, a menudo de mi propia creación sin experiencia.

Cuando utilizo 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 contenedora:

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

(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 último punto que señalarí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 sentar buenas bases, css incluido
  • incluso un proyecto que parece simple porque está construido en WordPress tiene poco JavaScript puede ser muy complejo en el CSS; de acuerdo, no tiene que hacer ninguna codificación del lado del servidor, por lo que esa parte es simple, pero la interfaz de uso del folleto tiene veinte módulos y tres variaciones de cada uno: ¡tienes algunos CSS muy complejos allí!

Componentes Web

En 2015 comenzamos a mirar los componentes web. Todavía no conozco mucho sobre estos, pero buscan unir todas las funcionalidades del front-end en módulos autónomos, tratando de manera efectiva de aplicar el tipo de principios de BEM al front-end como un todo y en componentes dispersos pero totalmente acoplados. elementos como fragmentos DOM, Js (MVC) y CSS que construyen el mismo widget de interfaz de usuario.

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 hacen que algunas de las otras arquitecturas de front-end sean más sensatas.

Hay más lecturas aquí y también un polímero marco aquí que 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 vuelvan desordenados. Intento seguir la mayoría de estos.

0

Le recomendaría que consulte el marco CSS "Compass Style" .

0

hay un gran material aquí y algunos se 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 que todos sus css genéricos se usen en el sitio fusionado en un solo archivo cuando se implementa.

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