2012-07-24 706 views
30

(esto puede haber sido respondido ya - no pudo encontrar la respuesta)¿Hay alguna ventaja en agrupar consultas de medios css juntas?

La anulación de la consulta @media tradicional tiende a agrupar toda la anulación para un tamaño/medio bajo el mismo grupo de corchetes.

p. Ej.

.profile-pic { 
    width:600px; 
} 
.biography { 
    font-size: 2em; 
} 

@media screen and (max-width: 320px) { 
    .profile-pic { 
     width: 100px; 
     float: none; 
    } 
    .biography { 
     font-size: 1.5em; 
    } 
} 

En Sass, hay una manera muy ingeniosa para escribir @media anulaciones de consulta anidada dentro de la declaración, así:

.profile-pic { 
width:600px; 
    @media screen and (max-width: 320px) { 
    width: 100px; 
    float: none; 
    } 
} 

.biography { 
    font-size: 2em; 
    @media screen and (max-width: 320px) { 
    font-size: 1.5em; 
    } 
} 

ahora, cuando se compila, Sass no agrupa la consulta @media bloques juntos, por lo que la salida termina siendo algo como esto:

.profile-pic { 
    width:600px; 
} 
@media screen and (max-width: 320px) { 
    .profile-pic { 
    width: 100px; 
    float: none; 
    } 
} 

.biography { 
    font-size: 2em; 
} 
@media screen and (max-width: 320px) { 
    .biography { 
    font-size: 1.5em; 
    } 
} 

que he usado esta técnica para un proyecto reciente, y cuando se aplica ese principio a un proyecto mucho más grande que terminan con mu La sección de consulta de @media media difundida a través de su CSS (tengo alrededor de 20 hasta ahora).

Me gusta bastante la técnica sass ya que facilita el seguimiento del flujo de anulaciones (y también hace que sea más fácil mover las cosas).

Sin embargo, me pregunto si hay alguna desventaja al tener una sección @media múltiple a través del CSS, especialmente en lo que respecta al rendimiento.

He intentado el profiler de crome css, pero no pude ver nada específico de las consultas de @media.

(More info on @media in sass on this page)

Respuesta

16

Un poco tarde a la fiesta, pero en base a las pruebas por debajo del impacto en el rendimiento parece ser mínima. La prueba muestra los tiempos de renderización para una página de ejemplo con 2000 consultas de medios separadas y combinadas, respectivamente.

http://aaronjensen.github.com/media_query_test/

La ventaja principal parece ser en tamaño de archivo más que cualquier otra cosa - lo cual, si está comprimiendo el CSS para la producción, se reducirá sustancialmente todos modos.

Pero en última instancia, ya que el puesto vinculado a continuación pone:

"Si usted tiene 2000 + preguntas de los medios en el CSS, creo que es posible que desee reconsiderar su estrategia de desarrollo de interfaz de usuario en comparación con el uso de una joya de reprocesa tu CSS ".

Blog post detallando el problema: http://sasscast.tumblr.com/post/38673939456/sass-and-media-queries

+0

Gracias por esta referencia, eso es perfecto. Buen hallazgo Intenté la prueba de consultas 2000 varias veces en Chrome en iPhone 4s y no parece haber ninguna diferencia significativa. – Ben

1

Yo asumiría que acaba de tener que ejecutar la verificación de consulta de medios una vez (y después de cargar todos los estilos dentro de él) sería menos exigente que la comprobación de cada selector pero no tengo duro evidencia de esto Si obtienes el Canary release of Chrome, hay herramientas de consulta de medios allí.

Como estás usando SASS este artículo podría ser de algún interés - http://css-tricks.com/media-queries-sass-3-2-and-codekit/

+0

Gracias. No uso codekit pero gracias, otros pueden encontrarlo útil. Con respecto a la versión canaria, ¿a qué herramientas en particular se refiere? – Ben

+0

Hay una nueva auditoría para los selectores de CSS que le indica cuánto tarda en ejecutarse cada uno. Podría ser útil. – SpaceBeers

+0

Tengo canarias pero no tuve suerte. ¿Te refieres a la pestaña _Profiles_ en las herramientas de desarrollo? También hay una pestaña de Auditorías por separado, pero ninguna parece incluir nada para las consultas de medios. – Ben

Cuestiones relacionadas