Gestionar la Explosión CSS

682

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.

JasCav
fuente
122
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.
cherouvim
8
@cherouvim: es curioso que debas decir eso porque toda mi razón para hacer esta pregunta comenzó con ver un CSS aterrador diseñado por un artista gráfico. Tal vez necesitamos un mejor entrenamiento para ellos?
JasCav
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 deben estar cerca de los programadores y diseñadores.
cherouvim el
@cherouvim Tengo que estar de acuerdo: así es como van las agencias, especialmente a medida que CSS se vuelve más complejo.
John Parker
27
@JasCav, los artistas gráficos no deberían tocar el CSS. Los diseñadores web y los desarrolladores web front-end deberían tratar con CSS. El trabajo del diseñador gráfico es hacer los gráficos.
zzzzBov

Respuestas:

566

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.

Pekka es compatible con GoFundMonica
fuente
3
@Andrew principalmente porque en un entorno dinámico (como un CMS) el uso de una ID podría conducir fácilmente a colisiones (por ejemplo, un usuario que cambia el nombre de una página a "contacto", lo que hace que ese nombre se use como ID del cuerpo, colisionando con el formulario de contacto también llamado "contacto"). Por lo general, recomiendo usar ID lo menos posible por ese motivo.
Pekka
44
@Pekka, deberías visitar www.oocss.org, mucho de lo que va en contra de lo que has mencionado aquí, pero es la mejor manera que he visto para administrar la hinchazón CSS. Vea mi respuesta a continuación también: stackoverflow.com/questions/2253110/how-to-manage-css-explosion/…
Moin Zaman
2
@ Sam gracias! Me gusta bastante bien, aunque ocasionalmente encuentro estas pautas muy difíciles de seguir. Hojas de estilo CSS son tan fáciles de meter la pata con el tiempo - un cambio de color aquí, una font-weight: boldallí .... disciplina es la única medicina :)
Pekka
1
Hablando como alguien nuevo en el estudio de la explosión CSS, la frase "clase única" es confusa. Tengo la sensación de que eso no es, idpero seguro que suena como uno. Tal vez el concepto podría aclararse?
ari gold
2
@ari tienes razón en que eso podría ser técnicamente idtambién.
Pekka
89

Aquí hay solo 4 ejemplos:

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.
Andy Ford
fuente
Los preprocesadores CSS son la causa del problema más que la solución. Domine el concepto de cascada de verdad y reducirá la hinchazón.
Daniel Sokolowski
@DanielSokolowski cualquier herramienta utilizada de forma incorrecta puede ser un problema en lugar de una solución. Pero el 100% está de acuerdo en el punto de dominar la cascada.
Andy Ford
73

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
srcspider
fuente
1
Los selectores sin etiqueta son mucho más lentos que los basados ​​en etiqueta. 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 representación tendrá que recorrer todos los elementos del DOM para ver si existe una coincidencia.
Miguel Ping
@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 una optimización especial, ¿por qué no se aplica a clases / identificadores? Tienes una fuente? El único asesino visible del rendimiento que noté con CSS fue debido al spam flotante: puede hacer que el motor de renderizado se demore horriblemente en algunos navegadores al desplazarse por la página (probablemente demasiados cálculos).
srcspider
3
Iba a votar esto para decir no a identificadores de destino, pero entonces no era la parte de no ser genérica (yay!) (Boo!)
mwilcox
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ía todas las clases ".myclass", y luego verificaría si es un antepasado de un div.
mwilcox
55
La comparación de reglas genéricas con variables globales es el error más grande que he escuchado sobre CSS.
gblazex
55

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

Zimbabao
fuente
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.
2
sass, compass y less 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 CSS en sí misma.
Moin Zaman
8
@Moin_Zaman En mi humilde opinión, señor, su declaración es pura tontería. usted escribe en sass / compass / less y organiza su código en sus archivos. no te importa cómo se ve el css de salida. Además, al menos menos (a través de menos aplicación) puede minimizar la salida, lo cual es genial.
bzx
1
@bzx estás demostrando mi punto :) Un navegador no entiende sass / compass / less. Todo esto debe compilarse en CSS simple, ya sea en el lado del cliente o como parte de su compilación. El uso de 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 óptimos.
Moin Zaman
Ahí es donde entra en juego la compresión gzip ... La mayoría de los servidores web y navegadores se comunicarán con contenido comprimido 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 es la cantidad de RAM necesaria para analizar las reglas CSS en el navegador.
Thirdender
31

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)

Moin Zaman
fuente
16

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.

Robusto
fuente
Usar ID es malo al igual que usar variables globales en su código de Visual Basic.
alpav
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 locos inventando nuevos nombres de clase.
Robusto
@Robusto: ¿Por qué es más difícil crear un nuevo nombre de identificación que crear un nuevo nombre de clase?
alpav
@Robusto: crear nuevos nombres de clase es realmente más fácil que los nombres de ID porque con los ID debe preocuparse por el alcance global y con los nombres de clase solo debe preocuparse por la unicidad en el alcance local, el mismo beneficio que con las variables locales.
alpav
1
@alpav "Eso frustra el propósito de la encapsulación: poder nombrar localmente sin pensar globalmente". Correcto, pero los selectores 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.
Paul D. Waite
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
   }
 }

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;
}
Abhishek Mehta
fuente
1
uso sass y podría ser que esta es una diferencia entre sass y menos, pero estoy bastante seguro de que se compilará como `#parent {width: 100%; } #parent # child1 {background: # E1E8F2; acolchado: 5px; } #parent # child2 {background: # F1F8E2; acolchado: 15px; } `
emik
12

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.

Paul D. Waite
fuente
7

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.

G-Wiz
fuente
5

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.

madr
fuente
2
"Sass / Less / Compass solo empeorará las cosas", eso es bastante subjetivo y depende del proyecto. Yo propondría que usar uno de estos junto con OOCSS realmente beneficiaría la mantenibilidad de muchos proyectos grandes (especialmente aquellos cuyos estilos se pueden cambiar con frecuencia)
Zach Lysobey
Zach L: OOCSS (o para el caso, SMACSS) utilizado correctamente hace que Compass / Less / Sass sea necesario solo para los prefijos de proveedor.
madr
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 que tales cosas son útiles, incluso en combinación con OOCSS / SMACSS fuera de los problemas de prefijo del proveedor
Zach Lysobey
4

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.

Jack Kinsella
fuente
2

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.

Mitchel Sellers
fuente
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
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 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.

Toni Leigh
fuente
0

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.

quinton
fuente