Gestione dell'esplosione CSS


683

Ho fatto molto affidamento su CSS per un sito Web su cui sto lavorando. In questo momento, tutti gli stili CSS vengono applicati in base al tag, quindi ora sto provando a spostarlo su uno stile più esterno per aiutare con eventuali cambiamenti futuri.

Ma ora il problema è che ho notato che sto ottenendo una "CSS Explosion". Sta diventando difficile per me decidere come organizzare e astrarre meglio i dati all'interno del file CSS.

Sto usando un gran numero di divtag all'interno del sito Web, passando da un sito Web fortemente basato su tabelle. Quindi sto ricevendo molti selettori CSS che assomigliano a questo:

div.title {
  background-color: blue;
  color: white;
  text-align: center;
}

div.footer {
  /* Styles Here */
}

div.body {
  /* Styles Here */
}

/* And many more */

Non è ancora così male, ma dato che sono un principiante, mi chiedevo se si potevano formulare raccomandazioni su come organizzare al meglio le varie parti di un file CSS. Non voglio avere un attributo CSS separato per ogni elemento sul mio sito Web e voglio sempre che il file CSS sia abbastanza intuitivo e di facile lettura.

Il mio obiettivo finale è semplificare l'uso dei file CSS e dimostrare il loro potere di aumentare la velocità dello sviluppo web. In questo modo, anche altre persone che potrebbero lavorare su questo sito in futuro inizieranno a usare buone pratiche di codifica, piuttosto che doverle prendere come ho fatto io.


122
Questa è un'ottima domanda ma per molte aziende un problema davvero irrisolvibile. Soprattutto perché CSS è stato scritto e gestito da grafici che possono non essere a conoscenza dei termini simplicity, complexity, maintenance, structuree refactoring.
Cherouvim,

8
@cherouvim - È divertente dirlo perché la mia intera ragione per porre questa domanda è iniziata con la visualizzazione di alcuni CSS spaventosi progettati da un artista grafico. Forse abbiamo bisogno di un allenamento migliore per loro?
JasCav,

13
La mia soluzione (in un mondo ideale) è quella di avere persone dedicate nella tua squadra che tagliano il PSD in html + css e lo mantengono in seguito. Queste persone dovrebbero essere vicine ai programmatori e ai progettisti.
Cherouvim,

@cherouvim Devo essere d'accordo: è praticamente così che vanno le agenzie, specialmente quando i CSS diventano più complessi.
John Parker,

27
@JasCav, Gli artisti grafici non dovrebbero toccare il CSS. Web designer e sviluppatori Web front-end dovrebbero occuparsi di CSS. Il compito del progettista grafico è realizzare la grafica.
zzzzBov,

Risposte:


567

Questa è un'ottima domanda Ovunque guardi, i file CSS tendono a sfuggire al controllo dopo un po ', specialmente, ma non solo, quando si lavora in gruppo.

Le seguenti sono le regole che io stesso sto cercando di rispettare (non che riesco sempre a.)

  • Refactor presto, refactor spesso. Pulisci frequentemente i file CSS, fonde insieme più definizioni della stessa classe. Rimuovere immediatamente le definizioni obsolete .

  • Quando aggiungi CSS durante la correzione di bug, lascia un commento su ciò che la modifica fa ("Questo è per assicurarti che la casella sia allineata a sinistra in IE <7")

  • Evita i licenziamenti, ad esempio definendo la stessa cosa in .classnamee .classname:hover.

  • Usa i commenti /** Head **/per costruire una struttura chiara.

  • Utilizzare uno strumento prettifier che aiuta a mantenere uno stile costante. Uso Polystyle , con il quale sono abbastanza contento (costa $ 15 ma i soldi sono ben spesi). Ci sono anche quelli gratuiti in giro (ad esempio, Code Beautifier basato su CSS Tidy , uno strumento open source).

  • Costruisci classi sensate. Vedi sotto per alcune note su questo.

  • Usa la semantica, evita la minestra DIV - usa <ul>s per i menu, per esempio.

  • Definisci tutto su un livello il più basso possibile (ad es. Una famiglia di caratteri predefinita, colore e dimensione in body) e usa inheritdove possibile

  • Se hai CSS molto complessi, forse un pre-compilatore CSS aiuta. Sto pensando di esaminare presto xCSS per la stessa ragione. Ce ne sono molti altri in giro.

  • Se lavori in gruppo, evidenzia la necessità di qualità e standard anche per i file CSS. Tutti amano gli standard di codifica nei loro linguaggi di programmazione, ma c'è poca consapevolezza che questo è necessario anche per i CSS.

  • Se lavori in gruppo, prendi in considerazione l'uso del controllo versione. Rende le cose molto più facili da tracciare e la modifica dei conflitti molto più facile da risolvere. Ne vale davvero la pena, anche se sei "solo" in HTML e CSS.

  • Non lavorare con !important. Non solo perché IE = <7 non può gestirlo. In una struttura complessa, l'uso di !importantè spesso tentato di cambiare un comportamento la cui fonte non può essere trovata, ma è veleno per la manutenzione a lungo termine.

