Non scrivere titoli nei CSS
Dividi le sezioni in file. Qualsiasi commento CSS, dovrebbe essere proprio questo, commenti.
reset.css
base.css
somepage.css
someotherpage.css
some_abstract_component.css
Usa uno script per combinarli in uno; se necessario. Puoi anche avere una buona struttura di directory e scansionare i .cssfile in modo ricorsivo .
Se è necessario scrivere intestazioni, disporre di un sommario all'inizio del file
I titoli nel sommario dovrebbero essere perfettamente uguali ai titoli che scriverai in seguito. È una seccatura cercare i titoli. Per aggiungere al problema, come si suppone esattamente che qualcuno abbia un'altra intestazione dopo la prima intestazione? ps. non aggiungere doc-like * (asterisco) all'inizio di ogni riga durante la scrittura di sommari, rende solo più fastidioso selezionare il testo.
/* Table of Contents
- - - - - - - - -
Header stuff
Body Stuff
Some other junk
- - - - - - - - -
*/
...
/* Header Stuff
*/
...
/* Body Stuff
*/
Scrivi commenti con o all'interno delle regole, non al di fuori del blocco
Prima di tutto, quando modifichi lo script c'è una probabilità del 50/50 che presterai attenzione a ciò che è al di fuori del blocco delle regole (in particolare se si tratta di un grande globo di testo;)). In secondo luogo, non c'è (quasi) nessun caso in cui avresti bisogno di un "commento" all'esterno. Se è fuori, è il 99% delle volte un titolo, quindi tienilo così.
Dividi la pagina in componenti
I componenti dovrebbero avere position:relative, no paddinge no margin, il più delle volte. Questo semplifica% governa un sacco, oltre a permettere di molto più semplice absolute:position'ing di elementi, dal momento che se c'è un contenitore posizionato assoluto l'elemento posizionato assoluto utilizzerà il contenitore quando calcolo top, right, bottom, leftproprietà.
La maggior parte dei DIV in un documento HTML5 è generalmente un componente.
Un componente è anche qualcosa che può essere considerato un'unità indipendente nella pagina. In parole povere trattate qualcosa come un componente se ha senso trattare qualcosa come una blackbox .
Andando di nuovo con l'esempio della pagina QA:
#navigation
#question
#answers
#answers .answer
etc.
Dividendo la pagina in componenti, il lavoro viene suddiviso in unità gestibili.
Inserisci le regole con un effetto cumulativo sulla stessa riga.
Ad esempio border, margine padding(ma non outline) tutti si aggiungono alle dimensioni e alle dimensioni dell'elemento che si sta disegnando.
position: absolute; top: 10px; right: 10px;
Se non sono così leggibili su una riga, almeno mettili nelle immediate vicinanze:
padding: 10px; margin: 20px;
border: 1px solid black;
Utilizzare la scorciatoia quando possibile:
/* the following... */
padding-left: 10px;
padding-right: 10px;
/* can simply be written as */
padding: 0 10px;
Non ripetere mai un selettore
Se hai più istanze dello stesso selettore, ci sono buone probabilità che tu finisca inevitabilmente con più istanze delle stesse regole. Per esempio:
#some .selector {
margin: 0;
font-size: 11px;
}
...
#some .selector {
border: 1px solid #000;
margin: 0;
}
Evitare di utilizzare TAG come selettori, quando è possibile utilizzare ID / classi
Prima di tutto i tag DIV e SPAN sono l'eccezione: non dovresti mai usarli, mai! ;) Utilizzali solo per allegare una classe / ID.
Questo...
div#answers div.answer table.statistics {
border-collapse: collapsed;
color: pink;
border: 1px solid #000;
}
div#answers div.answer table.statistics thead {
outline: 3px solid #000;
}
Dovrebbe essere scritto così:
#answers .answer .statistics {
border-collapse: collapsed;
color: pink;
border: 1px solid #000;
}
#answers .answer .statistics thead {
outline: 3px solid #000;
}
Perché i DIV penzolanti extra non aggiungono nulla al selettore. Inoltre, impongono una regola tag non necessaria. Se, ad esempio, cambiassi .answerda diva a, il articletuo stile si spezzerebbe.
O se preferisci una maggiore chiarezza:
#answers .answer .statistics {
color: pink;
border: 1px solid #000;
}
#answers .answer table.statistics {
border-collapse: collapsed;
}
#answers .answer .statistics thead {
outline: 3px solid #000;
}
Il motivo è la border-collapseproprietà è una proprietà speciale che ha senso solo se applicata a table. Se .statisticsnon è un tablenon dovrebbe applicarsi.
Le regole generiche sono malvagie!
- evita di scrivere regole generiche / magiche se puoi
- a meno che non si tratti di un ripristino / ripristino di CSS, tutta la magia generica dovrebbe essere applicata ad almeno un componente radice
Non ti fanno risparmiare tempo, ti fanno esplodere la testa; oltre a rendere la manutenzione un incubo. Quando stai scrivendo la regola, potresti sapere dove si applicano, tuttavia ciò non ha alcuna garanzia che la tua regola non ti rovinerà più tardi.
Aggiungere a queste regole generiche è confuso e difficile da leggere, anche se hai un'idea del documento che stai disegnando. Questo non vuol dire che non dovresti scrivere regole generiche, semplicemente non usarle a meno che tu non intenda davvero che siano generiche e anche se aggiungono quante più informazioni sull'ambito nel selettore che puoi.
Cose come questa ...
.badges {
width: 100%;
white-space: nowrap;
}
address {
padding: 5px 10px;
border: 1px solid #ccc;
}
... ha lo stesso problema dell'utilizzo di variabili globali in un linguaggio di programmazione. Devi dare loro spazio!
#question .userinfo .badges {
width: 100%;
white-space: nowrap;
}
#answers .answer .userinfo address {
padding: 5px 10px;
border: 1px solid #ccc;
}
Fondamentalmente si legge come:
components target
---------------------------- --------
#answers .answer .userinfo address
-------- --------- --------- --------
domain component component selector
Mi piace usare gli ID ogni volta che un componente che conosco è un singleton in una pagina; le tue esigenze potrebbero essere diverse.
Nota: idealmente, dovresti scrivere quanto basta. Menzionare più componenti nel selettore è tuttavia l'errore più tollerante, rispetto a menzionare meno componenti.
Supponiamo che tu abbia un paginationcomponente. Lo usi in molti punti del tuo sito. Questo sarebbe un buon esempio di quando dovresti scrivere una regola generica. Consente di dire display:blocki collegamenti dei singoli numeri di pagina e dare loro uno sfondo grigio scuro. Per essere visibili devi avere regole come questa:
.pagination .pagelist a {
color: #fff;
}
Ora supponiamo che usi la tua impaginazione per un elenco di risposte, potresti riscontrare qualcosa del genere
#answers .header a {
color: #000;
}
...
.pagination .pagelist a {
color: #fff;
}
Questo renderà i tuoi collegamenti bianchi neri, cosa che non vuoi.
Il modo errato per risolverlo è:
.pagination .pagelist a {
color: #fff !important;
}
Il modo corretto per risolverlo è:
#answers .header .pagination .pagelist a {
color: #fff;
}
I commenti "logici" complessi non funzionano :)
Se scrivi qualcosa del tipo: "questo valore dipende da blah-blah combinato con l'altezza di blah-blah", è inevitabile che tu commetta un errore e cadrà tutto come un castello di carte.
Mantieni semplici i tuoi commenti; se hai bisogno di "operazioni logiche" considera uno di quei linguaggi CSS come SASS o LESS .
Come si scrive un pallet a colori?
Lascia questo per la fine. Avere un file per l'intero pallet di colori. Senza questo file il tuo stile dovrebbe comunque avere delle palette di colori utilizzabili nelle regole. Il pallet di colori deve essere sovrascritto. Fai una catena di selettori usando un componente genitore di altissimo livello (es. #page) E poi scrivi il tuo stile come un blocco di regole autosufficiente. Può essere solo colore o qualcosa di più.
per esempio.
#page #header .description,
#page #categories .description,
#page #answers .answer .body
{
color: #222; background: #fff;
border-radius: 10px;
padding: 1em;
}
L'idea è semplice, la tua tavolozza dei colori è un foglio di stile indipendente dallo stile di base, in cui ti trovi a cascata .
Meno nomi, richiede meno memoria, facilitando la lettura del codice
Usare meno nomi è meglio. Idealmente usa parole molto semplici (e brevi!): Testo, corpo, intestazione.
Trovo anche che la combinazione di parole semplici sia più facile da capire quindi avere una zuppa di lunghe parole "appropriate": postbody, posthead, userinfo, ecc.
Mantieni il vocabolario piccolo, in questo modo anche se un estraneo che arriva a leggere la tua zuppa di stile (come te stesso dopo alcune settimane;)) deve solo capire dove vengono usate le parole piuttosto che dove viene utilizzato ogni selettore. Ad esempio, utilizzo .thisogni volta che un elemento è presumibilmente "l'elemento selezionato" o "l'elemento corrente", ecc.
Pulisci dopo te stesso
Scrivere CSS è come mangiare, a volte ti lasci un casino. Assicurati di ripulire quel casino, altrimenti il codice spazzatura si accumulerà. Rimuovi classi / ID che non usi. Rimuovi le regole CSS che non usi. Assicurati che tutto sia a posto e non hai regole contrastanti o duplicate.
Se, come ho suggerito, hai trattato alcuni contenitori come scatole nere (componenti) nel tuo stile, hai usato quei componenti nei tuoi selettori e hai conservato tutto in un file dedicato (o diviso correttamente un file con un sommario e intestazioni), allora il tuo il lavoro è sostanzialmente più semplice ...
Puoi usare uno strumento come l'estensione Dust-Me Selettori di Firefox (suggerimento: puntalo sul tuo sitemap.xml) per aiutarti a trovare parte della spazzatura nascosta nelle tue bombe e caramelle CSS.
Conserva un unsorted.cssfile
Supponiamo che tu stia progettando un sito QA e che tu abbia già un foglio di stile per la "pagina delle risposte", che chiameremo answers.css. Se ora hai bisogno di aggiungere molti nuovi CSS, aggiungilo al unsorted.cssfoglio di stile, quindi rifattorizza nel tuo answers.cssfoglio di stile.
Diversi motivi per questo:
- è più veloce fare il refactoring dopo aver finito, quindi è cercare regole (che probabilmente non esistono) e iniettare codice
- scriverai cose che rimuoverai, l'iniezione di codice rende più difficile la rimozione di quel codice
- l'aggiunta al file originale porta facilmente alla duplicazione della regola / selettore
simplicity,complexity,maintenance,structureerefactoring.