Consigli utili per ottimizzare il codice HTML, mantenendo separato il contenuto dalla presentazione.
Nello sviluppo di un sito spesso ci si preoccupa degli aspetti più complessi per poi dimenticare i dettagli elementari. All’interno del codice HTML hanno una notevole importanza ID e classi, ma capita di utilizzare questi attributi senza attenzione, in maniera spesso controproducente.
In ogni progetto è fondamentale considerare almeno due aspetti riguardanti il codice delle pagine:
- le possibilità di sviluppo future
- la leggibilità
Per ottenere i migliori risultati e soprattutto consentire a chiunque di comprendere il codice HTML, è sufficiente ricordarsi alcuni punti ben illustrati sul blog di Jens Meiert che ho voluto approfondire.
1. Ridurre al minimo ID e classi
Finchè è possibile, evitate di appesantire il codice HTML e sfruttate i selettori discendenti dei CSS. Sono uno strumento potente, e potrete così limitare gli ID ai contenitori principali (ad esempio #container, #header, #nav…). Potrebbe sembrare un dettaglio di poco conto, ma con la pratica vi accorgerete che questa non è un’indicazione assurda, anzi.
Ovviamente su elementi che hanno bisogno di personalizzazioni su misura (ad esempio un’icona associata) è indispensabile l’uso di classi ad hoc, ma questo modo di pensare sarà molto utile anche in futuro con i selettori dei CSS3. Sarete già pronti ad utilizzarli senza dover cambiare le vostre abitudini di lavoro.
2. Utilizzare nomi relativi alla funzione dell’elemento
Uno degli errori più comuni è usare per ID e classi un nome relativo all’aspetto dell’elemento e non alla sua funzione. Un esempio potrebbe essere .red_text invece di .alert. Commettendo questo errore resterete vincolati, ed in futuro non potrete cambiare la visualizzazione di quel particolare elemento senza modificare anche il nome dell’attributo. Avere una classe .red_text che fa riferimento ad un elemento di colore diverso dal rosso sarebbe assurdo!
A questo proposito non ci sono degli standard (anche se non sarebbe male averli), ma è buona pratica usare nomi come #menu o #nav per la navigazione, #content per il corpo centrale del sito, #header e #footer per testata e piede. Osservando i layout dei web designer più famosi potete farvi un’idea di quali siano le convenzioni più diffuse.
3. Sintetizzare in maniera comprensibile
Per velocizzare il lavoro ed evitare di avere fogli di stile esageratamente lunghi è sempre meglio cercare di usare nomi brevi per ID e classi. Questo però non deve andare a scapito della comprensibilità: #nav è sicuramente meglio di #navigation, ma usare .wdg al posto di .widget sarebbe esagerato.
Quelli mostrati sono dettagli elementari: proprio per questo andrebbero sempre tenuti presenti. Non pensate che siano aspetti poco importanti, la realizzazione di un buon sito inizia proprio dal codice scritto. A questo proposito, quali sono le vostre convenzioni per l’uso di ID e classi? Lasciate un commento per discuterne insieme.
E’ importante quello che hai scritto, che risulta vitale per non appesantire troppo la pagina e soprattutto per semplificare il codice.
Per fare questo, sono importantissime anche le doppie classi.
e speriamo che tutti i designer abbiano finito il periodo di transizione che ormai dura da troppi anni!!!
Parole sante, complimenti!
Ottimo articolo! Prenderò spunto sicuramente. Grazie.
Sebbene i contenuti di questo articolo siano riscontrabili in molti altri siti penso sia opportuno riflettere su una cosa. Premetto che condivido l’articolo in questione. Per un progetto “Medio piccolo” ha veramente importanza tutto ciò? Cioè, fa veramente differenza se uno scrive .red anzichè .alert? Io sono un accanito sostenitore di layout con css ad esempio, ma non farei un gran baccano se in un progetto tuttavia l’impaginazione è affidata alle tabelle. Perchè? Perchè spesso web designer & Co. dimenticano lo scopo per cui fanno i siti internet. Per comunicare. Ciò che viene comuicato dev’eesere appunto ricevuto dall’utente, dal visitatore. Dover pure scrivere classi semantiche perchè è più elegante mi sembra a volte un’inutile spreco di tempo. non è vero che in ogni progetto sono indispensabili quelle due cose. in un progetto di 5 pagine chissenefrega della leggibilità del codice? Questi due punti descritti dall’articolo valgono per un progetto medio, grande, dove magari più persone collaborano. ma se si è da soli, si deve sbarcare il lunario e si vuole far felice il cliente magari in un piccolo progetto…. affanc.. anche le classi semantiche dico io. Il suo pubblico e lui aprezzeranno il tempo in meno che ci metterete per consegnare il lavoro. solo il webdesigner gode di aver fatto un buon codice. la maggior parte della gente nemmeno sa che la barra degli indirizzi è una cosa diversa dalla casella di ricerca della hompage di google, ve lo posso assicurare, figurarsi se al vostro cliente se ne frega se il codice è ben identato e con classi semantiche(faccio un esempio per dire). Cioè, ricapitolando :esaminate benissimo la situazione . Fate ciò che è estremamente necessario per ottenere un lavoro benfatto e veloce. non pensate. pensare a volte fa male. ciedete al cliente cosa è realmente necessario, esaminate la scena. se la scena richiede classi semantiche, tutto ok fate una lista delle classi e usatele. ma se non vale la pena dello sforzo, non fatelo, non verrà pagato, non sarà appagante, perchè mentre decidete se è meglio .alert o .attenzione o .warning il cliente si sta chiedendo che cavolo state facendo. ed ha ragione.
@alex: capisco quello che dici, ma è anche questione di abitudine, e non sempre è una perdita di tempo, anzi.
A me ormai viene naturale utilizzare certe convenzioni mentre scrivo del codice, e ci metterei molto di più a realizzare un sito con delle tabelle piuttosto che con XHTML e CSS. E’ vero che per progetti piccoli, portati avanti da soli, spesso è inutile, ma non è solo questione di scrivere del codice leggibile anche da altre persone… basta pensare a cosa succede riprendendo in mano un sito realizzato magari 1 anno fa: avere determinate convenzioni aiuta non poco ad orientarsi.
Certo, infatti sono assolutamente d’accordo. io stesso scrivo per sconforto personale, giusto perchè a volte non è pagato/apprezzato/notato dal cliente. Infatti il punto che forse non ho chiarito è che a volte, io in primo luogo perdo lo scopo del progetto , fissandomi sullo strumento per ottenerlo. Verissimo comunque che le buone abitudini aprono la strada al lavoro impeccabile.