Costruire classi sensate

È così che mi piace costruire classi sensate.

Applico prima le impostazioni globali:

body { font-family: .... font-size ... color ... }
a { text-decoration: none; }

Quindi, identifico le sezioni principali del layout della pagina, ad esempio l'area superiore, il menu, il contenuto e il piè di pagina. Se ho scritto un buon markup, queste aree saranno identiche alla struttura HTML.

Quindi, inizio a costruire classi CSS, specificando più antenati il ​​più a lungo possibile e raggruppando le classi correlate il più vicino possibile.

div.content ul.table_of_contents 
div.content ul.table_of_contents li 
div.content ul.table_of_contents li h1
div.content ul.table_of_contents li h2
div.content ul.table_of_contents li span.pagenumber

Pensa all'intera struttura CSS come ad un albero con definizioni sempre più specifiche, più lontano dalla radice che sei. Vuoi mantenere il numero di classi il più basso possibile e vuoi ripeterti il ​​più raramente possibile.

Ad esempio, supponiamo che tu abbia tre livelli di menu di navigazione. Questi tre menu sembrano diversi, ma condividono anche alcune caratteristiche. Ad esempio, sono tutti <ul>, hanno tutti la stessa dimensione del carattere e gli elementi sono tutti uno accanto all'altro (al contrario del rendering predefinito di un ul). Inoltre, nessuno dei menu ha punti elenco ( list-style-type).

Innanzitutto, definisci le caratteristiche comuni in una classe denominata menu:

div.navi ul.menu { display: ...; list-style-type: none; list-style-image: none; }
div.navi ul.menu li { float: left }

quindi, definire le caratteristiche specifiche di ciascuno dei tre menu. Il livello 1 è alto 40 pixel; livelli 2 e 3, 20 pixel.

Nota: è possibile utilizzare anche più classi per questo, ma Internet Explorer 6 ha problemi con più classi , quindi questo esempio usa ids.

div.navi ul.menu#level1 { height: 40px; }
div.navi ul.menu#level2 { height: 20px; }
div.navi ul.menu#level3 { height: 16px; }

Il markup per il menu sarà simile al seguente:

<ul id="level1" class="menu"><li> ...... </li></ul>
<ul id="level2" class="menu"><li> ...... </li></ul>
<ul id="level3" class="menu"><li> ...... </li></ul>

Se nella pagina sono presenti elementi semanticamente simili, come questi tre menu, prova prima a individuare i punti in comune e a metterli in una classe; quindi, elaborare le proprietà specifiche e applicarle alle classi o, se è necessario supportare Internet Explorer 6, gli ID.

Suggerimenti HTML vari

Se aggiungi queste semantiche al tuo output HTML, i designer possono in seguito personalizzare l'aspetto dei siti Web e / o delle app usando CSS puro, il che è un grande vantaggio e un risparmio di tempo.

  • Se possibile, dai al corpo di ogni pagina una classe unica: <body class='contactpage'>questo rende molto facile aggiungere modifiche specifiche della pagina al foglio di stile:

    body.contactpage div.container ul.mainmenu li { color: green }
  • Quando si creano automaticamente menu, aggiungere il maggior numero possibile di contesto CSS per consentire uno stile più ampio in seguito. Per esempio:

    <ul class="mainmenu">
     <li class="item_first item_active item_1"> First item </li> 
     <li class="item_2"> Second item </li> 
     <li class="item_3"> Third item </li> 
     <li class="item_last item_4"> Fourth item </li> 
    </ul>
    

    In questo modo, è possibile accedere a ogni voce di menu per lo stile in base al suo contesto semantico: se si tratta del primo o dell'ultimo elemento nell'elenco; Che si tratti dell'elemento attualmente attivo; e per numero.

