2009-08-14 32 views
11

En la creación de estilos CSS un enfoque parece ser un estilo completamente calificado como¿Son eficientes los estilos CSS totalmente calificados?

#pnlImage div.ipd-imageInfo div.ipd-tags span.ipd-tag 

en comparación con una definición más corta como

div.ipd-tags span.ipd-tag 

que identificar de forma única el estilo también. Sin embargo, si el sitio se expande o cambia, el segundo estilo corre el riesgo de no identificar el elemento de manera única.

¿Hay algún impacto en el rendimiento al calificar completamente un estilo, es decir, es más largo? ¿Existen algunas pautas/referencias de mejores prácticas para el nombramiento de estilo?

Gracias

+0

whats a ipd-tags? –

+0

Supongo que algo específico de la aplicación – nickf

+0

Si el sitio cambia, el * primer * método también corre el riesgo de no identificar los elementos correctos. – nickf

Respuesta

5
  1. Mirando hacia arriba una #id es rápida.
  2. Buscar un tag es un poco más lento.
  3. Buscar un .class es el más lento.

Al iniciar sus selectores con una búsqueda más rápida reducirá el número de búsquedas necesarias para la próxima parte. Es decir, si escribí p.myClass, el navegador puede encontrar rápidamente todas las etiquetas p y luego solo tiene que recorrerlas para verificar el nombre de la clase.

Dicho esto, calificaría la mantenibilidad de su archivo CSS más alta que su velocidad de representación. Blah blah blah Optimización prematura, bla, bla.

+0

Mi implementación no funciona así. El algoritmo que implementé es "para cada elemento en el DOM, vea qué reglas se seleccionan (es decir, obtener del conjunto de reglas las reglas cuyos selectores coinciden con el elemento), y luego aplicar el algoritmo en cascada". Por lo tanto, cualquier selector simple (etiqueta, clase, ID) tarda aproximadamente la misma cantidad de tiempo (para probar si coincide con el elemento DOM en cuestión). Los selectores compuestos tardan más tiempo (tomar un tiempo que es linealmente proporcional al número de antepasados ​​que tiene el elemento DOM). – ChrisW

+2

* su * algoritmo? ¿Estás escribiendo tu propio motor de CSS? – nickf

+0

Sí, lo soy. Pero este es el algoritmo que me pareció sugerido por las especificaciones: la API entre mi procesador de HTML y mi analizador de CSS es como http://www.w3.org/TR/DOM-Level-2-Style/css.html# CSS-ViewCSS que invoco para cada elemento en el DOM (como una optimización del rendimiento, para elementos DOM suficientemente similares, el analizador CSS devuelve los resultados de la memoria caché). ¿Realmente está diciendo que el algoritmo utilizado por otras implementaciones de navegador es "para cada regla CSS, encuentre elementos DOM" en lugar de "para cada elemento DOM, encuentre reglas CSS"? Y si es así, ¿tienes alguna idea de por qué lo harían así? – ChrisW

0

No veo cómo una respuesta teórica es posible: la respuesta depende de la implementación; entonces te sugiero que lo perfiles para estar seguro.

0

¿Hay algún impacto en el rendimiento que califique por completo un estilo, es decir, es más largo?

Sí, en cada cambio dinámico del árbol DOM, la expresión CSS debe reproducirse al menos contra algunos nodos. Sin embargo, dudo que esto lleve a una demora notable.

Su objetivo declarado (hacer que los selectores sean robustos frente a cambios en la estructura de la página) no es sólido: la codificación de detalles intrincados sobre la estructura del sitio en CSS solo significa que tendrá más declaraciones para mantener y actualizar cuando cambios en la estructura de la página

Si está bajo su control, siga las clases simples (incluso si tiene más) y el menor número posible de niveles (haciendo un tamaño relativo de fuentes es el único caso de uso donde he usado varios niveles, e incluso esto fue algo superfluo). Simplemente desperdicia demasiada capacidad cognitiva para realizar un seguimiento de la estructura de la página en tu cabeza.

7

Google (not a search, actually them) seems to think that it does cause a performance hit.

