Con más personas que nunca escribiendo en Sass, vale la pena considerar cómo lo formateamos. Las guías de estilo CSS son comunes, por lo que quizás podamos extenderlas para cubrir opciones exclusivas de Sass.
Aquí hay algunas ideas hacia las que he estado gravitando. Quizás le sean útiles o le ayuden a formular sus propias ideas. Si está buscando más ejemplos, Sass Guidelines es otro buen lugar para buscar.
Utilice su guía de estilo / reglas de formato CSS habituales
Esta publicación trata sobre cosas específicas de Sass, pero como base para esto, debe seguir las buenas pautas de formato CSS que ya esté siguiendo. Si aún no lo ha hecho, este resumen de guías de estilo puede ayudarlo. Esto incluye cosas como:
- Sea consistente con la sangría
- Sea constante acerca de dónde van los espacios antes / después de los dos puntos / tirantes
- Un selector por línea, una regla por línea
- Enumere las propiedades relacionadas juntas
- Tenga un plan para nombrar los nombres de las clases
- No uses el #hotdrama de ID
- etc
Lista @extend (s) primero
.weather {
@extend %module;
...
}
Saber desde el principio que esta clase hereda otro conjunto completo de reglas de otros lugares es bueno. Otro beneficio es que la sustitución de estilos para ese conjunto de reglas heredado se vuelve mucho más fácil.
Saber cuándo usar @extend versus @include puede ser un poco complicado. Harry hace un buen trabajo al diferenciar los dos y ofrece ideas sobre cómo usarlos.
List @include (s) Siguiente
.weather {
@extend %module;
@include transition(all 0.3s ease-out);
...
}
El siguiente es su @includes para mixins y otras funciones. Nuevamente, es bueno tener esto cerca de la parte superior como referencia, pero también permite anulaciones. También es posible que desee realizar la llamada para separar @includes creados por el usuario y @includes proporcionados por el proveedor.
Lista de estilos “regulares” a continuación
.weather {
@extend %module;
@include transition(all 0.3s ease-out);
background: LightCyan;
...
}
Agregar estilos regulares después de @extends e @includes nos permite anular adecuadamente esas propiedades, si es necesario.
Pseudo clases y pseudo elementos anidados Siguiente
.weather {
@extend %module;
@include transition(all 0.3s ease-out);
background: LightCyan;
&:hover {
background: DarkCyan;
}
&::before {
content: "";
display: block;
}
...
}
Pseudo elementos y pseudo clases directamente relacionados con el elemento en sí, por eso, los anidamos primero antes que otros selectores. Tener pseudo elementos antes de las clases parece ser un poco más fácil de leer, pero si uno viene antes que el otro es totalmente una preferencia. De cualquier manera, sería mejor mantener los elementos con otros elementos y las clases con otras clases.
Últimos selectores anidados
.weather {
@extend %module;
@include transition(all 0.3s ease);
background: LightCyan;
&:hover {
background: DarkCyan;
}
&::before {
content: "";
display: block;
}
> h3 {
@include transform(rotate(90deg));
border-bottom: 1px solid white;
}
}
Nada va tras las cosas anidadas. Y se aplicaría el mismo orden que el anterior dentro del selector anidado.
Nunca escriba prefijos de proveedor
Los prefijos de proveedores son una cuestión urgente. A medida que los navegadores se actualizan con el tiempo, la necesidad de ellos desaparecerá. Si usa Autoprefixer, al compilar Sass, nunca debería tener que escribirlos.
Alternativamente, puede usar @mixins proporcionados por bibliotecas como Compass y Bourbon. O enrolle el suyo. Aunque usar @mixins para prefijos de proveedores es menos conveniente que Autoprefixer y aún requiere algo de mantenimiento, es mejor que tener que escribir las cosas manualmente.
Anidamiento máximo: tres niveles de profundidad
.weather {
.cities {
li {
// no more!
}
}
}
Lo más probable es que, si eres más profundo que eso, estás escribiendo un selector de mierda. Malo porque depende demasiado de la estructura HTML (frágil), demasiado específico (demasiado poderoso) y no muy reutilizable (no útil). También está al borde de ser difícil de entender.
Si realmente desea usar selectores de etiquetas porque la clase se está volviendo demasiado para usted, es posible que desee ser bastante específico al respecto para evitar una cascada no deseada. Y posiblemente incluso haga uso de @extend para que tenga el beneficio de la reutilización en el lado de CSS.
.weather
> h3 {
@extend %line-under;
}
}
Anidamiento máximo: 50 líneas
Si un bloque anidado de Sass es más largo que eso, es muy probable que no quepa en una pantalla del editor de código y comience a ser difícil de entender. El objetivo del anidamiento es la conveniencia y ayudar en la agrupación mental. No lo uses si te duele.
Los archivos Sass globales y específicos de la sección son solo una tabla de contenido
En otras palabras, no hay estilos directamente en ellos. Oblíguese a mantener todos los estilos organizados en partes componentes.
Enumere las dependencias globales / del proveedor primero, luego las dependencias del autor, luego los patrones y luego las partes
Termina siendo una tabla de contenido fácil de entender:
/* Vendor Dependencies */
@import "compass";
/* Authored Dependencies */
@import "global/colors";
@import "global/mixins";
/* Patterns */
@import "global/tabs";
@import "global/modals";
/* Sections */
@import "global/header";
@import "global/footer";
Las dependencias como Compass, colores y mixins no generan CSS compilado en absoluto, son dependencias puramente de código. Enumerar los patrones a continuación significa que las “partes” más específicas, que vienen después, tienen el poder de anular los patrones sin tener una guerra de especificidad.
Divida en tantos archivos pequeños como tenga sentido
No hay penalización por dividir en muchos archivos pequeños. Hágalo tanto como le sienta bien al proyecto. Sé que me resulta más fácil saltar a archivos específicos pequeños y navegar a través de ellos que menos o más grandes.
...
@import "global/header/header/";
@import "global/header/logo/";
@import "global/header/dropdowns/";
@import "global/header/nav/";
@import "global/header/really-specific-thingy/";
Probablemente haría esto bien en global.scss, en lugar de tener global @import un archivo _header.scss que tiene sus propias subimportaciones. Toda esa subimportación podría salirse de control.
Globbing podría ayudar si comienza a haber demasiados para enumerar.
Los parciales se denominan _partial.scss
Esta es una convención de nomenclatura común que indica que este archivo no debe compilarse por sí mismo. Es probable que tenga dependencias que harían imposible la compilación por sí mismo. Personalmente, me gustan los guiones en el nombre de archivo “real”, como _dropdown-menu.scss.
Compilar localmente con mapas de origen
En desarrollo, probablemente no importa en qué formato compile su Sass (por ejemplo, expandido, comprimido, etc.) localmente siempre que esté produciendo mapas de origen.
Es una bandera cuando compilas Sass:
$ sass sass/screen.scss:stylesheets/screen.css --sourcemap
Aunque probablemente no compile Sass de esa manera normalmente, siempre hay algún tipo de forma de configurar lo que está usando para compilar Sass para que lo haga con mapas de origen. Cuando los tienes, eso significa que DevTools te muestra dónde está el código Sass, lo cual es super (duper) útil:
Aquí hay algunos enlaces relevantes sobre esto:
- (Google) Trabajar con preprocesadores CSS
- (The Sass Way) Uso de mapas de origen con Sass 3.3
En implementación, compilar comprimido
Los sitios web activos solo deberían tener CSS comprimido. Y con gzip con encabezados far-our expira para arrancar.
Ni siquiera confirme archivos .css
Esto puede requerir algo de trabajo de DevOps, pero es bastante bueno si los archivos .css ni siquiera están en su repositorio. La compilación ocurre durante la implementación. Entonces, lo único que ve en el repositorio son sus archivos Sass creados a mano con un formato agradable. Esto también hace que las diferencias sean útiles. Una diferencia es una vista de comparación de los cambios proporcionados por los proveedores de control de versiones. La diferencia de un archivo CSS comprimido es inútil.
Sea generoso con los comentarios
Es raro arrepentirse de haber dejado un comentario en código. Es útil o fácilmente ignorable. Los comentarios se eliminan cuando se compilan en código comprimido, por lo que no hay ningún costo.
.overlay {
// modals are 6000, saving messages are 5500, header is 2000
z-index: 5000;
}
Y hablando de comentarios, es posible que desee estandarizar eso. El //
La sintaxis en Sass es bastante buena, especialmente para bloques de comentarios, por lo que es más fácil comentar / descomentar líneas individuales.
Variable de todos los números comunes y los números con significado
Si se encuentra usando un número que no sea 0 o 100% una y otra vez, probablemente merezca una variable. Dado que probablemente tiene un significado y controla la coherencia, puede ser útil poder modificarlo en masa.
Si un número claramente tiene un significado fuerte, ese también es un caso de uso para la variabilidad.
$zHeader: 2000;
$zOverlay: 5000;
$zMessage: 5050;
.header {
z-index: $zHeader;
}
.overlay {
z-index: $zOverlay;
}
.message {
z-index: $zMessage;
}
Idealmente, esos números probablemente deberían mantenerse en un archivo separado @ import-ed como una dependencia. De esa manera, puede realizar un seguimiento de toda su pila de índice Z en un solo lugar. Sin embargo, si las variables están dentro del ámbito de la clase, entonces tendría sentido asegurarse de que estén primero antes que cualquier otra regla.
.accordion {
$accordion-header-color: $primary-color;
$accordion-padding: 1em;
@extend %module;
@include transition(all 0.3s ease-out);
background: $accordion-header-color;
padding: $accordion-padding;
}
Variable todos los colores
Excepto quizás blanco y negro. Lo más probable es que un color no sea único, e incluso si crees que lo es, una vez que esté en una variable, es posible que veas usos para él en otros lugares. Las variaciones de ese color a menudo pueden ser manejadas por las funciones de color de Sass como aclarar () y oscurecer (), que facilitan la actualización de colores (cambio en un lugar, actualizaciones del esquema de color completo).
Anidar y nombrar sus consultas de medios
La capacidad de anidar consultas de medios en Sass significa que 1) no tiene que volver a escribir el selector en otro lugar, lo que puede ser propenso a errores 2) las reglas que está anulando son muy claras y obvias, lo que generalmente no es el caso cuando están en la parte inferior de su CSS o en un archivo diferente.
.sidebar {
float: right;
width: 33.33%;
@include bp(mama-bear) {
width: 25%;
}
}
Más sobre esto y la importancia de nombrarlos bien.
Vergüenza por último
En su hoja de estilo global, @importar un archivo _shame.scss al final.
@import "compass"
...
@import "shame"
Si necesita hacer una solución rápida, puede hacerlo aquí. Más tarde, cuando tenga el tiempo adecuado, puede mover la solución a la estructura / organización adecuada. Ver más.
El resultado final depende de usted
Sass no hace nada que no le digas que haga, por lo que afirmar que la salida de Sass está inflada es solo afirmar que escribes código inflado. Escriba Sass de manera que la salida CSS final sea tal como la hubiera escrito sin Sass.