Si noti che questa assegnazione di più classi come indicato nell'esempio sopra non funziona correttamente in IE6 . C'è una soluzione alternativa per rendere IE6 in grado di gestire più classi. Se la soluzione alternativa non è un'opzione, dovrai impostare la classe più importante per te (numero articolo, attivo o primo / ultimo), oppure ricorrere all'uso degli ID.


3
@Andrew principalmente perché in un ambiente dinamico (come un CMS) l'utilizzo di un ID potrebbe facilmente portare a collisioni (ad esempio, un utente che rinomina una pagina in "contatto", portando a quel nome utilizzato come ID del corpo, scontrandosi con il modulo di contatto chiamato anche "contatto"). In genere, consiglio di usare gli ID il più parsimoniosamente possibile per quel motivo.
Pekka,

4
@Pekka dovresti dare un'occhiata a www.oocss.org molto va contro ciò che hai menzionato qui, ma è il modo migliore che ho visto per gestire il gonfiamento CSS. Vedi anche la mia risposta qui sotto: stackoverflow.com/questions/2253110/how-to-manage-css-explosion/…
Moin Zaman

2
@Sam grazie! Mi piace abbastanza bene, anche se ogni tanto trovo queste linee guida molto difficili da seguire. I fogli di stile CSS sono così facili da rovinare nel tempo - un cambio di colore qui, un font-weight: boldlà .... la disciplina è l'unica medicina :)
Pekka,

1
Parlando come una persona nuova nello studio dell'esplosione dei CSS, la frase "classe unica" è confusa. Ho la sensazione che non sia un idma suona sicuramente come uno. Forse il concetto potrebbe essere chiarito?
ari gold,

2
@ari hai ragione id, anche tecnicamente potrebbe essere un .
Pekka,

89

Ecco solo 4 esempi:

Su tutti e 4 la mia risposta ha incluso il consiglio di scaricare e leggere i sistemi CSS PDF di Natalie Downe . (Il PDF include tonnellate di note non presenti nelle diapositive, quindi leggi il PDF!). Prendi nota dei suoi suggerimenti per l'organizzazione.

EDIT (2014/02/05) quattro anni dopo, direi:

  • Usa un pre-processore CSS e gestisci i tuoi file come parziali (preferisco personalmente Sass con Compass, ma anche Less è abbastanza buono e ce ne sono altri)
  • Leggi concetti come OOCSS , SMACSS e BEM o getbem .
  • Dai un'occhiata a come sono strutturati i framework CSS popolari come Bootstrap e Zurb Foundation . E non scartare quadri meno popolari: Inuit è interessante ma ce ne sono molti altri.
  • Combina / minimizza i tuoi file con un passaggio di generazione su un server di integrazione continua e / o un task runner come Grunt o Gulp.

I pre-processori CSS sono la causa del problema piuttosto che la soluzione. Padroneggia veramente il concetto a cascata e ridurrai il gonfiamento.
Daniel Sokolowski il

@DanielSokolowski qualsiasi strumento utilizzato in modo improprio può essere un problema piuttosto che una soluzione. Ma il 100% concorda sul punto di dominare la cascata.
Andy Ford,

73

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

1
i selettori senza tag sono molto più lenti di quelli basati su tag. Tutti i browser hanno metodi nativi per ottenere un 'div' per esempio (o qualsiasi altro tag). Se lo lasci essere troppo generico ('.class'), il motore di rendering dovrà percorrere tutti gli elementi del DOM per vedere se esiste una corrispondenza.
Miguel Ping,

@Miguel Perché il motore di rendering non dovrebbe percorrere tutti gli elementi nel DOM per vedere se sono un DIV? Se esiste un'ottimizzazione speciale, perché non viene applicata a classi / ID? Hai una fonte? L'unico killer delle prestazioni visibile che ho notato con CSS era dovuto allo spam float: può causare un ritardo orribile del motore di rendering su alcuni browser durante lo scorrimento della pagina (probabilmente troppi calcoli).
srcspider,

3
Stavo per votare questo per aver detto di non scegliere come target tagNames (yay!) Ma poi c'era la parte sul non essere generico (boo!)
mwilcox,

1
@Miguel, non funziona così. I browser leggono una stringa CSS all'indietro, quindi ci vorrebbe: "div .myclass" e trova tutte le classi ".myclass", quindi controlla se è un antenato di un div.
mwilcox,