Además, la fundación Mozilla tiene un artículo "Writing Efficient CSS for use in the Mozilla UI" que describe las posibles dificultades de rendimiento de los selectores CSS en su navegador (s), y cómo optimizar sus reglas de estilo para su motor de renderizado. Su artículo tiene toneladas de ejemplos de lo que es bueno y lo que es malo. Sin embargo, tenga en cuenta que esto solo es relevante para sus navegadores.

Hay también algunos puntos de referencia están disponibles al público, sobre los selectores CSS afectan a velocidades de visualización:

Yo, sin embargo, creo que esto es, en su mayor parte, estiércol de caballo. Puede realizar un cambio LEJANO mayor en la velocidad de carga/renderización de su página utilizando otras optimizaciones simples. Creo que su cordura y una base de código bien organizada deberían ser lo primero. Si esto fuera tan importante como algunos creen, todos estaríamos usando los atributos HTML < 4 (bgcolor =, border =, etc.) para dar estilo a nuestras páginas web.

1

Usted podría estar interesado en David Baron (Mozilla) 's Google Tech talk.

+0

+1 muy relevante. La descripción de la coincidencia del selector de CSS comienza alrededor del tiempo 0:15:40. – ChrisW

0

Aunque tu pregunta es sobre el rendimiento (y sugeriría, mídela ...) Me gustaría agregar que siempre debes intentar usar la definición más corta posible para identificar los elementos correctos.

La razón no es el tamaño del archivo, sino la capacidad de ampliar su sitio sin alterar el CSS principal.

Por ejemplo, usted tiene esta parte en su sitio html:

<div id="Header"> 
    <h1>Css example</h1> 
    <h2>Welcome to the css example site</h2> 
    <p>An example page by davy</p> 
</div> 

y este es el css:

#Header 
{ 
    background-color: #ffeedd; 
    padding: 1em; 
} 
#Heading h1 
{ 
    font-size: 3em; 
    color: #333; 
} 
#Heading h2 
{ 
    font-size: 1.5em; 
    color: #666; 
} 
#Heading p 
{ 
    margin: 0 0.5em 1.5em 1em; 
    font-size: 1.1em; 
    color: #999; 
} 

Y más tarde se obtendría a una página donde' Me gusta que tu encabezado tenga un fondo diferente.

Si eligió usar div#Header en su archivo css principal, tendría que cambiar el html (que según su sistema podría significar crear una plantilla/página maestra diferente) para agregar una clase adicional, o crear una selector css calificado como body div#Header.

Utilizando el selector más corto todavía puede usar div#Header { background : ... } para cambiar su encabezado. Puede crear un archivo css adicional y cargarlo en su encabezado en esa página (si está permitido) o agregar una definición de estilo directamente a su sección <head>. Lo bueno de esto es que su archivo CSS no crece con los selectores para cada página diferente, y puede mantenerse alejado de classitis.

También podría usarlo para cambiar el método de tamaño de su página (estático/fluido) de modo que una plantilla/página maestra use el CSS predeterminado, y el otro se deriva de esa plantilla/página maestra y simplemente vincula un CSS llamado FluidWitdth90. CSS para cambiar la plantilla a un diseño fluido de 90% de ancho.

+0

Solo para asegurarme de que lo entiendo correctamente, ¿el ejemplo que proporciona es el enfoque preferido? En lugar del estilo más completo y calificado que utilicé, hágalos más cortos y más específicos solo para ese elemento para que puedan ser reemplazados. – ChrisP

+0

Mi regla es usar siempre el selector menos específico posible. Así que tendría aproximadamente 3/4 veces para anular el estilo con otros archivos css al ser más específico. –

1

Tengo un sitio donde otro diseñador usó estilos altamente calificados y el mantenimiento es una pesadilla. (los estilos calificados son solo una parte de eso)

Básicamente, no se puede tocar o simplificar la estructura html sin romper la mitad de los estilos, y los estilos a menudo no se conectan correctamente a las nuevas adiciones de contenido. Si agrega una nueva CSS, a su vez tiene que calificar sus nuevas reglas en gran medida o la mitad de ellas quedan anuladas por alguna regla existente porque contiene mucha especificidad.

Por lo tanto, desde el punto de vista del mantenimiento no es eficiente. Tampoco es eficiente desde un punto de vista de tipeo.

Cuestiones relacionadas