css organization

Gestionando la explosión de CSS



organization (15)

No escriba encabezados en CSS

Solo divide las secciones en archivos. Cualquier comentario de 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 necesario. Incluso puede tener una buena estructura de directorios también, y simplemente hacer que su script .css archivos .css .

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 escribe más adelante. Es un dolor buscar títulos. Para agregar al problema, ¿cómo se supone que alguien sepa que tiene 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 edites el script hay una posibilidad de 50/50 de que prestes atención a lo que está fuera del bloque de reglas (especialmente si es un gran globo de texto;)). En segundo lugar, no hay (casi) ningún caso en el que necesite un "comentario" externo. Si está fuera, es el 99% del tiempo de un título, así que mantenlo así.

Dividir la página en componentes.

Los componentes deben tener una position:relative , sin padding y sin margin , la mayor parte del tiempo. Esto simplifica mucho el% de reglas, además de permitir un absolute:position mucho más simple absolute:position de elementos, ya que si hay un contenedor posicionado absoluto, el elemento posicionado absoluto usará el contenedor al calcular las propiedades top , right , bottom , left .

La mayoría de los archivos 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 de los laicos, tratar algo como un componente si tiene sentido tratar algo como una caja negra .

Siguiendo 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.

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

Por ejemplo, el border , el margin y el padding (pero no el outline ) se agregan a las dimensiones y al 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 taquigrafía cuando sea posible:

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

Nunca repetir un selector

Si tiene más instancias del mismo selector, hay una buena probabilidad de que, inevitablemente, termine 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 TAG como selectores, cuando puede usar id / classes

Primero que nada, las etiquetas DIV y SPAN son la excepción: ¡nunca debes usarlas, nunca! ;) Úsalos 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 que cuelgan extra no agregan nada al selector. También obligan a una etiqueta-regla innecesaria. Si .answer que cambiar, por ejemplo, .answer de un div a un article su estilo 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 por la cual la propiedad border-collapse es una propiedad especial que solo tiene sentido cuando se aplica a una table . Si .statistics no es una table no debería aplicarse.

¡Las reglas genéricas son malas!

  • Evita escribir reglas genéricas / mágicas si puedes
  • a menos que sea para un restablecimiento / desactivación de CSS, toda su magia genérica debería aplicarse a al menos un componente raíz

No te ahorran tiempo, te hacen explotar la cabeza; así como hacer del mantenimiento una pesadilla. Cuando está escribiendo la regla, puede saber dónde se aplican, sin embargo, eso no garantiza que su regla no le afecte más adelante.

Añadir 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 agregue tanta información de alcance en el selector como pueda.

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 cuando 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 de pagination . Lo usas en muchos lugares a través de tu sitio. Este sería un buen ejemplo de cuándo escribiría una regla genérica. Digamos que display:block los enlaces de números de páginas individuales y déles un fondo gris oscuro. Para que sean visibles hay que tener reglas como esta:

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

Ahora digamos que usa su paginación para obtener 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 se vuelvan negros, lo que no quieres.

La forma incorrecta de arreglarlo 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 escribes algo como: "este valor depende de bla-bla combinado con la altura de bla-bla", es inevitable que cometas un error y todo 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 escribo un palet de colores?