5
Il confronto tra regole generiche e variabili globali è il più grande fraintendimento che io abbia mai sentito parlare di CSS.
gblazex,

55

Dai un'occhiata a 1. SASS 2. Bussola


11
Un milione di volte questo. L'uso di Sass mi ha reso un wrangler css più organizzato e potente che mai. Mi permette di organizzare gli stili su più file, annidare gli stili, usare le variabili, ecc., Ecc. Ecc.
Alan H.

2
sass, compass e less tutti producono CSS normale alla fine della giornata che potrebbe essere ancora brutto ed esploso. Non è una soluzione al gonfiore CSS di per sé.
Moin Zaman,

8
@Moin_Zaman Secondo la mia modesta opinione, signore, la sua affermazione è pura umiltà. scrivi in ​​sass / compass / less e organizzi il tuo codice nei loro file. non ti interessa l'aspetto dell'output css. inoltre, almeno meno (tramite meno app) può minimizzare l'output, il che è fantastico.
bzx,

1
@bzx stai dimostrando il mio punto :) Un browser non capisce sass / compass / less. tutti questi devono essere compilati in un semplice vecchio CSS sul lato client o come parte della tua build. L'uso di strumenti come questi senza sapere cosa producono alla fine come CSS rende molto facile abusarli inconsapevolmente e finire con file CSS più grandi che ottimali.
Moin Zaman,

È qui che entra in gioco la compressione gzip ... La maggior parte dei server Web e browser comunicherà con contenuti gzip quando possibile. Se finisci per ripetere più volte un frammento di selettore, questo verrà compresso in una singola voce della tabella hash. L'unico vero problema è quindi la quantità di RAM necessaria per analizzare le regole CSS nel browser.
terzo

31

Il modo migliore che ho visto per contrastare il CSSgonfiamento è usare i principi CSS orientati agli oggetti.

C'è persino un framework OOCSS là fuori che è abbastanza buono.

Alcune delle ideologie vanno contro molto di ciò che è stato detto qui nelle risposte migliori, ma una volta che sai come progettare CSSin modo orientato agli oggetti, vedrai che funziona effettivamente nel mantenere il codice snello e cattivo.

La cosa chiave qui è identificare "Oggetti" o schemi di blocchi di costruzione nel tuo sito e progettarli con essi.

Facebook ha assunto il creatore di OOCSS, Nicole Sullivan per ottenere molti risparmi nel loro codice front-end (HTML / CSS). Sì si può effettivamente ottenere un risparmio non solo nel CSS, ma nel tuo HTML troppo, che dal suono di esso, è molto possibile per voi come si parla conversione di un tablelayout di base in un sacco di divs'

Un altro ottimo approccio è simile in alcuni aspetti a OOCSS, è quello di pianificare e scrivere i CSS in modo che siano scalabili e modulari sin dall'inizio. Jonathan Snook ha scritto e pubblicato un libro / ebook su SMACSS - Scalable and Modular Architecture for CSS

Lascia che ti colleghi con alcuni link:
5 errori di CSS massicci - (Video)
5 errori di CSS massicci - (Diapositive)
CSS Bloat - (Diapositive)


16

Dovresti anche capire la cascata, il peso e come funzionano.

Ho notato che stai utilizzando solo identificatori di classe (div.title). Sapevi che puoi usare anche gli ID e che un ID ha più peso di una classe?

Per esempio,

#page1 div.title, #page1 ul, #page1 span {
  // rules
}

farà sì che tutti quegli elementi condividano una dimensione del carattere, diciamo, o un colore, o qualunque siano le tue regole. Puoi anche fare in modo che tutti i DIV discendenti di #pagina1 ottengano determinate regole.

Per quanto riguarda il peso, ricorda che gli assi CSS si spostano dal più generale / più leggero al più specifico / più pesante. Vale a dire, in un selettore CSS un identificatore di elemento viene ignorato da un identificatore di classe viene annullato da un identificatore di ID. I numeri contano, quindi un selettore con due specificatori di elementi (ul li) avrà più peso di uno con un solo specificatore (li).

Pensalo come cifre. Un 9 nella colonna uni è ancora meno di uno nella colonna delle decine. Un selettore con un identificatore ID, un identificatore di classe e due specificatori di elementi avrà un peso maggiore rispetto a un selettore senza ID, 500 specificatori di classe e 1.000 specificatori di elementi. Questo è un esempio assurdo, certo, ma hai capito. Il punto è che l'applicazione di questo concetto ti aiuta a ripulire molti CSS.

