Organizzazione CSS fai-da-te

Detesto osservare il codice o il mark-up che ho scritto in passato, che non capisco subito. Non sono sicuramente diverso da te in quanto voglio essere in grado di tornare anni dopo, prendere il codice e capire esattamente cosa sta succedendo. Non voglio analizzare i concetti più semplici, dove si trovano le parentesi, o persino il modo in cui il mark-up è rientrato. Ho creato abitudini per aiutarmi con un rapido sviluppo, che ha mantenuto la mia sanità mentale piuttosto intatto. Sarò onesto, però, non ho mai pensato molto a come scrivo e organizzo il mio CSS fino a poco tempo fa, ed è quello che sto condividendo oggi.


Introduzione: perché preoccuparsi?

Ci sono molti modi per fare ciò che sto suggerendo con i CSS. Lasciatemi essere il primo a dire, non usare nulla di cui ti scrivo oggi se il tuo livello di comfort non è elevato con i miei concetti. Invece, pensa ai concetti e migliora le soluzioni di cui sto scrivendo. Condividi le tue intuizioni. Non discuterò con te se pensi che ci sia un modo migliore per organizzare i fogli di stile, perché alla fine non esiste un modo giusto o sbagliato. Tuttavia, credo che maggiore è la struttura che aggiungi, meglio sarà alla fine quando lavori con i CSS.

"Quanto è facile per noi, come sviluppatori, trovare, capire, riparare o aggiungere rapidamente a una determinata base di codice? Più facile è il compito, migliore è l'usabilità interna."

Ci sono un paio di concetti che voglio coprire ora in generale per far funzionare i succhi del cervello. Innanzitutto, vi è una concentrazione sull'usabilità con lo sviluppo web. Vogliamo che gli utenti dei nostri siti Web trovino le cose più velocemente, navigino in modo più naturale e in generale comprendano intrinsecamente i concetti delle nostre applicazioni. È un uso molto degno di tempo ed energia. Ciò che a volte viene dimenticato è l'usabilità interna in tutte le fasi di pianificazione e discussione dei nostri progetti. Quanto è facile per noi sviluppatori, trovare, capire, riparare o aggiungere rapidamente a una determinata base di codice? Più facile è questo compito, migliore è l'usabilità interna. Secondo me, questo concetto è degno del nostro tempo e pensato come l'usabilità del front-end.

Secondo, ricorda che c'è una C in CSS. È la parte a cascata. Il metodo che uso potrebbe volare di fronte a certi pensieri convenzionali, ma quando ti ritrovi in ​​un angolo solo per l'utilizzo di alcuni aspetti del CSS, perdi il potere. Quando sto pianificando un progetto di grandi dimensioni, penso ai selettori id come "spiega l'entità", ai selettori di classe come "descrivi l'entità" e agli attributi di stile come "sostituisci ciò che ho appena detto". Abbasso le proprietà in cascata per ridurre il codice e dare un pò di metodo alla follia. Di nuovo, non ci sono modi giusti o sbagliati, ma quando non hai un piano, ti stai preparando per un sacco di lavoro extra, per non parlare di un sovraccarico extra.

Infine, ricorda che ci sono sempre dei compromessi in fase di sviluppo. I modi più eleganti di fare le cose non sono sempre i più efficienti.

A volte, i modi più efficienti di fare le cose ti costano la strada quando devi raccogliere il codice per il supporto.

Nessuno può fare queste scelte per te, ma devi considerare i compromessi mentre scrivi. A volte devi mordere il proiettile solo un po ', forse per aggiungere una richiesta HTTP aggiuntiva per rendere il risultato finale utilizzabile internamente. Altre volte, è necessario aggiungere un buon commento per ricordare la scelta che hai fatto e andare avanti.


Un paio di scelte: quadri o Il selvaggio West

È probabile che tu stia utilizzando un framework per gestire il tuo CSS o che tu stia aggiungendo i tuoi stili in un modo a cui ti sei abituato, ma senza troppa struttura. Entrambi hanno i lati positivi e negativi. Diamo un'occhiata ad alcuni framework CSS prima, dalle bocche dei cavalli:

Planimetria

YUI 2

Baseline

YAML

