2009-08-14 9 views
8

Ok, quindi in un'altra domanda qualcosa è stato oggetto di discussione, e questo legame è stato menzionato:scrittura efficiente CSS

https://developer.mozilla.org/en/Writing_Efficient_CSS

In quell'articolo, dicono alcune cose che non sapevo, ma prima chiedo loro, dovrei chiedere questo ... Questo vale per i CSS interpretati da Firefox? Perdona la mia noobness, ma non ero sicuro di cosa intendessero per interfaccia utente di Mozilla. (Non farmi male!)

Se si applica, quando dicono:

Evitare il selettore discendente!

Il selettore discendente è il più costoso selettore in CSS. È terribilmente costoso, soprattutto se una regola che utilizza il selettore si trova nel tag o nella categoria universale. Spesso ciò che è realmente desiderato è il selettore del bambino . L'uso del selettore discendente è vietato in UI CSS senza l'approvazione esplicita del proprietario del modulo della tua skin.

* BAD - treehead treerow treecell { } 
* BETTER, BUT STILL BAD (see next guideline) - treehead > treerow > treecell { } 

Il selettore di discendente è solo uno spazio? E allora quale sarebbe la differenza tra bambino e discendente? Il bambino è un elemento dentro l'altro, ma non è lo stesso del discendente? Mentre sto scrivendo penso che avrei potuto capirlo. Un discendente potrebbe essere un bambino/nipote/pronipote/ecc.? E il bambino è solo uno profondo?

Scusa ancora per il livello stupido della mia domanda ... mi sto solo chiedendo, perché ho sempre usato i miei discendenti nel mio CSS per il mio sito. Ma sì, se non si tratta di Firefox, tutta questa domanda non ha senso ...

Se non si tratta di Firefox, qualcuno ha un link a un articolo che spiega l'efficienza di Firefox o dei browser in generale?

+2

Sì. E i selettori di bambini non funzionano in IE6, quindi se quel supporto è d'obbligo, sei praticamente disossato. – jason

risposta

6

Prima di tutto - i suggerimenti in questo articolo sono non per le pagine html - sono specificamente per il Mozilla UI - XUL, quindi potrebbe essere migliore prassi per XUL, ma non per html.

L'applicazione del CSS su una pagina HTML media è una delle cose più veloci che si verificano durante il caricamento della pagina.
Inoltre, l'articolo potrebbe suggerire il modo più veloce per applicare le regole CSS, ma a quale costo? Ad esempio, non suggeriamo di avere più di una classe per ogni regola:

BAD - .treecell.indented {}
BUONA - .treecell-rientrate {}

che è quasi scandaloso . Può portare a CSS più veloce, ma a chi importa? Supponendo che hai già .treecell e .indented, seguendo questi suggerimenti porta a logica complicata, manutenzione più difficile, duplicati css regole, più difficile JavaScript (che costa molto di più che i CSS), ecc
Essi suggeriscono non si utilizza la piena ricchezza dei selettori CSS e la sostituzione di questi selettori con classi piatte, il che è un peccato.

+0

In realtà, l'articolo fornisce "treecell.indented" non ".treecell.idented" come "BAD". Sta dando un esempio generico di qualcosa come "p.indented" e il punto è "non qualificare le regole categorizzate in classi con i nomi dei tag". Non dice nulla sull'avere più di una classe per regola. –

+0

@pw - Sei corretto. Non posso spiegare come sia successo, ma l'articolo ha abbastanza esempi di ciò che le persone fanno quotidianamente sui CSS, che non è raccomandato su XUL. Con il tuo permesso, lascerò la risposta così com'è. :) – Kobi

7

Un discendente potrebbe essere figlio/nipote/pronipote/ecc.? E il bambino è solo uno profondo?

Sì, esattamente. Poiché un bambino può essere solo uno profondo, c'è uno spazio molto più piccolo che il motore di rendering deve cercare ricorsivamente per verificare se la regola corrisponde o meno.

E sì, quell'articolo riguarda sia Firefox che i browser in generale. La maggior parte (tutti?) Di ciò che è in esso si applica a qualsiasi motore di rendering della pagina.

1

Un "genitore> figlio" è solo un gradino più in basso, mentre un "discendente dell'antenato" potrebbe essere uno o più gradini verso il basso.

Ancora meglio è utilizzare i tag "#id" laddove possibile, in modo che ci sia meno ricerca DOM.

1

L'interfaccia utente CSS è per lo styling l'interno del browser - la finestra delle impostazioni, estensioni interfacce ecc

Discendenti ei bambini sono diversi, i bambini sono molto più specifici e si traducono in molto meno di dover essere considerato.

2

...mentre sto scrivendo penso che avrei potuto capirlo. Un discendente potrebbe essere un bambino/nipote/pronipote/ecc.? E il bambino è solo uno profondo?

Infatti.

Una cosa che posso aggiungere sul lato dell'efficienza delle cose è: Non utilizzare * a meno che non lo si intenda veramente. È piuttosto intensivo quando le regole vanno e la maggior parte delle persone potrebbe andare via solo specificando gli elementi che vogliono veramente prendere di mira.

+0

L'ho imparato mentre aggiungevo un reset. Ma grazie per aver ribadito! Non mi ero neanche reso conto che alcuni di quegli universali descritti in quell'articolo erano possibili, ma forse era meglio così. –

+0

@Oli: So che è stata una citazione diretta, ma le parolacce sono state contrassegnate e l'ho modificato. Ridicolo, lo so, ma non credo che toglie nulla alla tua risposta. –

1

Il problema con il selettore figlio è che non è altrettanto supportato. Naturalmente, questo potrebbe essere stato corretto sui nuovi browser IE.

In ogni caso, quando si scrive CSS per una pagina Web non sarà un grosso problema. Dubito che le frazioni di secondi che avresti salvato nel caricamento della pagina sarebbero state notate. Questo articolo sembra più diretto verso le persone che scrivono cose per il browser vero e proprio, non per i siti web.

1

O'Reillys "Even Faster Web Sites" ha un intero capitolo su questo titolo "Semplificare selettori CSS". Si fa riferimento il tuo link su Mozilla.

Credo che due punti sono la pena ricordare.

  1. Sì, se l'hai fatto il più possibile, il tuo HTML e CSS sarebbero stati un disastro di stili e forse anche più inefficienti a causa delle dimensioni del file aggiunte. Spetta allo sviluppatore scegliere il miglior equilibrio. ogni riga mentre la scrivi, la fa funzionare e poi vedi cosa può essere utile

  2. Come un altro commentatore ha notato, ci vuole il millisecondo del browser per capire come applicare gli stili al caricamento della pagina. Tuttavia, dove questo può avere un impatto molto più grande è con DHTML. Ogni volta che cambi il DOM, il browser applica nuovamente l'intero foglio di stile alla pagina. In questo scenario, molti selettori inefficienti potrebbero avere un impatto visibile sulla tua pagina (percezione di sfiducia/mancanza di risposta).