A proposito, l'aggiunta dell'identificatore di elemento alla classe (div.title) non è necessaria a meno che non ci si trovi in ​​conflitto con altri elementi che hanno class = "title". Non aggiungere peso inutile, perché potrebbe essere necessario utilizzarlo in un secondo momento.


L'uso degli ID è dannoso proprio come l'utilizzo delle variabili globali nel codice Visual Basic.
alpav

2
@alpav: mi dispiace, non è corretto. Gli ID sono un modo formidabile per far apparire gli elementi simili in modo diverso nelle diverse parti di una pagina senza impazzire nel creare nuovi nomi di classe.
Robusto

@Robusto: Perché creare un nuovo nome ID è più difficile che creare un nuovo nome di classe?
alpav

@Robusto: creare nuovi nomi di classe è in realtà più semplice dei nomi ID perché con gli ID devi preoccuparti dell'ambito globale e con i nomi delle classi devi preoccuparti solo dell'unicità nell'ambito locale, lo stesso vantaggio delle variabili locali.
alpav

1
@alpav "Questo sconfigge lo scopo dell'incapsulamento: essere in grado di nominare localmente senza pensare a livello globale." Giusto, ma i selettori CSS sono intrinsecamente globali: quando scrivi .myclass, selezioni tutto con la classe myclass. In CSS, le classi sono identiche agli ID in questo senso.
Paul D. Waite,

12

Vorrei suggerire Meno CSS Dynamic framework

È simile a SASS come menzionato in precedenza.

Aiuta a mantenere CSS per classe genitore.

Per esempio

 #parent{     
  width: 100%;

    #child1
    {    
     background: #E1E8F2;    
     padding: 5px;    
    }

    #child2
   {
     background: #F1F8E2;
     padding: 15px
   }
 }

Cosa fa: applica la larghezza: 100% a # child1 e # child2.

Inoltre, # child1 CSS specifico appartiene a #parent.

Questo renderebbe

#parent #child1
{
 width: 100%;
 background: #E1E8F2;
 padding: 5px;
}

#parent #child2
{
 width: 100%;
 background: #F1F8E2;
 padding: 15px;
}

1
io uso sass e potrebbe essere che questa sia una differenza tra sass e less, ma sono abbastanza sicuro che verrà compilato come `#parent {larghezza: 100%; } #parent # child1 {background: # E1E8F2; imbottitura: 5px; } #parent # child2 {background: # F1F8E2; imbottitura: 15px; } `
emik,

12

Trovo che la cosa difficile sia tradurre il progetto richiesto per un sito in una serie di regole. Se il design del sito è chiaro e basato su regole, i nomi delle classi e la struttura CSS possono derivare da questo. Ma se nel tempo le persone aggiungono casualmente piccole parti al sito che non hanno molto senso, non c'è molto che puoi fare al riguardo nel CSS.

Tendo a organizzare i miei file CSS più o meno in questo modo:

  1. Ripristino CSS, basato su Eric Meyer . (Perché altrimenti trovo che, per la maggior parte degli elementi, ho almeno una o due regole che stanno solo ripristinando gli stili di browser predefiniti - la maggior parte dei miei elenchi non assomigliano allo stile HTML predefinito per gli elenchi, ad esempio.)

  2. Grid CSS di sistema, se il sito lo richiede. (Ho basato il mio su 960.gs )

  3. Stili per i componenti che compaiono su ogni pagina (intestazioni, piè di pagina, ecc.)

  4. Stili per i componenti utilizzati in vari punti del sito

  5. Stili rilevanti solo per le singole pagine

Come puoi vedere, la maggior parte dipende dal design del sito. Se il design è chiaro e organizzato, il tuo CSS può essere. Altrimenti, sei fregato.


7

La mia risposta è di alto livello per rispondere alle preoccupazioni di alto livello che hai sollevato nella tua domanda. Ci possono essere trucchi organizzativi di basso livello e modifiche che puoi fare per renderlo più bello, ma nessuno di questi può risolvere carenze metodologiche. Ci sono diverse cose che influenzano l'esplosione dei CSS. Ovviamente la complessità complessiva del sito, ma anche cose come la semantica dei nomi, le prestazioni CSS, l'organizzazione dei file CSS e la testabilità / accettabilità.

