Il foglio di stile perfetto
Giovedì 18 Gennaio 2007 - 10:05
di Alessandro Fulciniti
Ogni sviluppatore aspira alla perfezione… al modo migliore, a quello più veloce, a quello più efficace e pratico per fare le cose. In quanto ai CSS la perfezione (a parte quella della resa sui browser) del codice è molto soggettiva. Qui vi presento la mia selezione di caratteristiche del foglio di stile perfetto:
- Valido
- Semplice
- Logico
- Leggero
- Robusto
- Cross-browser
- A prova di futuro
- Non ridondante
- Ben organizzato
- Regole e dichiarazioni suddivise secondo una logica
- Senza hack né workaround
- Senza dichiarazioni superflue
- Ben ottimizzato
- Facilmente leggibile
- Commentato il giusto
Tra le caratteristiche che ho elencato sopra manca forse la più importante, quella che quasi le riassume tutte: la mantenibilità.Personalmente, punto soprattutto sulla semplicità, sulla compatibilità cross-browser e sull’ottimizzazione… E voi, su quali puntate quando scrivete CSS? Quali sono le più importanti a vostro parere? Ne ho dimenticata qualcuna?
Commenti
1
Io penso manchi un termine chiave… Versatile… Io quando faccio un CSS penso soprattutto che sia facile da “modificare” e da adattare ad ogni situazione.
2
Una caratteristica che si interseca parzialmente con alcuni dei vari punti potrebbe essere “modulare”. Ovvero dividere le regole in più fogli di stile in modo da individuare meglio dove apportare eventuali correzioni
Ad esempio nei miei lavori prediligo l’uso di
- un CSS di base (che fa tabula rasa dello stile di default dei browser e imposta alcune regole di base come il clearing, l’image replacement etc.);
- uno per eventuali menu multilivello (soprattutto quando sono complessi e devono funzionare anche senza javascript)
- uno con le regole specifiche per la pagina
- vari fogli di stile con commenti condizionali per correggere eventuali problemi con IE 6 e minori (possono anche non servire in certi casi)in questo modo è possibile che vi sia qualche isolata ridondanza di regole, ma di certo riesco a gestire meglio eventuali modifiche. Inoltre visto che lavoro in un team di sviluppo, in questo modo rendo leggibile il mio lavoro anche ad altre persone.
Circa i 15 punti della lista mi sembra un pò difficile poterli raggiungerli tutti poichè alcuni sono in contrasto con altri. Ad esempio se volessi fare un css “ben ottimizzato” (anche in termini di peso) dovrei comprimerlo al punto di togliere molti commenti e renderlo illegibile (ad esempio scrivendo tutte le regole in un unica linea)
Sulla regola 11 sono d’accordo sul fatto di non inserire hack (contrasterebbero con la regola fondamentale “a prova di futuro”) ma l’uso di workarounds si rende necessario più spesso di quanto non si vorrebbe e se realizzati in modo ragionato possono benissimo convivere (ad esempio il workaround sul min-height in IE)
# - postato da Fabrizio Calderan - 18 Gennaio 2007 - 11:06
3
Nomi assegnati a classi etc etc di facile comprensione, soprattutto nell’ottica di un futuro (che si spererebbe lontano eh!, ma poi è sempre imminente) in cui ci si andrà a rimettere mano, non sempre io in prima persona ma anche collaboratori che intervengono in un secondo tempo.
Pertanto nei miei css non troverai mai cose del tipo
.class1{….}
.class2{….}Trovo fondamentale, soprattutto per chi lavora in gruppo, che ci sia una convenzione ben definita su come realizzare i css. Ne segue anche una documentazione esaustiva sul come e sul perchè nel progetto X si sono adottate certe soluzioni piuttosto che altre. Questo a futura memoria del gruppo di lavoro, nonchè per rapida formazione dei nuovi collaboratori.
Ho notato che questo metodo di lavoro riduce notevolmente i tempi di sviluppo dei css per i nuovi siti.Per quanto riguarda i workaround, hai perfettamente ragione: non dovrebbe esserci questa necessità. A volte è possibile fare css senza workaround, spesso purtroppo no. Sempre che l’obiettivo finale sia ottenere lo stesso identico risultato su tutti i browser(s) a disposizione….
O almeno, io non ci sono ancora riuscito…
Grazie a chi mi vorrà segnalare qualche risorsa in merito.# - postato da bobbibi - 18 Gennaio 2007 - 11:12
4
Che intendi per “Ben ottimizzato“? Devo dire che tendo a tenerli semplici, validi ecc. ecc. tuttavia mi riescono sempre un po’ complicati. Tendo a frazionarli per “scopo” ossia foglio stile per gli elementi del catalogo, foglio stile generale per la grafica ripetuta, foglio stile per le pagine di presentazione, ecc. ecc.
I workaround per il motivo “Cross Browser” sono necessari per le bizzarrie interpretative dei vari browser…
5
Io vorrei sapere quali sono le ditte che ti permettono di passare tempo ad “organizzare” un css………
6
Spesso il concetto è relativo, e dipende dal modo in cui lavoriamo. Sto facendo delle prove sul mio sito con i CSS provando a dividere il singolo foglio in più file.
Per esempio separo l’ossatura ‘bone’ (il fatto di avere le 2 colonne) così da poterla riutilizzare semplicemenete anche in un altro sito, o eventualmente cambiarla se necessario.
Oppure la tipografia, o i link sono tutti in file separati.
Questa filosofia, che ritengo precisa e utile, ha però qualche controindicazione. Innanzitutto quando viene richiesto il CSS dal marcatore link vengono poi generate, da un punto di vista HTTP tante richieste quanti sono i file (e ogni richiesta ha un suo carico a se stante).
Inoltre è scomodissimo fare un aggiornamento e modifica in corso d’opera per via della cache. Si può usare un pò di scripting server side per settare meglio i parametri della cache ,ma spesso i browser sovrascrivono tale impostazione.
Cosa succede? Che per fare un aggiornamento va prima provato il tutto con un CSS interno, non inline, che va a sovrascrivere il CSS in cache, e poi si rimette tutto a posto.
Altra logica, sempre in fatto di performance e carico minore sul server, potrebbe essere usare un CSS compresso, ma poi diventa, all’occhio umano, abbastanza illeggibile.
# - postato da Simone Onofri - 18 Gennaio 2007 - 11:32
7
Colgo dunque l’occasione per invitare tutti, se poi si vuol continuare la discussione sui questi temi dal vivo, se ne parlerà al BarCamp di Roma! :)
# - postato da Simone Onofri - 18 Gennaio 2007 - 11:37
8
..la 11 e la 6 fanno un po a cazzotti…
# - postato da kentaromiura - 18 Gennaio 2007 - 11:40
9
Concordo con chi dice che alcuni punti sono difficili da avere in contemporanea, magari questi corrispondono ad una situazione ideale, ma per varie cause questa è lontana dalla realtà.. basti pensare ai problemi con IE6.
Io cerco sempre di puntare sulla leggibilità e sulla semplicità eliminando le dichiarazioni superflue e ridondanti. Qualche commento può far comodo per identificare le varie sezioni.
Rispondendo a Sergio: sicuramente in un’azienda non hai molto tempo da dedicare alla riorganizzazione di un foglio di stile, ma se si acquisisce un metodo di scrittura già ottimizzato molti problemi vengono superati a priori.
10
Ciao,
sono tutti parametri condivisibili. Però penso non vadano intesi come una lista, piuttosto come una “radar chart“, che rende meglio l’idea di parametri che possono anche essere in conflitto tra loro. Il CSS migliore sarebbe quello che copre un’area maggiore.
11
ritengo i commenti nei CSS quasi inutili…
il mio consiglio è di commentare i CSS il meno possibile :-)# - postato da Andrea Paiola - 18 Gennaio 2007 - 12:24
12
La leggibilità non merita il 14° posto, secondo me.
Riassume già molti punti importanti, come le dichiarazioni secondo una logica, codice ben organizzato e modulare.Spesso per cercare di ottimizzare al massimo si perde molto sulla leggibilità. E’ da chiedersi a quel punto se quei 1-2k risparmiati valgano la fatica che causano nel leggere e nel rimettere mano al codice.
Ancora linee guida non ne ho trovate, ognuno fa giustamente secondo il suo gusto, ma secondo me un modo sensato di scrivere CSS sta nel mezzo tra leggibilità e ottimalità.
Perchè alla fine il CSS è letto dal browser (e quindi deve essere ottimizzato), ma molto spesso è letto anche dalle persone
13
Ciao Tom: a proposito, complimenti per il premio HT, e anche ad Andrea che lo ha votato :)
# - postato da Simone Onofri - 18 Gennaio 2007 - 12:32
14
Mega CSS unico per tutto il sito oppure tanti piccoli CSS??
Come dice Simone Onofri, è meglio ridurre le richieste HTTP.
Ma se io ho un mega CSS ha veramente senso farlo caricare tutto?
Non ho mai capito qual è la soluzione migliore. Nelle varie guide sul css coding best practises segnalate qui sul blog c’è chi mette tutto in un CSS unico, compresi layout diversi che si cambiano correggendo l’id sul body, e chi invece dice consiglia i CSS modulari, per facilitare, tra l’altro, editing e riciclaggio in siti futuri.Mah…
Forse la soluzione migliore va decisa valutando caso per caso, come sempre…
# - postato da Cheope - 18 Gennaio 2007 - 12:45
15
Andrea: che unito alla tua dichiarazione di qualche post fa sui commenti al codice (”un buon codice si commenta da solo”) fa sì che si capisca che tu
a) non commenti niente
b) scrivi codice parlante:)
16
Piccola precisazione: non si tratta di una vera e propria classifica… le caratteristiche sono in ordine quasi random, ho pensato che comunque fosse importante numerarle :-)
In quanto ai commenti, a parer mio é essenziale anticipare le varie sezioni dei CSS e commentare eventuali hack e workaround.
Per l’ottimizzazione, e in generale le buone pratiche di sviluppo: credo che vadano fatte in fase di scrittura.
# - postato da Alessandro Fulciniti - 18 Gennaio 2007 - 13:22
17
Secondo me i commenti sono fondamentali… non bisogna scrivere il IV canto dell’Inferno ma sono essenziali per lavorare in gruppo e per “riconoscersi” a distanza di tempo.
Diciamo che può essere furbo, per limitare i commenti, utilizzare classi e identificatori in modo referenziale (es. #colonna-destra non ha bisogno di commenti) ed espressivo. A patto di rinunciare a qualcosa sul piano della sintesi (es. #colonna-destra Vs #cd)
18
Io sono pienamente d’accordo su ciò che dice Fabrizio Calderan, ovvero che oltre le citate caratteristiche un’altra molto importante è la “modularità”, che poi volendo può essere vista associata anche alla caratteristica N°9 (Ben Organizzato) della lista sopra citata.
E’ molto importante suddividere i CSS dei menù da quelli con le regole specifiche per le singole pagine, ecc. Perchè così si ha una maggiore leggibilità ed è più facile poi aggiornare il codice.
19
si scrivo codice parlante: certe volte gli faccio parlare addirittura piemontese :D
# - postato da Andrea Paiola - 18 Gennaio 2007 - 15:28
20
Troverei interessante stilare anche una lista di errori da evitare in fase di stesura dei css che rendono imperfetto il foglio di stile e che poi ne complicano la gestione complessiva. Ad esempio iniezierei evitando nomi di identificatori e classi che siano legati in qualche modo all’aspetto visuale del layout.
Ad esempio potrei definire una classe .testorosso ma se per qualche motivo quell’elemento cambia il colore in un momento successivo ho perso un riferimento utile nel foglio di stile (e poi sfido a ritrovarlo quando il file ha una lunghezza non banale).
Preferisco invece assegnare dei nomi che siano associabili alla funzione che svolge l’elemento, ad es .titolonews . Per lo stesso motivo starei molto attento a definire ad es. anche un id del tipo #testobasso, perchè se dovesse cambiare la disposizione del blocco (oppure se venissero aggiunti in coda altri blocchi) mi troverei nella stessa situzione.
# - postato da Fabrizio Calderan - 18 Gennaio 2007 - 15:56
21
concordo con rocco:
deve essere versatile.
22
Io sono a favore della divisione dei css in vari file senza esagerare, ho un css per gestire i form che riuso frequentemente e mi trovo benissimo.
Sono contrario al 100% all’uso dei workaround:
firefox, opera e safari si comportano in modo molto simile così mi basta gestire Internet Explorer tramite commenti condizionali su cui posso fare affidamento al 100% anche in futuro.
Inoltre adesso come adesso ogni sito che si rispetti ha un linguaggio server di supporto tramite il quale, essendo pignoli, si puo’ servire un css diverso a seconda del browser e del sistema operativo.Per curiosità, voi di solito scrive codice del tipo:
#header #navigation ul li .link{}
oppure
#navigation .link{} ?# - postato da Grab - 19 Gennaio 2007 - 10:08
23
> Per curiosità, voi di solito scrive codice del tipo:
> #header #navigation ul li .link{}
> oppure
> #navigation .link{} ?Dipende spesso dalla cascata. Uso la seconda opzione per una regola generale; mentre se devo scrivere una… regola per un’eccezione, laddove esistono già regole soprastanti preferisco scrivere il percorso completo dei selettori.
Mi evita sorprese nei fogli (o nei sistemi di fogli) complessi.
Parlando di organizzazione dei fogli, senza commenti non vivrei. Mi càpita di dover riprendere in mano vecchi lavori; e senza i titoli di sezione nei fogli grandi o i poemetti che spiegano alcune regole astruse o complesse, l’editing mi prenderebbe del gran tempo in più.
Inoltre ho imparato e imparo molte cose leggendo i CSS degli altri. Al di fuori delle normali situazioni di lavoro in team, se mai qualcuno dovesse leggere i miei CSS per “capire come ho fatto” mi fa piacere l’idea di avergli reso più agevole l’apprendimento :-)
24
PER FAVORE AIUTATEMI!!!!
Non riesco a creare un foglio di stile css, come faccio a sistemare la posizione di immagini, banner o barra menu??
se metto la barra al posto giusto le scritte che ci sono a fianco scendono giu!
come faccio??? risp please!!# - postato da HELP!!! - 30 Gennaio 2007 - 21:39
25
Sto cercando di rendere un sito,realizzato da un’ altra persona, accessibile e per ora cio’ che ho fatto e’ stato:
1)ho modificato il codice in modo tale che il Markup Validatio Service non mi desse errori
2)ho modificato css,sto usando plone come cms,in modo tale che facendolo test su di esso non risultino piu’ errori ma solo avvisi
volevo sapere devo eliminare anche gli avvisi,operazione che a me sembra complicata,oppure mi basta aver eliminato gli errori?se ho ancora ,solo,degli avvisi posso mettere sulle pagine del sito l’icona che il css e’ valido?Quale dovrebbe essere il passo successivo da compiere per quanto riguarda l’accessibilita’ del sito?
grazie a tutti
# - postato da ludovico - 31 Gennaio 2007 - 15:05