Perché i browser corrispondono ai selettori CSS da destra a sinistra?

I selettori CSS sono abbinati dai motori del browser da destra a sinistra. Quindi prima trovano i bambini e poi controllano i loro genitori per vedere se corrispondono al resto delle parti della regola.

1. Perchè è questo?
2. È solo perché dice la specifica?
3. Influisce sul layout finale se è stato valutato da sinistra a destra?

Per me il modo più semplice per farlo sarebbe usare i selettori con il minor numero di elementi. Quindi prima gli ID (in quanto dovrebbero restituire solo 1 elemento). Quindi forse le classi o un elemento che ha il minor numero di nodi, ad esempio potrebbe esserci solo un intervallo nella pagina, quindi vai direttamente a quel nodo con qualsiasi regola che fa riferimento a un intervallo.

Ecco alcuni link a sostegno delle mie affermazioni

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

Sembra che sia fatto in questo modo per evitare di guardare tutti i figli dei genitori (che potrebbero essere molti) piuttosto che tutti i genitori di un figlio che devono essere uno. Anche se il DOM è profondo, guarderebbe solo un nodo per livello anziché multiplo nella corrispondenza RTL. È più facile / veloce valutare i selettori CSS LTR o RTL?

Tieni presente che quando un browser esegue la corrispondenza del selettore ha un elemento (quello per cui sta cercando di determinare lo stile) e tutte le tue regole e i relativi selettori e deve trovare quali regole corrispondono all'elemento. Questo è diverso dalla solita cosa jQuery, diciamo, dove hai solo un selettore e devi trovare tutti gli elementi che corrispondono a quel selettore.

Se hai solo un selettore e un solo elemento da confrontare con quel selettore, in alcuni casi ha più senso da sinistra a destra. Ma questa non è decisamente la situazione del browser. Il browser sta provando a eseguire il rendering di Gmail o qualsiasi altra cosa e ha quello <span>che sta cercando di modellare e le oltre 10.000 regole che Gmail inserisce nel suo foglio di stile (non sto inventando quel numero).

In particolare, nella situazione in cui il browser sta osservando la maggior parte dei selettori che sta considerando , non corrisponde all'elemento in questione. Quindi il problema diventa quello di decidere che un selettore non corrisponde il più velocemente possibile; se ciò richiede un po 'di lavoro extra nei casi che corrispondono, vinci comunque a causa di tutto il lavoro che risparmi nei casi che non corrispondono.

Se inizi semplicemente abbinando la parte più a destra del selettore con il tuo elemento, allora è probabile che non corrisponda e il gioco è fatto. Se corrisponde, devi fare più lavoro, ma solo in proporzione alla profondità dell'albero, che nella maggior parte dei casi non è così grande.

D'altra parte, se inizi abbinando la parte più a sinistra del selettore ... a cosa lo abbini? Devi iniziare a camminare sul DOM, alla ricerca di nodi che potrebbero corrispondere. Scoprire che non c'è nulla di simile alla parte più a sinistra potrebbe richiedere del tempo.

Quindi i browser corrispondono da destra; fornisce un ovvio punto di partenza e ti consente di sbarazzarti della maggior parte dei selettori candidati molto rapidamente. Puoi vedere alcuni dati su http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b185e455a0b3562a/7db34de545c17665 (anche se la notazione è confusa), ma il risultato è che in particolare per Gmail due anni fa, per il 70% delle coppie (regola, elemento) potresti decidere che la regola non corrisponde solo dopo aver esaminato le parti tag / class / id del selettore più a destra per la regola. Il numero corrispondente per la suite di test delle prestazioni di pageload di Mozilla era del 72%. Quindi vale davvero la pena provare a sbarazzarsi di quei 2/3 di tutte le regole il più velocemente possibile e quindi preoccuparsi solo di abbinare il rimanente 1/3.

Nota anche che ci sono altre ottimizzazioni che i browser già fanno per evitare di provare a trovare regole che sicuramente non corrisponderanno. Ad esempio, se il selettore più a destra ha un id e quell'id non corrisponde all'id dell'elemento, allora non ci sarà alcun tentativo di abbinare quel selettore a quell'elemento in Gecko: l'insieme di "selettori con ID" che viene tentato proviene da una ricerca hashtable sull'ID dell'elemento. Quindi questo è il 70% delle regole che hanno buone possibilità di abbinamento che ancora non corrispondono dopo aver considerato solo il tag / class / id del selettore più a destra.

L'analisi da destra a sinistra, chiamata anche analisi dal basso verso l'alto, è effettivamente efficace per il browser.

Considera quanto segue:

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

Il browser controlla prima per a, poi li, poi ule poi #menu.

Questo perché il browser sta eseguendo la scansione della pagina, deve solo guardare l'elemento / nodo corrente e tutti i nodi / elementi precedenti che ha scansionato.

La cosa da notare è che browser inizia l'elaborazione nel momento in cui ottiene un tag / nodo completo e non è necessario attendere l'intera pagina tranne quando trova uno script, nel qual caso si ferma temporaneamente e completa l'esecuzione dello script e quindi va avanti.

In caso contrario, sarà inefficiente perché il browser ha rilevato l'elemento che stava eseguendo la scansione al primo controllo, ma è stato quindi costretto a continuare a cercare nel documento tutti i selettori aggiuntivi. Per questo il browser deve avere l'intero HTML e potrebbe essere necessario scansionare l'intera pagina prima di iniziare a dipingere CSS.

Ciò è in contrasto con il modo in cui la maggior parte delle librerie analizza dom. Qui il dom è costruito e non ha bisogno di scansionare l'intera pagina, basta trovare il primo elemento e continuare ad abbinare gli altri al suo interno.

Consente il collegamento in cascata dal più specifico al meno specifico. Permette anche un corto circuito nell'applicazione. Se la regola più specifica si applica in tutti gli aspetti a cui si applica la regola padre, tutte le regole padre vengono ignorate. Se ci sono altri bit nel genitore, questi vengono applicati.

Se facessi il contrario, dovresti formattare in base al genitore e quindi sovrascrivere ogni volta che il bambino ha qualcosa di diverso. A lungo termine, questo è molto più lavoro che ignorare gli elementi nelle regole che sono già stati curati.