Sembri essere sulla strada giusta con la semantica dei nomi, ma può essere fatto un passo avanti. Le sezioni di HTML che compaiono ripetutamente sul sito senza modifiche strutturali (note come "moduli") possono essere considerate root di selezione e da lì è possibile definire il layout interno relativo a quella radice. Questo è il principio di base dei CSS orientati agli oggetti e puoi leggere / guardarne di più in questo discorso di un ingegnere di Yahoo .

È importante notare che questo approccio pulito può essere eseguito al contrario della preoccupazione per le prestazioni, che favorisce i selettori brevi basati sull'id o sul nome del tag . Trovare questo equilibrio dipende da te, ma a meno che tu non abbia un sito enorme, questa dovrebbe essere solo una guida nella parte posteriore della tua testa che ti ricorda di mantenere i selettori brevi. Maggiori informazioni sulle prestazioni qui .

Infine, hai un singolo file CSS per l'intero sito o più file (un singolo file di base utilizzato con i file per pagina o sezione)? Il singolo file è migliore per le prestazioni, ma potrebbe essere più difficile da capire / mantenere con più membri del team e potrebbe essere più difficile da testare. Per i test, ti consiglio di avere una singola pagina di test CSS che includa tutti i moduli CSS supportati per testare collisioni e cascate involontarie.

In alternativa, puoi avere un approccio a più file , per estendere le regole CSS a una pagina o una sezione. Ciò richiede che il browser scarichi più file, il che è un problema di prestazioni. È possibile utilizzare la programmazione lato server per specificare e aggregare (e minimizzare) i file CSS in un singolo file in modo dinamico. Ma poiché questi file sono separati e i test per essi sarebbero separati, si introduce la possibilità di un aspetto incoerente tra pagine / sezioni. Quindi i test diventano più difficili.

Sta a te analizzare le esigenze specifiche del cliente, bilanciare di conseguenza queste preoccupazioni.


5

Come detto prima di me: entra in OOCSS. Sass / Less / Compass è allettante da usare, ma fino a quando il CSS vanilla non viene usato nel modo giusto Sass / Less / Compass peggiorerà le cose.

Prima di tutto, leggi su css efficiente. prova Google Page Speed ​​e leggi cosa hanno scritto Souders su css efficienti.

Quindi, inserisci OOCSS.

  • Impara a lavorare con la cascata. (Dopotutto, lo chiamiamo Fogli di stile a cascata ).
  • Scopri come ottenere la granularità corretta (bottom-up anziché top-down)
  • Scopri come separare struttura e skin (che cosa è unico e quali sono le variazioni di questi oggetti?)
  • Scopri come separare contenitore e contenuto.
  • Impara ad amare le reti.

Rivoluzionerà ogni singolo bit sulla scrittura di CSS. Sono totalmente rinnovato e lo adoro.

AGGIORNAMENTO: SMACSS è simile a OOCSS, ma più facile da adattare in generale.


2
"Sass / Less / Compass non farà altro che peggiorare le cose" - è piuttosto soggettivo e dipende dal progetto. Vorrei sostenere che l'utilizzo di uno di questi in collaborazione con OOCSS avrebbe davvero giovato alla manutenibilità di molti grandi progetti (in particolare quelli i cui stili possono essere cambiati frequentemente)
Zach Lysobey,

Zach L: OOCSS (o per quello, SMACSS) usato correttamente rende Compass / Less / Sass necessario solo per i prefissi del fornitore.
madr

Non proverò a discuterne troppo (specialmente perché al momento non uso un pre-processore), ma sono abbastanza sicuro che ci sono un sacco di persone che trovano queste cose utili, anche in combinazione con OOCSS / SMACSS al di fuori dei problemi con il prefisso del fornitore
Zach Lysobey,

4

I principi fondamentali per CSS sensibili, estratti dal refactoring CSS: dall'appendice ai CSS modulari

Scrivi in ​​SASS. Saresti pazzo a rinunciare ai vantaggi di variabili, mixin e così via.