Deja esto para el final. Tenga un archivo para toda su paleta de colores. Sin este archivo, su estilo aún debe tener un palet de colores utilizable en las reglas. Su palet de colores debe sobrescribir. Usted encadena los selectores utilizando un componente primario de muy alto nivel (por ejemplo, #page ) y luego escribe su estilo como un bloque de reglas autosuficientes. 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 de base, en la que se conecta en cascada .

Menos nombres, menos memoria, lo que facilita la lectura del código

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

Limpiar después de ti

Escribir CSS es como comer, a veces dejas un lío atrás. Asegúrate de limpiar ese desastre, o el código de basura simplemente se acumulará. Elimina las clases / IDs que no uses. Elimina las reglas CSS que no usas. Asegúrese de que todo esté bien ajustado y que no tenga reglas contradictorias 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 divida adecuadamente un archivo con un índice 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 (sugerencia: diríjala a su sitemap.xml) para ayudarlo a encontrar parte de la basura oculta en sus nukes y carnies de css.

Mantener un archivo unsorted.css

Digamos 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 nuevos css, agréguelo a la hoja de estilo unsorted.css luego refactorice su hoja de estilo answers.css .

Varias razones para esto:

  • es más rápido refactorizar una vez que haya terminado, entonces es buscar reglas (que probablemente no existen) e inyectar código
  • escribirá cosas que eliminará, 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 la regla / selector

He confiado mucho en CSS para un sitio web en el que estoy trabajando. En este momento, todos los estilos CSS se aplican por etiqueta, por lo que ahora estoy tratando de moverlo a un estilo más externo para ayudar con futuros cambios.

Pero ahora el problema es que me he dado cuenta de que estoy recibiendo una "explosión de CSS". Me resulta difícil decidir cómo organizar mejor y resumir los datos dentro del archivo CSS.

Estoy usando una gran cantidad de etiquetas div dentro del sitio web, moviéndome desde un sitio web basado en tablas. Así que estoy recibiendo 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 está tan mal, 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 aprenderlo como lo hice yo.

¿Puedo sugerir LESS

Es similar a SASS como se mencionó anteriormente.

Ayuda a mantener el CSS por clase padre.

P.ej

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

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

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

Esto haría que

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

Aquí hay solo 4 ejemplos:

En todas las 4, mi respuesta ha incluido el consejo para 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.

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

  • Use un preprocesador de CSS y administre sus archivos como parciales (yo personalmente prefiero Sass con Compass, pero Menos 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 descuente 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 ejecutor de tareas como Grunt o Gulp.

Como he dicho antes: entra en el OOCSS. Sass / Less / Compass es tentador de usar, pero hasta que vanilla CSS se use de la manera correcta, Sass / Less / Compass solo empeorará las cosas.

En primer lugar, lea acerca de 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 Cascading Stylesheets).
  • Aprenda cómo obtener la granularidad correcta (de abajo a arriba en lugar de de arriba a abajo)
  • Aprenda cómo separar la estructura y la piel (¿qué es único y cuáles son las variaciones de estos objetos?)
  • Aprende a separar contenedor y contenido.
  • Aprende a amar las redes.

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

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

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 se basa en reglas, entonces los nombres de clase y la estructura CSS pueden derivarse de eso. Pero si las personas, con el tiempo, agregan pequeños bits al sitio de forma aleatoria que no tienen mucho sentido, no hay mucho que puedas hacer al respecto en el CSS.

Tiendo a organizar mis archivos CSS de esta manera:

  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 de navegador predeterminados; la mayoría de mis listas no parecen el estilo HTML predeterminado para las listas, por ejemplo).

  2. Sistema de cuadrícula CSS, si el sitio lo requiere. (Base la mía 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, tu CSS puede ser. Si no, estás jodido.

Esta es una muy buena pregunta. Por todas partes, los archivos CSS tienden a salirse de 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 las que siempre logro).

  • Refactor temprano, refactor a menudo. Con frecuencia, limpie los archivos CSS, fusione varias definiciones de la misma clase. Eliminar las definiciones obsoletas de inmediato .

  • Cuando agregue CSS durante la reparació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 redundancias, por ejemplo, definiendo lo mismo en .classname y .classname:hover .

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

  • Utilice una herramienta prettifier que ayuda a mantener un estilo constante. Uso Polystyle , con el que estoy bastante feliz (cuesta $ 15 pero es dinero bien gastado). Estoy seguro de que también hay gratuitas (Actualización: como, por ejemplo, Code Beautifier basado en CSS Tidy , una herramienta de código abierto que no he usado todavía pero que parece muy interesante).

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

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

  • Defina todo lo que esté en el nivel más bajo posible (p. Ej., Una familia de fuentes predeterminada, color y tamaño en el body ) y utilice inherit cuando sea posible

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

  • Si trabaja en equipo, resalte también la necesidad de calidad y estándares para los archivos CSS. Todos son importantes en cuanto a los estándares de codificación en su (s) lenguaje (s) de programación, pero hay poca conciencia de que esto también es necesario para CSS.

  • Si trabaja en un equipo, considere usar el control de versiones. Hace que las cosas sean mucho más fáciles de rastrear, y los conflictos de edición son mucho más fáciles de resolver. Realmente vale la pena, incluso si estás "solo" en HTML y CSS.

  • No trabajes con !important . No solo porque IE = <7 no puede lidiar con eso. En una estructura compleja, el uso de! Important es a menudo 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.

