html - nuevos - selector padre css

¿Por qué los navegadores coinciden con los selectores de CSS de derecha a izquierda? (3)

Los selectores de CSS coinciden con los motores del navegador de derecha a izquierda. Así que primero encuentran a los niños y luego verifican a sus padres para ver si coinciden con el resto de las partes de la regla.

¿Por qué es esto?
¿Es solo porque la especificación dice?
¿Afecta el diseño final si se evaluó de izquierda a derecha?

Para mí, la forma más sencilla de hacerlo sería utilizar los selectores con el menor número de elementos. Así que las identificaciones primero (ya que solo deben devolver 1 elemento). Entonces, tal vez las clases o un elemento que tenga la menor cantidad de nodos; por ejemplo, solo puede haber un intervalo en la página, así que vaya directamente a ese nodo con cualquier regla que haga referencia a un intervalo.

Aquí hay algunos enlaces que respaldan mis reclamos.

Parece que se hace de esta manera para evitar tener que mirar a todos los hijos de los padres (que podrían ser muchos) en lugar de a todos los padres de un niño que deben ser uno. Incluso si el DOM es profundo, solo miraría un nodo por nivel en lugar de múltiples en la coincidencia RTL. ¿Es más fácil / rápido evaluar los selectores de CSS LTR o RTL?

El análisis de derecha a izquierda, también llamado análisis de abajo hacia arriba, es realmente eficaz para el navegador.

Considera lo siguiente:

#menu ul li a { color: #00f; }

El navegador primero busca a , luego li , luego ul , y luego #menu .

Esto se debe a que a medida que el navegador escanea la página, solo necesita mirar el elemento / nodo actual y todos los nodos / elementos anteriores que ha escaneado.

Lo que hay que tener en cuenta es que el navegador comienza a procesarse en el momento en que obtiene una etiqueta / nodo completos y no tiene que esperar toda la página, excepto cuando encuentra un script, en cuyo caso se detiene temporalmente y completa la ejecución del script y luego va hacia adelante

Si lo hace al revés, será ineficaz porque el navegador encontró el elemento que estaba escaneando en la primera comprobación, pero luego se vio obligado a continuar mirando a través del documento para todos los selectores adicionales. Para esto, el navegador debe tener el código HTML completo y es posible que deba escanear toda la página antes de que comience a pintar CSS.

Esto es contrario a la manera en que la mayoría de las bibliotecas analizan el dominio. Allí se construye el dom y no es necesario escanear toda la página, solo encuentra el primer elemento y luego sigue coincidiendo con otros dentro de ella.

Permite la conexión en cascada de lo más específico a lo menos específico. También permite un cortocircuito en la aplicación. Si la regla más específica se aplica a todos los aspectos a los que se aplica la regla principal, se ignoran todas las reglas principales. Si hay otros bits en el padre, se aplican.

Si fuera al revés, daría formato de acuerdo con el padre y luego sobrescribiría cada vez que el niño tuviera algo diferente. A largo plazo, esto es mucho más trabajo que ignorar los elementos de las reglas que ya están vigiladas.

Tenga en cuenta que cuando un navegador está haciendo una selección del selector, tiene un elemento (para el que está tratando de determinar el estilo) y todas sus reglas y sus selectores, y necesita encontrar qué reglas coinciden con el elemento. Esto es diferente de lo habitual en jQuery, por ejemplo, donde solo tienes un selector y necesitas encontrar todos los elementos que coincidan con ese selector.

Si solo tenía un selector y solo un elemento para comparar con ese selector, entonces de izquierda a derecha tiene más sentido en algunos casos. Pero esa es decididamente no la situación del navegador. El navegador está tratando de mostrar Gmail o lo que sea y tiene el <span> que está tratando de diseñar y las más de 10,000 reglas que Gmail coloca en su hoja de estilo (no estoy inventando ese número).

En particular, en la situación en que el navegador está mirando la mayoría de los selectores que está considerando no coinciden con el elemento en cuestión. Entonces, el problema se convierte en decidir que un selector no coincide lo más rápido posible; Si eso requiere un poco de trabajo adicional en los casos que coinciden, aún así ganará debido a todo el trabajo que ahorra en los casos que no coinciden.

Si comienza por hacer coincidir la parte más a la derecha del selector con su elemento, entonces es probable que no coincida y haya terminado. Si coincide, tiene que hacer más trabajo, pero solo proporcional a la profundidad de su árbol, que no es tan grande en la mayoría de los casos.

Por otro lado, si comienzas por hacer coincidir la parte más a la izquierda del selector ... ¿contra qué lo emparejas? Tienes que empezar a recorrer el DOM, buscando nodos que puedan coincidir. El simple hecho de descubrir que no hay nada que coincida con la parte izquierda puede llevar un tiempo.

Así que los navegadores coinciden desde la derecha; proporciona un punto de partida obvio y le permite deshacerse de la mayoría de los selectores de candidatos muy rápidamente. Puedes ver algunos datos en http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b185e455a0b3562a/7db34de545c17665 (aunque la notación es confusa), pero el resultado final es que Gmail en particular hace dos años, para el 70% de los pares (regla, elemento), podría decidir que la regla no coincide solo después de examinar las partes de etiqueta / clase / identificación del selector de la derecha para la regla. El número correspondiente al conjunto de pruebas de rendimiento de carga de página de Mozilla fue del 72%. Por lo tanto, realmente vale la pena intentar deshacerse de esos 2/3 de todas las reglas lo más rápido posible y solo preocuparse por igualar el 1/3 restante.

Tenga en cuenta también que ya hay otras optimizaciones que los navegadores hacen para evitar incluso intentar cumplir reglas que definitivamente no coincidirán. Por ejemplo, si el selector de la derecha tiene un ID y ese ID no coincide con el ID del elemento, entonces no habrá ningún intento de hacer coincidir ese selector con ese elemento en absoluto en Gecko: el conjunto de "selectores con ID" que se intentan proviene de una búsqueda de tabla hash en el ID del elemento. Así que este es el 70% de las reglas que tienen una buena probabilidad de emparejamiento que aún no coinciden después de considerar solo la etiqueta / clase / id del selector de la derecha.