Non usare mai un ID HTML per lo styling; usa sempre le classi . Gli ID HTML, se usati correttamente, compaiono una sola volta nell'intera pagina, che è l'esatto contrario della riutilizzabilità, uno dei beni di base nell'ingegneria sensibile. Inoltre, è davvero difficile ignorare i selettori contenenti ID e spesso l'unico modo per sopraffare un ID HTML è creare un altro ID, facendo sì che gli ID si propaghino nella base di codice come i parassiti che sono. Meglio lasciare gli ID HTML per Javascript invariato o hook di test di integrazione.

Assegna un nome alle tue classi CSS in base alla loro funzione visiva piuttosto che alla loro funzione specifica dell'applicazione. Ad esempio, dire ".highlight-box" anziché ".bundle-product-discount-box". La codifica in questo modo significa che è possibile riutilizzare i fogli di stile esistenti quando si svolgono attività secondarie. Ad esempio, abbiamo iniziato a vendere note legali ma recentemente ci siamo trasferiti in tutor legali. Le nostre vecchie classi CSS avevano nomi come ".download_document_box", un nome di classe che ha senso quando si parla di documenti digitali ma confonderebbe solo quando applicato al nuovo dominio di tutor privati. Un nome migliore che si adatta sia ai servizi esistenti, sia a quelli futuri, sarebbe ".pretty_callout_box".

Evita di nominare le classi CSS dopo specifiche informazioni sulla griglia. C'era (ed è tuttora) un terribile anti-pattern nelle comunità CSS in base al quale designer e creatori di framework CSS (tosse Twitter Bootstrap ) credono che "span-2" o "cols-8" siano nomi ragionevoli per le classi CSS. Il punto del CSS è darti la possibilità di modificare il tuo design senza influenzare il markup (molto). La codifica hardware inserisce dimensioni in HTML che ostacolano questo obiettivo, quindi è sconsigliato in qualsiasi progetto che duri più a lungo di un fine settimana. Maggiori informazioni su come abbiamo evitato le classi di griglia in seguito.

Dividi il tuo CSS tra i file . Idealmente, dovresti dividere tutto in "componenti" / "widget" e quindi comporre le pagine da questi atomi di progettazione. Realisticamente, noterai che alcune delle pagine del tuo sito web hanno idiosincrasie (ad esempio un layout speciale o una strana galleria fotografica che appare in un solo articolo). In questi casi potresti creare un file relativo a quella pagina specifica, eseguendo il refactoring in un widget completo solo quando diventa chiaro che l'elemento verrà riutilizzato altrove. Questo è un compromesso, motivato da preoccupazioni pratiche di bilancio.