Primero aplico 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 crear clases de CSS, especificando la mayor ascendencia posible y sensible, 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 de la raíz se encuentre. Desea mantener el número de clases lo más bajo posible, y repetirlo 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 ellos son <ul> , todos tienen el mismo tamaño de fuente y todos los elementos están uno al lado del otro (a diferencia de la representación predeterminada de una 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 una altura de 40 píxeles; 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 id s.

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 primero los puntos comunes y colocarlos en una clase; luego, calcule las propiedades específicas y aplíquelas a las clases o, si tiene que admitir Internet Explorer 6, ID.

Varios consejos HTML

Si agrega estas semánticas a su salida HTML, los diseñadores pueden personalizar más adelante el aspecto de los sitios web y / o aplicaciones con CSS puro, lo que es una gran ventaja y ahorra tiempo.

  • Si es posible, <body class=''contactpage''> una categoría ú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 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 crear estilos 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 clases múltiples como se describe en el ejemplo anterior no funciona correctamente en IE6 . Hay una workaround para que IE6 pueda manejar múltiples clases; No lo he probado todavía, pero parece muy prometedor, procedente de Dean Edwards. Hasta entonces, 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. (booo IE6!)

La mejor manera que he visto para contrarrestar la expansión de CSS es mediante el uso de principios CSS orientados a objetos.

Incluso hay un marco OOCSS por ahí que es bastante bueno.

Algunas de las ideologías van en contra 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 crear patrones de bloque en su sitio y arquitecto con ellos.

Facebook contrató a la creadora de OOCSS, Nicole Sullivan para obtener muchos ahorros en su código de usuario (HTML / CSS). Sí, realmente puede obtener ahorros no solo en su CSS, sino también en su HTML, que, por el sonido, es muy posible para usted cuando menciona la conversión de un diseño basado en table en muchos div .

Otro gran enfoque es similar en algunos aspectos al OOCSS, es planificar y escribir su CSS para que sea escalable y modular desde el principio. Jonathan Snook ha realizado un brillante trabajo de redacción y libro / libro electrónico sobre SMACSS

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

Mi respuesta es de alto nivel para abordar las inquietudes de alto nivel que ha planteado en su pregunta. Puede haber trucos organizacionales 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 que estás en el camino correcto con la semántica de nombres, pero se puede ir 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 de selección, y desde allí se puede establecer 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 ir en contra de la preocupación por el rendimiento, lo que favorece a los 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 solo una guía en la parte posterior de su cabeza que le recuerda que debe mantener sus selectores cortos. Más sobre el rendimiento aquí .

Por último, ¿va a tener un solo archivo CSS para todo el 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 de CSS que incluya todos los módulos CSS compatibles para probar colisiones y cascadas no deseadas.

Alternativamente, puede tener un enfoque de múltiples archivos , para extender las reglas CSS a una página o una 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 como estos archivos están separados y las pruebas para ellos serían independientes, usted presenta la posibilidad de una apariencia y percepción inconsistentes en las páginas / secciones. Por lo tanto, la prueba se vuelve más difícil.

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

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

Me doy cuenta de que está usando solo identificadores de clase (div.title) ¿Sabía que también puede usar las ID y que una 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, por ejemplo, o un color, o cualesquiera que sean sus reglas. Incluso puede hacer que todos los DIV que son descendientes de # page1 obtengan ciertas reglas.

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

Por cierto, no es necesario agregar el especificador de elementos a la clase (div.title) a menos que se encuentre en conflicto con otros elementos que tienen class = "title". No agregue peso innecesario, ya que es posible que necesite usar ese peso más adelante.

Muchas veces veré a 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 facilitarte volver más tarde y encontrar en qué estás trabajando.

hay un gran material aquí y algunos han tomado mucho tiempo para responder a esta pregunta, sin embargo, cuando se trata de hojas de estilo individuales o separadas, iría con archivos separados para el desarrollo y luego pasaré a tener todo su css genérico usado en todo el lugar combinado en un solo archivo cuando se implementa.

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

Deberías mirar a BEM .

Teoría

BEM es un intento de proporcionar un conjunto de instrucciones para organizar y nombrar los 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 llevan al código de espagueti y los 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 pasar por encima de otros

BEM funciona bien con SASS para llevar un estilo casi orientado a objetos a CSS. Puede crear archivos modulares, que controlan la visualización de un único 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 se resiste a esta idea, de hecho, los conceptos aplicados aportan muchas de las partes más agradables de las estructuras de OO, como la modularidad, el acoplamiento flojo y la cohesión estrecha y la reutilización sin contexto. Incluso puede construir de una forma que se parezca a un objeto encapsulado usando Sass y el &operador .

Un artículo más detallado de la revista Smashing se puede encontrar aquí ; y uno de Harry Roberts, de CCS Hechicería (que cualquier persona involucrada en CSS debe tener una lectura de) 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 algunos grandes desastres, a menudo de mi propia creación, sin experiencia.

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

.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 destacaría aquí es que, por pequeño que sea tu proyecto, aunque parezca poco complejo, deberías hacerlo desde el principio, por dos razones:

  • los proyectos aumentan en complejidad, por lo que es importante sentar las bases, 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. De acuerdo, no tiene que hacer ninguna codificación del lado del servidor, por lo que esa parte es simple, pero el folleto lleva la parte delantera. 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. Todavía no sé mucho sobre esto, pero buscan unir todas las funcionalidades de front-end en módulos independientes, intentando efectivamente aplicar el tipo de principios de BEM al front-end como un todo y se componen de componentes dispersos pero totalmente acoplados. elementos como los fragmentos de DOM, Js (MVC) y CSS que todos construyen el mismo widget 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 hacen que algunas de las otras arquitecturas frontales estén más cuerdas.

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

Finalmente

También creo que esta es una excelente y moderna guía de css mejor diseñada, diseñada específicamente para evitar que los grandes proyectos css se ensucien. Trato de seguir la mayoría de estos.

Los principios básicos para CSS sensible, extraídos de CSS Refactoring: De CSS solo para anexos a CSS modular

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

Nunca use un ID de HTML para el estilo; Siempre use clases . Los ID HTML, cuando se usan correctamente, aparecen solo una vez en toda la página, que es todo lo contrario de 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 un ID HTML es crear otro ID, lo que hace que los ID se propaguen en la base de código como las plagas que son. Es mejor dejar los ID de HTML para los enlaces de prueba de integración o Javascript invariables.

Nombre sus clases de 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". Codificar de esta manera significa que puedes reutilizar tus hojas de estilo existentes cuando juegas negocios paralelos. Por ejemplo, comenzamos a vender 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 solo se confundiría cuando se aplicara 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 sigue existiendo) un terrible anti-patrón en las comunidades de CSS en el que los diseñadores y creadores de marcos de CSS (tos Twitter Bootstrap ) creen que "span-2" o "cols-8" son nombres razonables para las clases de CSS. El punto de CSS es darle la posibilidad de modificar su diseño sin afectar el marcado (mucho). La codificación de los tamaños de las grillas en el HTML frustra este objetivo, por lo que se desaconseja en cualquier proyecto que se espera que dure más que un fin de semana. Más sobre cómo evitamos las clases de rejilla más tarde.

Divide tu CSS a través de 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ñas 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.

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

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

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

Te recomendaría que mires el Compass .