Troppo facile passare dallo spaghetti html all'xhtml/css pieno di div, spam e class
Nonostante molti professionisti del web si siano lasciati alle spalle un html stile anni '90 fatto di table per la formattazione, img spacer e frame, evolvendo verso la scelta di un moderno xhtml con css per la definizione degli stili, è altrettanto vero che spesso questo si concretizza in un html che abbonda, o meglio abusa di div, span, class.
Aprire il codice sorgente di una pagina in formato xhtml e trovarci dentro una catena perversa di div incastrate una dentro l'altra, usate per racchiudere un semplice paragrafo a cui si vuole attribuire uno stile, spesso è il sintomo della buona intenzione dello sviluppatore web (probabilmente non appartenente all'ultimissima generazione) che si è però persa per strada, ma che potrebbe essere recuperata attraverso l'adozione di alcune semplici regoline.
Le "regoline" sarebbero le seguenti:
- id: quando abbiamo un elemento che siamo sicuri che sia univoco all'interno della pagina, attribuiamogli un id; i più comuni elementi che costitiuiscono una pagina possono avere il loro id se non sono ripetuti nella pagina: "filodiarianna" per la barra di navigazione nota anche come breadcrumb, "spallasx" e "spalladx" per le colonne laterali che spesso circondano il corpo della pagina, "testata", "piepagina" per il footer, "fotoprincipale" etc.
- se questi elementi hanno un loro container naturale, evitiamo di avvolgerli su una inutile div; ci sono tantissimi elementi nelle pagine che sono fatto delle liste (di link, di voci, di immagini) e che possono essere codificate attraverso gli appositi tagul e li; ad esempio la barra di navigazione puo' essere rappresentata come una <ul id="filodiarianna"> senza bisogno di div;
- cerchiamo di dare una logica rigida all'html di questi elementi in modo che agganciandoci all'id, tramite css riusciamo a fare le impostazioni ai suoi elementi senza dover aggiungere class o span, ma attraverso i selettori di tipo, di attributo, di adiacenza e discendenza, pseudo-classi e pseudo-elementi del css;
- quando un elemento non e' univoco nella pagina, usiamo le classi; ma usiamole per identificare degli elementi logici e non dei comportamenti: ad esempio una classe "galleria" associata alle liste delle gallerie delle foto va bene, ma evitiamo classi chiamate "left", "red", "azzurrino", "spazioverticale", che spesso altro non sono che il vecchio modo di scrivere l'html con i font dentro l'html mascherati da classi;
- span va usato per identificare un segmento di testo (e non una sezione di pagina) che non e' altrimenti isolabile; dentro uno span non ci può essere un div, un <p>
- assolutamente da evitare gli stili embedded dentro il codice html: gli stili vanno messi su file css esterni; anche in fase di studio e prototipizzazione e' un rischio creare degli stili embedded che poi vengono spostati su appositi fogli di stile, a causa delle regole di specificity del css che fanno in modo che spostando uno stile embedded in un foglio di stile cambi completamente il risultato finale
e poi:
- il fatto di essere italiani (o meglio non anglofoni) ci da una utile opportunita': per i nomi degli id e delle classi, tra inglese e italiano scegliamo sempre l'italiano perche' oltre farci capire immediatamente che si tratta di ci consente una maggiore separazione tra le nostre definizioni e quelle di sistema; "filodiarianna" è quindi meglio di
http://www.ibm.com/developerworks/library/x-html5/?ca=dgr-lnxw01NewHTML
Aprire il codice sorgente di una pagina in formato xhtml e trovarci dentro una catena perversa di div incastrate una dentro l'altra, usate per racchiudere un semplice paragrafo a cui si vuole attribuire uno stile, spesso è il sintomo della buona intenzione dello sviluppatore web (probabilmente non appartenente all'ultimissima generazione) che si è però persa per strada, ma che potrebbe essere recuperata attraverso l'adozione di alcune semplici regoline.
Le "regoline" sarebbero le seguenti:
- id: quando abbiamo un elemento che siamo sicuri che sia univoco all'interno della pagina, attribuiamogli un id; i più comuni elementi che costitiuiscono una pagina possono avere il loro id se non sono ripetuti nella pagina: "filodiarianna" per la barra di navigazione nota anche come breadcrumb, "spallasx" e "spalladx" per le colonne laterali che spesso circondano il corpo della pagina, "testata", "piepagina" per il footer, "fotoprincipale" etc.
- se questi elementi hanno un loro container naturale, evitiamo di avvolgerli su una inutile div; ci sono tantissimi elementi nelle pagine che sono fatto delle liste (di link, di voci, di immagini) e che possono essere codificate attraverso gli appositi tagul e li; ad esempio la barra di navigazione puo' essere rappresentata come una <ul id="filodiarianna"> senza bisogno di div;
- cerchiamo di dare una logica rigida all'html di questi elementi in modo che agganciandoci all'id, tramite css riusciamo a fare le impostazioni ai suoi elementi senza dover aggiungere class o span, ma attraverso i selettori di tipo, di attributo, di adiacenza e discendenza, pseudo-classi e pseudo-elementi del css;
- quando un elemento non e' univoco nella pagina, usiamo le classi; ma usiamole per identificare degli elementi logici e non dei comportamenti: ad esempio una classe "galleria" associata alle liste delle gallerie delle foto va bene, ma evitiamo classi chiamate "left", "red", "azzurrino", "spazioverticale", che spesso altro non sono che il vecchio modo di scrivere l'html con i font dentro l'html mascherati da classi;
- span va usato per identificare un segmento di testo (e non una sezione di pagina) che non e' altrimenti isolabile; dentro uno span non ci può essere un div, un <p>
- assolutamente da evitare gli stili embedded dentro il codice html: gli stili vanno messi su file css esterni; anche in fase di studio e prototipizzazione e' un rischio creare degli stili embedded che poi vengono spostati su appositi fogli di stile, a causa delle regole di specificity del css che fanno in modo che spostando uno stile embedded in un foglio di stile cambi completamente il risultato finale
e poi:
- il fatto di essere italiani (o meglio non anglofoni) ci da una utile opportunita': per i nomi degli id e delle classi, tra inglese e italiano scegliamo sempre l'italiano perche' oltre farci capire immediatamente che si tratta di ci consente una maggiore separazione tra le nostre definizioni e quelle di sistema; "filodiarianna" è quindi meglio di
breadcrumb. Puo' essere ad esempio facile usare dei nomi che entrano in conflitto con i nuovi tag proposti dall'html5: section, header, footer, nav, article, menu
http://www.ibm.com/developerworks/library/x-html5/?ca=dgr-lnxw01NewHTML
Commenti