Riduci al minimo l'annidamento. Introdurre nuove classi anziché annidare i selettori. Il fatto che SASS rimuova il dolore di ripetere i selettori durante l'annidamento non significa che devi annidare cinque livelli in profondità. Non qualificare mai eccessivamente un selettore (ad esempio, non utilizzare "ul.nav" dove ".nav" potrebbe fare lo stesso lavoro.) E non specificare elementi HTML accanto al nome della classe personalizzata (ad esempio "h2.highlight"). Invece usa solo il nome della classe da solo e rilascia il selettore di base (es. L'esempio precedente dovrebbe essere ".highlight"). I selettori con qualifiche eccessive non aggiungono alcun valore.

Crea stili per elementi HTML (ad es. "H1") solo quando dai uno stile ai componenti di base che dovrebbero essere coerenti nell'intera applicazione. Evita i selettori di grandi dimensioni come "header ul" perché è probabile che tu debba sostituirli in alcuni punti comunque. Come continuiamo a dire, la maggior parte delle volte si desidera utilizzare una classe specifica e ben denominata ogni volta che si desidera uno stile particolare.

Abbraccia le basi di Block-Element-Modifier. Puoi leggerlo ad esempio qui. Lo abbiamo usato abbastanza leggermente, ma comunque ci ha aiutato molto nell'organizzazione degli stili CSS.


2

Molte volte vedrò le persone suddividere il file in sezioni, con un commento di intestazione tra le sezioni.

Qualcosa di simile a

/* Headings and General Text */

.... stuff here for H1, etc..

/* Main page layout */

.... stuff here for layout page setup etc.

Funziona abbastanza bene e può rendere più facile tornare più tardi e trovare ciò su cui stai lavorando.


Questo non dice nulla sulla preoccupazione del richiedente di avere "un attributo CSS separato per ogni singola cosa".
G-Wiz,

1

Dovresti guardare BEM .

Teoria

BEM è un tentativo di fornire una serie di istruzioni per l'organizzazione e la denominazione dei selettori CSS nel tentativo di rendere le cose più riutilizzabili e modulari e di evitare scontri tra selettori del tipo che spesso porta a codice spaghetti e mal di testa di specificità.

Se usato correttamente, ha degli effetti molto positivi.

  • Gli stili fanno quello che ti aspetti quando vengono aggiunti a un elemento
  • Gli stili non perdono ed incidono solo su ciò a cui vengono aggiunti
  • Gli stili sono completamente disaccoppiati dalla struttura del documento
  • Gli stili non devono essere forzati a cavalcare l'un l'altro

BEM funziona bene con SASS per portare uno stile quasi orientato agli oggetti nei CSS. Puoi creare file modulari, che gestiscono la visualizzazione di un singolo elemento dell'interfaccia utente e contengono variabili, come colori e "metodi" come la gestione degli elementi interni. Mentre un programmatore OO hardcore potrebbe rifiutare questa idea, in effetti, i concetti applicati portano molte delle parti più belle delle strutture OO, come la modularità, l'accoppiamento lento e la coesione stretta e la riutilizzabilità senza contesto. Puoi persino costruire in un modo che assomigli ad un oggetto incapsulato usando Sass e l' &operato r.

Un articolo più approfondito di Smashing Magazine può essere trovato qui ; e uno di Harry Roberts di CCS Wizardry (di cui chiunque sia coinvolto in css dovrebbe avere una lettura) è qui .

In pratica

Ho usato questo, diverse volte, insieme ad aver usato SMACSS e OOCSS, il che significa che ho qualcosa anche per confrontarli. Ho anche lavorato in alcuni grandi pasticci, spesso della mia creazione inesperta.

Quando uso BEM nel mondo reale, accresco la tecnica con un paio di principi extra. Uso le classi di utilità - un buon esempio è una classe wrapper:

.page-section {
    width: 100%;
}
@media screen and (min-width: 1200px) {
    margin: 0 auto;
    width: 1200px;
}

E mi affido anche un po 'alla cascata e alla specificità. Qui il modulo BEM sarebbe .primary-boxe .headersarebbe il contesto per un over-ride specifico

.header {
  .primary-box {
    color: #000;
  }
}

(Faccio del mio meglio per rendere tutto il più generico e il più libero possibile dal contesto, il che significa che un buon progetto quasi tutto è nei moduli riutilizzabili)

Un ultimo punto che vorrei sottolineare è che per quanto piccolo e poco complesso possa apparire il tuo progetto, dovresti farlo dall'inizio, per due motivi:

  • i progetti aumentano in complessità, quindi è importante porre buone basi, incluso il css
  • anche un progetto che sembra semplice perché basato su WordPress ha poco JavaScript può essere ancora molto complesso nei CSS - OK, non devi fare alcuna codifica lato server, quindi quella parte è semplice, ma il front-end dell'opuscolo ha venti moduli e tre varianti di ciascuno: hai dei css molto complessi lì!

Componenti Web

Nel 2015 stiamo iniziando a esaminare i componenti Web. Non ne conosco ancora una grande quantità, ma cercano di riunire tutte le funzionalità del front-end in moduli autonomi, cercando efficacemente di applicare i tipi di principi dal BEM al front-end nel suo insieme e componendo i componenti ma totalmente accoppiati elementi come frammenti DOM, Js (MVC) e CSS che creano tutti lo stesso widget UI.

In questo modo essi affronteranno alcuni dei problemi originali che esistono con i CSS che abbiamo cercato di risolvere con cose come BEM, mentre lungo la strada rendiamo più sana qualche altra architettura di front-end.

C'è qualche ulteriore lettura qui e anche un quadro Polymer qui che vale la pena dare un'occhiata

Finalmente

Penso anche che questa sia una guida css di best practice eccellente e moderna, progettata specificamente per impedire che i grandi progetti css diventino confusi. Provo a seguire la maggior parte di questi.



0

c'è dell'ottimo materiale qui e alcuni hanno impiegato molto tempo a rispondere a questa domanda, tuttavia quando si tratta di fogli di stile separati o individuali andrei con file separati per lo sviluppo e poi passerei a utilizzare tutti i tuoi CSS generici in tutto il sito unito in un singolo file quando distribuito.

in questo modo hai il meglio dei due mondi, aumenta le prestazioni (meno richieste HTTP richieste dal browser) e separazione dei problemi di codice durante lo sviluppo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.