Sull’efficienza dei selettori annidati
Venerdì 26 Febbraio 2010 - 08:39
di Cesare Lamanna
Qual è il migliore approccio nella definizione dei selettori all’interno di un foglio di stile? Di quali fattori tenere conto? Va bene privilegiare la leggibilità e l’usabilità del codice sacrificando, almeno entro limiti accettabili, le performance nel rendering della pagina?
Possono essere così sintetizzati gli spunti di discussione che può suscitare un post come questo di Cory Schires. Il nostro si esprime a favore della pratica dell’annidamento profondo dei selettori CSS.
Ammettiamo di avere un elemento span con classe position che ha come elementi antenati un paragrafo, un div con classe employee e un altro div con id our_team (sto replicando per comodità i nomi usati da Schires nel suo esempio). Vogliamo applicare al testo di <span class="position"> una dimensione di 10px e un colore #add036.
Bene, le opzioni che lui propone come alternative nella scrittura deo codice CSS sono questa:
.position { color: #add036; font-size: 10px; }
e questa:
#our_team .employee p span.position { color: #add036; font-size: 10px; }
In questo secondo caso abbiamo un esempio di selettore annidato in profondità, ovvero preceduto nella definizione della regola dai suoi elementi antenati.
Schires offre una lista di benefici derivanti da questo approccio, ma tutto si può così sintetizzare:
Your code will be better organized, easier to read, and more maintainable.
Nel rimandarvi al post per gli esempi completi e per approfondire il pensiero dell’autore, vi chiedo: tutti convinti? È un approccio che usate?
Commenti
1
Mah. Sono d’accordo sul fatto di annidare qualcosa, però non così tanto.
Di solito suddivido le pagine in macroblocchi e utilizzo una cosa tipo
.macroblocco .macroblocco_title
{
…
}Cioé mi porto dietro nel nome dell’elemento che voglio selezionare anche un pezzo del macroblocco, così si capisce subito l’utilità anche senza utilizzare selettori profondissimi, che penalizzano le prestazioni…
# - postato da davide - 26 Febbraio 2010 - 09:37
2
Dipende dalla complessità del sito e dalla sua struttura. Con selettori così dettagliati rinuncio alla generalizzazione, che molto spesso è utile perchè risparmia la ripetizione delle stesse regole più e più volte.
Tra l’altro per siti molto complessi scrivere regole così dettagliate porta ad appesantire il css in maniera esagerata.
# - postato da Tommaso Baldovino - 26 Febbraio 2010 - 09:56
3
Dopo qualche anno di imprecazioni ci siamo decisi a considerare il css come l’html: deve essere dinamico, l’output di un programma. E il programma scrive i selettori annidati… :)
4
Uso .selettore quando definisco una classe che voglio riusare più volte
Uso p.selettore o #content .cippo p.selettore quando voglio “puntare” esattamente qualcosa…
Insomma, a dirla tutta, non vedo il problema: gli annidamenti hanno significati, e si usa quello che serve quando serve…
# - postato da William Ghelfi - 26 Febbraio 2010 - 10:09
5
Piccola precisazione… parents in inglese vuol dire genitori, non parenti :)
# - postato da Luca - 26 Febbraio 2010 - 10:15
6
il discorso è impostato male… William Ghelfi mi ha levato le parole di bocca… perdon, dalle dita…
7
Io non sono per niente daccordo.
E’ risaputo che annidare INUTILMENTE ed in quel caso mi sembra inutile. E’ infatti risaputo che è molto dispendioso a livello di risorse e che il browser legge i selettori da destra verso sinistra e quindi impiegherebbe più tempo nel traversing del documento. CSS - lo dice l’acronimo stesso, foglio di stile a cascata, ma così si viene a perdere tutto il valore. Facendo così, non solo si usano risorse inutili ma il foglio di stile in termini di byte risulterà più pesante.
Continuo con il dire che seguendo il ragionamento del post dovrei scrivere
div#navigation li
#header div#navigation ul li
dove è davvero inutile.
Non voglio assolutamente essere scortese con Cesare, che mi offre feed rss di qualità ogni giorno, ma digli a Cory Schires di leggersi https://developer.mozilla.org/en/Writing_Efficient_CSS su MDC.
Saluti!
8
Inoltre personalmente una cosa del genere non mi sembra affatto più leggibile:
#our_team .employee p span.position { color: #add036; font-size: 10px; }
Al massimo :
.employee .positionOppure:
#our_team .position
9
Hai ragione Luca, ma nella mia intenzione quel ‘parenti’ voleva essere una traduzione di ‘ancestors’, quindi ‘antenati’, grazie per avermelo fatto notare, correggo subito, non ho valutato che ‘parenti’ non implica come dovrebbe l’idea di ‘discendenza’.
@Antonio: ci tengo solo a sottolineare che sono in tutto d’accordo con te :) se ho proposto il link è per avere un confronto con tutti, sono questioni su cui più punti di vista possono aiutare a formarsi un’idea più precisa su pro e contro
# - postato da Cesare Lamanna - 26 Febbraio 2010 - 12:35
10
Certo, lo immaginavo (lo so che non scrivi a vanvera ;-)) solo che morivo dalla voglia di scrivere “digli a Cory Schires” senza mancarti di rispetto!
11
dì a Cory Shires
oppure
digliScusa, ma l’hai scritto 2 volte :P
ciao
12
Prima ho dimenticato di scrivere la parolina magica: SASS.
Si, qualche generazione si deve saltare.
Il fatto è che il css non è manutenibile.
Con Sass è possibile che saltino fuori diversi annidamenti inutili che potrebbero appesantire il rendering. Allo stesso tempo però ho un solo unico css (una sola richiesta http), compatta (pochi kb).I vantaggi ottenuti in tempo risparmiato e manutenibilità sono di gran lunga superioriori all’eventuale appesantimento del rendering.
Per metterla in metafora: ha senso chiedersi come fare per evitare di schiaccarci il dito quando usiamo il martello? Compriamo una sparachiodi, facciamo molto prima, anche se è più pericolosa e costa un po’ di più.
13
OT: @gianaz Era come in “fatti mandare dalla mamma”:
“Tu digli a quel coso… che sono geloso…”
14
I miei due ultimi temi li ho costruiti apposta per verificare i benefici di “tutto annidato” e “niente annidato”. Devo dire che la seconda soluzione mi ha permesso di scrivere un codice un pò più pulito e ordinato.
15
Complimenti per il titolo… a primo acchito ho pensato al “Dialogo sopra i due massimi sistemi del mondo” :D
16
nessuno a parlato di perfomace…
a me piacerebbe sapere quale approccio è più veloce.
ogni tanto pagespeed (il plugin per firefox) mi dice che ho i selettori poco efficienti, e me lo dice sempre quando sono annidati.
eppure dal mio punto di vista un selettore annidato dovrebbe essere più performante…
17
Uso entrambi gli approcci in maniera tale da ridurre il pià possibile il codice html e lo stesso css.
Per convenzione uso sempre mettere l’id principale di riferimento prima di ogni tag html nella stesura del css.
18
No @maurizio, il selettore annidato è meno performante rispetto a quello non annidato.
Se hai 2 minuti dai un’occhiata a https://developer.mozilla.org/en/Writing_Efficient_CSS (già citato nel mio commento)…
19
Ma lo vogliamo dire, una volta per tutte e senza intenzioni velleitarie, che i css, per come sono stati concepiti più di un decennio fa (una vera rivoluzione), oggi iniziano ad essere davvero un ingombro?
20
leggibilità ok, performance, ok.
Ma nessuno ha detto che a volte aggiungere ancestor è l’unico modo per fare override di qualcosa senza impazzire con gli !important, visto che classi, id e pseudo-classi hanno pesi differenti
21
L’hai detto ora tu, @Tambu! E hai ragione. Per quanto riguarda gli !important alle volte ne facciamo cattivo uso per quantità e qualità!
22
Io per mia esperienza sono assolutamente in accordo con questo approccio, anche alla luce di quanto esposto dai mie colleghi sopra
# - postato da Probyn - 04 Marzo 2010 - 09:27