Por que os navegadores correspondem aos seletores de CSS da direita para a esquerda?

Os seletores CSS são correspondidos pelos mecanismos do navegador da direita para a esquerda. Então, eles primeiro encontram as crianças e depois checam os pais para ver se elas correspondem ao restante das partes da regra.

1. Por que é isso?
2. É apenas porque a especificação diz?
3. Isso afeta o layout final se for avaliado da esquerda para a direita?

Para mim, a maneira mais simples de fazer isso seria usar os seletores com o menor número de elementos. Portanto, os IDs primeiro (como devem retornar apenas 1 elemento). Então talvez classes ou um elemento que tenha o menor número de nós - por exemplo, pode haver apenas um período na página; portanto, vá diretamente para esse nó com qualquer regra que faça referência a um período.

Aqui estão alguns links para fazer backup de minhas reivindicações

1. http://code.google.com/speed/page-speed/docs/rendering.html
2. https://developer.mozilla.org/en/Writing_Efficient_CSS

Parece que isso é feito dessa maneira para evitar ter que olhar para todos os filhos dos pais (que podem ser muitos) e não para todos os pais de um filho que deve ser um. Mesmo que o DOM seja profundo, ele analisaria apenas um nó por nível, em vez de vários na correspondência RTL. É mais fácil / rápido avaliar os seletores CSS LTR ou RTL?

Lembre-se de que, quando um navegador faz a correspondência de seletores, ele tem um elemento (aquele para o qual está tentando determinar o estilo) e todas as suas regras e seus seletores, e ele precisa descobrir quais regras correspondem ao elemento. Isso é diferente da coisa usual do jQuery, digamos, onde você só tem um seletor e precisa encontrar todos os elementos que correspondem a esse seletor.

Se você tiver apenas um seletor e apenas um elemento para comparar com esse seletor, da esquerda para a direita faz mais sentido em alguns casos. Mas essa definitivamente não é a situação do navegador. O navegador está tentando renderizar o Gmail ou o que quer que seja e possui o <span>que está tentando estilizar e as mais de 10.000 regras que o Gmail coloca em sua folha de estilo (não estou inventando esse número).

Em particular, na situação em que o navegador está olhando a maioria dos seletores que está considerando , não corresponde ao elemento em questão. Portanto, o problema passa a ser decidir se um seletor não corresponde o mais rápido possível; se isso exigir um pouco de trabalho extra nos casos correspondentes, você ainda ganha devido a todo o trabalho que você salva nos casos que não correspondem.

Se você começar apenas combinando a parte mais à direita do seletor com o seu elemento, é provável que não corresponda e pronto. Se corresponder, você precisará fazer mais trabalho, mas apenas proporcional à profundidade da sua árvore, o que não é tão grande na maioria dos casos.

Por outro lado, se você começar combinando a parte mais à esquerda do seletor ... contra o que você o combina? É necessário começar a percorrer o DOM, procurando nós que possam corresponder a ele. Apenas descobrir que não há nada que corresponda à parte mais à esquerda pode demorar um pouco.

Portanto, os navegadores correspondem da direita; fornece um ponto de partida óbvio e permite que você se livre da maioria dos seletores de candidatos rapidamente. Você pode ver alguns dados em http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b185e455a0b3562a/7db34de545c17665 (embora a notação seja confusa), mas o resultado é o Gmail em particular há dois anos, para 70% dos pares (regra, elemento) você pode decidir que a regra não corresponde depois de apenas examinar as partes de tag / class / id do seletor mais à direita da regra. O número correspondente para o conjunto de testes de desempenho de carregamento de páginas da Mozilla foi de 72%. Portanto, vale a pena tentar livrar-se dessas 2/3 de todas as regras o mais rápido possível e só se preocupar em combinar as 1/3 restantes.

Observe também que existem outras otimizações que os navegadores já fazem para evitar tentar corresponder a regras que definitivamente não coincidem. Por exemplo, se o seletor mais à direita tiver um ID e esse ID não corresponder ao ID do elemento, não haverá nenhuma tentativa de corresponder esse seletor com esse elemento no Gecko: o conjunto de "seletores com IDs" tentados vem de uma pesquisa de hashtable no ID do elemento. Portanto, essas são 70% das regras que têm uma boa chance de correspondência que ainda não coincidem depois de considerar apenas a tag / classe / ID do seletor mais à direita.

A análise da direita para a esquerda, também chamada de análise de baixo para cima, é realmente eficiente para o navegador.

Considere o seguinte:

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

O navegador primeiro verifica a, depois li, depois ule depois #menu.

Isso ocorre porque, como o navegador está varrendo a página, ele precisa apenas olhar o elemento / nó atual e todos os nós / elementos anteriores que ele varreu.

O ponto a ser observado é que o navegador começa a processar no momento em que obtém uma tag / nó completo e não precisa esperar a página inteira, exceto quando encontra um script, caso em que pausa temporariamente e conclui a execução do script e, em seguida, avança.

Se ocorrer o contrário, será ineficiente porque o navegador encontrou o elemento que estava sendo digitalizado na primeira verificação, mas foi forçado a continuar procurando no documento todos os seletores adicionais. Para isso, o navegador precisa ter o html inteiro e pode precisar digitalizar a página inteira antes de iniciar a pintura em css.

Isso é contrário ao modo como a maioria das bibliotecas analisa. Lá, o dom é construído e não é necessário escanear a página inteira, basta encontrar o primeiro elemento e, em seguida, continuar a combinar outros dentro dele.

Permite cascata do mais específico para o menos específico. Também permite um curto-circuito na aplicação. Se a regra mais específica se aplicar a todos os aspectos aos quais a regra pai se aplica, todas as regras pai serão ignoradas. Se houver outros bits no pai, eles serão aplicados.

Se você seguisse o caminho inverso, formataria de acordo com o pai e substituiria toda vez que a criança tiver algo diferente. A longo prazo, isso é muito mais trabalhoso do que ignorar itens nas regras já tratadas.