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
simplicity,complexity,maintenance,structureyrefactoring.