Ce ne sono molti altri, e proprio come un framework per il linguaggio di scelta del vostro server, ognuno ha i suoi vantaggi l'uno sull'altro e ognuno ha i suoi svantaggi. Non sono qui per allontanarti da un quadro, come li ho usati in passato e credo nei concetti. Penso che quando lavori su una grande squadra, non esiste una scelta migliore in quanto standardizza i tuoi stili e dà lezioni voce del singolo sviluppatore e designer. Detto questo, credo che ci siano alcuni inconvenienti nell'usare un framework CSS, poiché si aggiunge al sovraccarico in particolare con gli stili che non si utilizzano e la curva di apprendimento è piuttosto alta. Questo può essere un po 'frustrante in particolare con i progetti che hanno orari rigidi. Detto questo, la curva di apprendimento è proprio questa, una curva, e nel tempo padroneggierai qualsiasi progetto tu ritenga migliore. Il vantaggio dell'utilizzo di un framework è che ora hai migliorato la tua usabilità interna, poiché stai utilizzando un paradigma di metodo set, sebbene quel metodo sia qualcosa che è probabilmente fuori dal tuo controllo.

Selvaggio West

L'altra soluzione è quella che chiamo "Wild West" dove tutto va bene. Sarò onesto e dirò che ci sono molte volte in cui ho spinto qualcosa fuori dalla porta senza pensare troppo al futuro, o nel caso di un progetto molto piccolo in cui il CSS non è molto consistente. La curva di apprendimento qui non è così male, perché stai scrivendo il tuo CSS mentre vai. Hai il controllo completo sul destino del tuo stile. Abbastanza fresco finora! Il problema è l'usabilità interna. Torna a quel progetto dopo che non è più fresco nella tua mente, e ci saranno alcuni problemi. "Perché diavolo ho scritto questo come questo" o "Non ho idea di cosa intendessi con questo commento" o "Perché quell'input non cambia gli stili" o "cos'è questo grosso pezzo di controllo chum" sono risposte comuni dopo il il foglio di stile non è più nella tua mente.


La mia scelta: la soluzione ibrida

Se potessi mettere la soluzione quadro su una scala mobile con la soluzione wild west dall'altra parte, penso che preferirei qualcosa solo nel mezzo. Mentre un letto è troppo duro, e l'altro letto è troppo morbido, voglio trovare il letto che è giusto. Questo è ciò che chiamo la soluzione ibrida. Condivide i tratti sia con il selvaggio west che con i quadri. Da un lato, ho il controllo sui miei stili, e con ciò la curva di apprendimento è piuttosto bassa. Dall'altro, voglio dare una piccola struttura a ciò che scrivo, in modo che quando tornerò in seguito, avrò almeno una familiarità con la struttura perché costruisco i miei metodi che ogni progetto.

È un po 'un progetto fai-da-te come nel miglioramento domestico. Stai scambiando la struttura e il costo di un professionista per la comodità e la familiarità di usare le tue mani per fare il lavoro. Quello che speri alla fine è lo stesso progetto finito, ma uno senza la curva di apprendimento o idee e concetti estranei dalla versione di forza industriale.


Convenzione sulla denominazione dei file

Ripensando alle scelte che dobbiamo fare come sviluppatori, faccio la scelta di aumentare le richieste HTTP per un'organizzazione leggermente migliore. So che mi sto costando un po 'di prestazioni, ma quello che ottengo alla fine è CSS che è più facile da capire quando devo guardarli dopo. Puoi fare una scelta diversa qui, e non avrai molte discussioni da parte mia. Preferisco le dimensioni dei file più piccole organizzate in modo coerente sull'unico file CSS o intestazione nel mio HTML.

Ecco cosa funziona per me:

  • reset.css : Un css di ripristino è uno che imposta tutti o almeno la maggior parte degli stili di browser per annullare. Utilizzo un css di ripristino in modo da poter contrastare alcune differenze con i browser e vedo il valore quando si affrontano problemi relativi a browser diversi. Non è Nirvana, e ci sono alcuni che preferiscono non resettare, o quello che ho letto di recente, un soft reset. Preferisco ripristinare tutto, e io uso il sapore di reset di Eric Meyer.

  • forms.css: Separo i miei stili di forma dal resto del mio CSS. Voglio sapere quando sto lavorando ai moduli, e non stanno apparendo come vorrei esattamente dove andare.

  • global.css: Il mio file css globale è qualcosa che uso per ogni progetto più grande che scrivo. Ciò che è contenuto in questo piccolo file sono piccole classi che potrei usare più e più volte nei progetti. La mia regola generale è, se c'è una scorciatoia per la proprietà, quindi probabilmente non appartiene al file globale. Non userei la proprietà del carattere. Per esempio:

 / * Colori * / .red colore: rosso; sfondo: ereditario;  .blue color: blue; sfondo: ereditario;  .highlight color: black; sfondo: giallo;  / * Lists * / .horizontal list-style-type: none; display: inline;  .vertical list-style-type: none; blocco di visualizzazione;  / * Testo * / .small dimensione carattere: piccolo;  .large font-size: large;  .bold font-weight: bold; 

