¿Sass daña el rendimiento?

Question

He estado educando a mí mismo. Lectura this:

El motor evalúa cada regla de derecha a izquierda, comenzando desde el selector de más a la derecha (llamada la "llave") y moviéndose a través de cada selector hasta que se encuentra una coincidencia o descarta la regla. (El "selector" es el elemento documento al que se aplique la regla.)

Por ejemplo:

ul li a {...} 
#footer h3 {...} 
* html #atticPromo ul li a {...] 

Ahora, algunas salidas de código de ejemplo SASS para mí:

#content #blog { 
    /* ... */ 
} 
/* line 85, ../sass/screen.scss */ 
#content #flickr { 
    /* ... */ 
} 

#content #flickr div p { 
    /* ... */ 
} 

Esto parece un poco incómodo. ¿Estoy haciendo algo mal? ¿Este es un problema de comunicación entre Sass y yo? ¿Lo estamos perdiendo?

Editar: Parte del código SCSS:

#flickr { 
    @include columns(5,8); 
    background: url('../img/ipadbg.png') no-repeat; 

    #ipod-gloss { 
     z-index: 999; 
     position: relative; 
    } 

    div { 
     margin-top: -80px; 
     margin-right: 20px; 

     h2 { 
      color: $white; 
      font-size: 24px; 
     } 

     p { 
      margin-top: 40px; 
     } 
    } 
} 

Bono lado!: el artículo dice que los navegadores (o al menos Firefox) buscan los selectores de derecha a izquierda. No podía entender por qué esto es más eficiente por qué. ¿Alguna pista?

Answer 1

usted tiene que encontrar su compromiso entre la facilidad de mantenimiento (anidación hace que sea más fácil encontrar su camino alrededor de la hoja de estilo) y el rendimiento de la representación.

Una regla empírica dice que debe intentar restringirse a una anidación de tres niveles y debe evitar anidar identificadores si no es necesario.

Sin embargo, creo que anidar demasiado no es el mayor problema. Tan pronto como me di cuenta del poder de los mixins, los usé mucho.

Por ejemplo, este es mi uso frecuente mixin botón:

@mixin small-button($active-color: $active-color, $hover-color: $button-hover-color, $shadow: true) 
    display: inline-block 
    padding: 4px 10px 
    margin: 
    right: 10px 
    bottom: 10px 
    border: none 
    background-color: $button-color 
    color: $font-color-inv 
    +sans-serif-font(9px, 700) 
    text-align: center 
    text-transform: uppercase 
    cursor: pointer 
    @if $shadow 
    +light-shadow 
    &:hover 
    text-decoration: none 
    background-color: $hover-color 
    &:last-child 
    margin-right: 0 
    a 
    color: $font-color-inv 
    &, &:hover 
     text-decoration: none 
    &.disabled 
    +opacity(0.75) 
    &:hover 
     background-color: $button-color 
    &.active 
    background-color: $active-color 
    &.disabled:hover 
     background-color: $active-color 

Ves, todo un código de bits. La aplicación de tales mixins a muchos elementos en su página resultará en un gran archivo CSS que tarda más tiempo en ser interpretado.

En la antigua forma de CSS, le daría a cada elemento del botón, p. la clase .small-button. Pero este método contamina tu marcado con clases no semánticas.

Sass proporciona una solución: herencia de selector a través del @extend directive.

Si los valores por omisión de su parámetro de la mixin, también puede proporcionar una clase simple, que utiliza los mixins con su defecto:

// Use this mixin via @extend if you are fine with the parameter defaults 
.small-button 
    +small-button 

Y a continuación, sólo puede heredar de esta clase en diversos contextos :

#admin-interface 
    input[type=submit] 
    @extend .small-button 

La declaración CSS resultante agrega todos los usos de .small botón en una regla con selectores separados por comas:

.small-button, #admin-interface input[type=submit] { 
    display: inline-block; 
    ... 
} 

En conclusión, un uso ingenuo de Sass puede afectar su rendimiento de CSS. Si se usa sabiamente, sin embargo, es mantenible gracias a un código DRY bien estructurado, conduce a una separación adecuada de marcado y estilo (solo clases semánticas) y permite un código CSS inteligente y de rendimiento.

Answer 2

SASS es solo un lenguaje que se compila en CSS. Si le preocupa el rendimiento de SASS en términos de cómo se ejecuta en el navegador, entonces SASS no ingresa la ecuación: se compilará y se publicará en el navegador como CSS regular.

---

Por lo que puedo ver de su uso de SASS, hay un par de cosas que podría sugerir:

1. Usted no tiene para anidar todo.

La capacidad de anidar reglas dentro de cada uno en SASS es una función de idioma, pero no tiene que hacerlo si no tiene sentido hacerlo.

---

En términos de su uso general CSS:

1. Si el anidamiento se vuelve demasiado severa/unwieldly, considerar el uso de clases donde tiene sentido.
2. Cuando es necesario usar la jerarquía de elementos DOM, considere usar el [combinador infantil]: .foo > .bar.

Los ID deben ser únicos, por lo tanto, siempre deben hacer referencia solo a un solo elemento. La mayoría de las veces, pueden ser reglas CSS en sí mismas, por ejemplo, #content #flickr se convertiría en #flickr, y los navegadores optimizarán la búsqueda de una única ID. La única vez que necesitaría algo como #id1 #id2 es si #id2 debe aparecer en diferentes contextos en páginas diferentes.

Si su selector contiene elementos como #id div p, ese div es superfluo o sirve para un propósito específico.

• Si es superflua, cambiar la regla de #id p, que selecciona cualquier <p> que se produce como un descendiente de #id.
• Si sirve para un propósito específico, considere clasificar el <div> con un nombre de clase que describa su propósito, quizás <div class="photos-list">. Entonces su CSS podría convertirse en .photos-list p, que es mucho más fácil de mantener y reutilizable.

---