Si noti che queste sono classi molto specifiche, che si aggiungono alle regole a cascata degli stili. Mentre generalmente nessuno sarà usato come unico stile per un elemento, essi aggiungono alla descrizione dell'elemento che la classe è applicata.

  • style.css: My style.css è il mio controller principale del mio stile. Se si pensa in termini di OO per CSS, my style.css è la mia classe, mentre gli altri file estendono la mia classe (in qualche modo comunque) e si aggiungono all'eredità dei miei oggetti principali. Uso il mio style.css per importare i miei altri file e per definire i miei selettori e classi locali, solo progetto, id.


Selettori di ID e di classe: pensate diversamente

Il mio metodo ibrido diverge qui dalla maggior parte delle persone, dato che la mia regola generale con gli id ​​è semplicemente quella di spiegare l'elemento in questione. I selettori ID vengono utilizzati una sola volta per pagina (inclusi i processi GET), quindi desidero che questi siano di natura molto specifica. Per massimizzare davvero il riutilizzo del codice, qualsiasi proprietà al di fuori di quella spiegazione di un elemento, preferirei davvero utilizzare un selettore di classe. Dato che questo ID è unico per la pagina, voglio solo usare spiegazioni univoche per questo selettore.

Ad esempio, la mia larghezza sarebbe in qualche modo unica. Il mio padding e margine sarebbe in qualche modo unico. La mia posizione sarebbe in qualche modo unica. Si potrebbe sostenere che la visualizzazione di questo selettore sarebbe in qualche modo unica. Il mio colore per l'elemento; non proprio unico Il mio background, ancora non proprio unico. Per gli oggetti non proprio unici, penso a questi come "descrivi l'elemento" per il quale utilizzo i selettori di classe.

Illustriamo questo con un piccolo codice. Per facilità, sto usando un recente tutorial di Jeffrey Way intitolato Quick Tip: Practical CSS Shapes. Cosa succede se abbiamo preso il CSS originale:

 #container background: # 666; margine: auto; larghezza: 500 px; altezza: 700 px; padding-top: 30px; font-family: helvetica, arial, sans-serif;  h1 background: # e3e3e3; background: -moz-linear-gradient (in alto, #e3e3e3, #c8c8c8); background: -webkit-gradient (lineare, in alto a sinistra, in basso a sinistra, da (# e3e3e3), a (# c8c8c8)); imbottitura: 10px 20px; margin-left: -20px; margin-top: 0; posizione: relativa; larghezza: 70%; -moz-box-shadow: 1px 1px 3px # 292929; -webkit-box-shadow: 1px 1px 3px # 292929; box-shadow: 1px 1px 3px # 292929; colore: # 454545; text-shadow: 0 1px 0 bianco; 

e trasformato in questo:

 #container margin: auto; larghezza: 500 px; altezza: 700 px; padding-top: 30px; font-family: helvetica, arial, sans-serif;  # heading-one padding: 10px 20px; margin-left: -20px; margin-top: 0; posizione: relativa; larghezza: 70%;  .norm-background color: #fff; sfondo: # 666;  .heading-fancy background: # e3e3e3; background: -moz-linear-gradient (in alto, #e3e3e3, #c8c8c8); background: -webkit-gradient (lineare, in alto a sinistra, in basso a sinistra, da (# e3e3e3), a (# c8c8c8)); -moz-box-shadow: 1px 1px 3px # 292929; -webkit-box-shadow: 1px 1px 3px # 292929; colore: # 454545; text-shadow: 0 1px 0 bianco; 

Finora, tutto ciò che ho fatto è stato aggiungere due nuove classi dal selettore di h1 univoco e astratto che h1 a un ID univoco. Non ho guadagnato nulla per il momento, e in realtà ho aggiunto solo un po 'di overhead al mio file. Dov'è il vantaggio allora?

Se pensate per un momento che potreste riutilizzare queste descrizioni da qualche altra parte, forse per un sottotitolo, allora abbiamo del riutilizzo del codice. Diamo un'occhiata per vedere cosa possiamo fare ora. Ecco come appare in origine:

ed ecco come appare con un sottotitolo:

Ho solo aggiunto una nuova definizione ora:

 # heading-two padding: 10px 20px; margin-left: -20px; margin-top: 0; posizione: relativa; larghezza: 30%; 

Insieme a un piccolo HTML:

 

La mia intestazione

La mia sottorubrica

Abbiamo il riutilizzo del codice e abbiamo un metodo coerente. Se prendi questo metodo e lo applichi, ridurrai il numero di stili (o oggetti se preferisci) che scrivi. Meno codice con un metodo significa supporto più semplice in un secondo momento. Davvero, niente di sconvolgente qui, ma quando inizi a spiegare i tuoi selettori di ID ma descrivi le tue classi è un metodo semplice per aggiungere un po 'di sanità al tuo codice.


Attributi di stile

Sono sicuro che qualcuno, da qualche parte, ti ha detto di non usare mai l'attributo style. Sono anche sicuro che alcuni di voi non saranno d'accordo con me, e questo è OK, posso prenderlo. Ho intenzione di infrangere quella regola solo un po 'con un avvertimento. Non usarlo mai senza pensarci troppo su quello che stai facendo. Esistono usi legittimi per l'attributo style, in particolare quando si lavora con applicazioni complesse che utilizzano chiamate AJAX, ma tali usi provengono dal proprio livello di comportamento.

Quando si utilizza l'attributo style, è quando è necessario effettuare una chiamata finale rapida per sovrascrivere qualcosa nella visualizzazione a cascata per l'elemento che non avrebbe senso aggiungere al file global.css. Ad esempio, potresti dover sostituire uno stile dal tuo livello di comportamento in base a un'azione dell'utente. Aggiunge alla complessità solo un po ', ma si aggiunge alla cascata. Non utilizzerei più proprietà, in quanto si tratta di un rapido intervento, o meglio, "dimentica quello che ti ho appena detto, fallo invece". È una cascata, e dovresti trattare il tuo CSS come tale, secondo me.


Indentazione, layout e commenti

Trascorriamo molto tempo mettendo l'accento sulla nostra indentazione nel nostro codice e HTML, ma non vedo spesso la stessa enfasi nel nostro CSS. Fa il mondo della differenza. Riprendiamo il nostro esempio operativo:

 

La mia intestazione

La mia sottorubrica

Se indentiamo questo nel nostro markup, perché non indentarlo allo stesso modo nel nostro CSS:

 #container margin: auto; larghezza: 500 px; altezza: 700 px; padding-top: 30px; font-family: helvetica, arial, sans-serif;  # heading-one padding: 10px 20px; margin-left: -20px; margin-top: 0; posizione: relativa; larghezza: 70%;  # heading-two padding: 10px 20px; margin-left: -20px; margin-top: 0; posizione: relativa; larghezza: 30%; 

Aggiunge solo un po 'più enfasi su ciò che sta succedendo con questi selettori di ID. Capisco ora che sono bambini al contenitore div senza paragonare il mio mark-up.

Quando decidi il layout del tuo file di stile, questa è la regola che uso. Devi @importare i tuoi file CSS aggiuntivi prima di iniziare con il file reset.css e poi il resto. Definisci i tuoi elementi successivamente come h1, ancore, ecc. Quindi, definisci i selettori ID nel tuo style.css. Se stai lavorando con più pagine, commenta l'inizio di ogni nuova pagina all'interno del tuo rientro. Ad esempio, #container è probabilmente un elemento del layout che è il contenitore per ogni pagina, quindi inizia da lì con il tuo rientro e risolvi i commenti su dove stai utilizzando ciascun elemento. Infine, definisci le tue classi. Normalmente non indentizzo le mie lezioni, perché sono spesso riutilizzate e il rientro non mostra dove sono usate.

Infine, e probabilmente la cosa più importante, commenta il tuo CSS come faresti con il tuo codice lato server. Se esiste un contesto che è possibile assegnare a una classe, ad esempio gli elementi utilizzati o l'ID corrispondente, commentarlo. Ogni contesto che offri al tuo futuro è come avere una macchina del tempo. Marty McFly potrebbe non aver buttato fuori quel ragazzo inquietante dal traffico in arrivo se avesse appena letto prima i commenti del condensatore di flusso.


Conclusione

Sono relativamente sicuro che i miei metodi non avranno una nuova mossa di danza che prende il nome, né curerà il cancro. Non sono nemmeno sicuro se saranno adattati da una singola persona al di fuori della mia famiglia. Detto questo, spero davvero che tu ti allontani dai concetti e costruisca metodi che funzionano per te. L'usabilità dello sviluppo è un obiettivo che tutti dovremmo cercare di raggiungere. Quando crei una metodologia, aumenti la tua usabilità interna in modo esponenziale mentre sviluppi abitudini che riutilizzi e condividi con la tua squadra e altre persone. Risolve i problemi di sviluppo, aumenta la produttività e riduce il costo complessivo dello sviluppo. È una di quelle rare proposte di vincita / vincita che incontri nella tua vita di sviluppo quotidiana.

Grazie per la lettura, e per favore condividi le tue idee.