HTML - Pagina 2 di 4 - TomStardust.com

Intestazioni HTML: guida all’uso

Raccomandazioni e pratiche comuni per un buon utilizzo delle intestazioni HTML

Le intestazioni all’interno del codice HTML sono elementi ben noti. Sono state però al centro di alcune discussioni sulla semantica: in particolare l’uso del tag h1 ha generato spesso pareri contrastanti per il suo utilizzo nelle pagine diverse dalla homepage.

Seguendo alcune discussioni in rete, e guardando la struttura di alcuni siti come quello di Roger Johansson, ho raccolto alcune indicazioni per una guida il più possibile definitiva, almeno fino alla prossima rivoluzione del web semantico. In questo riassunto ho tenuto conto anche dei requisiti per avere delle pagine quanto più possibile accessibili.

Regole generali per le intestazioni HTML

Una sola intestazione h1 per pagina
Coerenza, senza saltare nessun livello, passando da h1 ad h2, h3, e così via.

La struttura delle pagine

Homepage

h1 per il titolo del sito
h2 per i titoli delle sezioni principali o per i titoli dei post (blog)
h3, h4, h5… per titoli e sottotitoli secondari, in ordine di importanza

Pagine interne

titolo del sito evidenziato con strong o em, ma non h1
h1 per l’argomento principale della pagina, o il titolo del post (blog)
h2, h3, h4… per sezioni e sottotitoli, in ordine di importanza

L’elemento più delicato è sicuramente il titolo del sito: noterete che nelle pagine interne non è evidenziato da un h1, che invece viene usato per l’argomento specifico della pagina.

Fino a qualche tempo fa ero convinto che fosse bene utilizzare ovunque un h1 sul titolo del sito, ma ho dovuto ricredermi. In effetti non ha senso identificare questo titolo come l’elemento più importante nelle pagine interne, a maggior ragione se parliamo di un blog. In contesti simili è il soggetto del post ad avere maggior rilevanza: l’importante è che il sito sia comunque identificabile, ma questo può essere fatto anche senza utilizzare un’intestazione.

Io seguirò questi criteri nei miei prossimi progetti e nei futuri redesign. Noterete che questo stesso sito segue regole differenti: sono convinto che potrà essere indicizzato ancora meglio dai motori di ricerca con qualche piccola modifica nelle pagine interne.

Voi quali criteri utilizzate per le intestazioni? Siete d’accordo con queste linee guida o fareste diversamente? Lasciate un commento con il vostro parere, potrebbero emergere idee interessanti.

L’utopia del codice HTML valido

Uno spunto di riflessione sulla realizzazione di progetti con codice HTML valido.

Perchè esistono gli standard HTML? La risposta è semplice: deve esserci una base comune su cui poter sviluppare, e questa base deve essere capita e condivisa da tutti, per evitare incomprensioni e incompatibilità.

I problemi

In questo scenario, esistono numerose società che sviluppano applicazioni e tecnologie basate su un linguaggio come l’HTML: il loro nemico più grande è il codice non valido. Basti pensare a come sarebbe molto più semplice lavorare sempre su pagine validate, prive di errori e warning, anche semplicemente durante lo sviluppo di un sito web. Se però iniziano ad essere presenti errori e codici non standard, ecco che una gran parte del tempo verrà impiegato per correggere questi problemi. Se si parla poi di progetti come la creazione di un nuovo motore di rendering o di un browser, il tempo perso in questa direzione sarà ancora maggiore.

A questo proposito è illuminante un post di Rebuilding the Web riguardo al linguaggio HTML ed all’importanza della sua validità. L’autore dell’articolo racconta la sua esperienza in una piccola azienda che progettava la realizzazione di un browser standard-compliant: era impossibile pensare di gestire tutte le eccezioni generate dal codice non valido con un piccolo team di lavoro. Per questo i motori di rendering sul mercato restano sempre gli stessi, a meno che qualche soggetto importante non decida di investire, potendoselo permettere. Anche Apple e Google hanno deciso di puntare su Webkit (open-source) per Safari e Chrome piuttosto che realizzare un proprio rendering engine: la spesa sarebbe stata troppo elevata.

Meno del 10% del web ha codice valido

La colpa di tutto questo è proprio da ricercare nella diffusione del codice HTML non valido: se l’intero web non avesse errori non ci sarebbero problemi, ma è chiaro che questa rimarrà un’utopia. In passato ci sono state anche delle discussioni sul comportamento dei browser: c’era chi proponeva di visualizzare solo le pagine con codice valido, ma questo significherebbe impedire l’accesso a più del 90% dei siti web.

I dati che si trovano sulla rete sono impressionanti:

una ricerca del 2001 di Dagfinn Parnas, analizzando i siti indicizzati su dmoz.org, ha rivelato che solo lo 0.71% aveva codice HTML valido.
nel 2006 Rene Saarsoo ha ripetuto lo studio, ed i siti validi erano diventati il 2.58%.
un progetto di ricerca di Opera del 2008, chiamato MAMA, ha analizzato 3 milioni e mezzo di pagine e quelle valide erano il 4.13%.

Fortunatamente la tendenza è in aumento, ma i numeri restano ridicoli ed per ora ben poco influenti.

L’utopia di un web migliore

Con un quadro di questo genere, è facile comprendere come le conseguenze del codice HTML non valido riguardino tutti. Se utilizzate un qualsiasi browser, o a maggior ragione uno screen reader, un editor WYSIWYG o un motore di ricerca state pagando la presenza di milioni di pagine web errate. Enormi risorse continuano ad essere investite per gestire gli errori contenuti in queste pagine, ed in futuro lo scenario non sarà molto diverso.

Non esiste una soluzione immediata al problema, ma se una pagina web può essere validata senza grande sforzo, perchè non impegnarsi a raggiungere questo obiettivo? Anche questi sono costi di sviluppo da considerare, ma esistono anche dei vantaggi: una pagina valida non ha problemi ad essere visualizzata in tutti i browser e viene indicizzata senza problemi dai motori di ricerca.

Nel vostro prossimo progetto pensate seriamente alla validità del codice HTML, con un minimo di attenzione in più darete il vostro contributo per un web migliore.

[foto: Heberger Site]

Classi HTML: buone pratiche ed errori comuni

Google pubblica l’analisi di un miliardo di pagine web: le classi HTML più usate mostrano dati interessanti ed errori da evitare.

Esistono numerosi studi sulle pratiche più diffuse nel web design, ma spesso queste analisi vengono effettuate su un campione ristretto, non attendibile. Google ha pubblicato uno studio che fa luce su alcuni aspetti: pur non essendo troppo approfondito, può contare su un campione di più di un miliardo di pagine web. Abbastanza per fermarsi ad osservare i dati provando a trarne qualche conclusione.

Tra gli argomenti dello studio voglio considerare soprattutto le classi HTML, per capire anche quante speranze esistano di avvicinarsi alla nascita di un web semantico.

I risultati dello studio di Google sulle classi HTML

Prima di tutto, è necessario analizzare un aspetto: la maggior parte delle pagine web non utilizza alcuna classe. E’ un dato che potrebbe sorprendere, ma ricordate che stiamo parlando di una rete dove regnano ancora incontrastate le pagine con codice non valido, generate da software inefficaci, dove le tabelle vengono usate ancora per il layout.

La classifica delle classi più utilizzate è la seguente:

footer
menu
title
small
text
content
header
nav
copyright
button
main
search
msonormal
date
smalltext
body
style1
top
white
link

Alcune sono comuni, come header e footer, l’utilizzo di altre invece è totalmente errato.

Gli errori più comuni

Tra le classi di questa top 20, sono senza dubbio da evitare tutte quelle con un nome senza significato come msonormal o style1. Tra l’altro MsoNormal è una classe generata da Office esportando un documento come pagina web. Il fatto che sia presente tra le più utilizzate è indicativo della qualità media della rete e di come vengano realizzati molti siti: che sia un problema irrisolvibile?

Sono poi usate in maniera sbagliata le classi con un nome collegato all’aspetto presentazionale, come white.

Una guida da seguire

Se avete dubbi su come scrivere il codice HTML, utilizzando ID e classi nel modo corretto, trovate alcune indicazioni utili in un articolo che ho pubblicato qualche mese fa: “Guida all’utilizzo di ID e classi nel codice HTML”. L’argomento è sempre valido, per questo ci tengo a segnalarlo.

Il codice dovrebbe essere scritto sempre in maniera comprensibile, trovando il giusto equilibrio tra sintesi e leggibilità, senza dimenticare di usare nomi legati alla funzione di un elemento e non al suo aspetto.

Nel caso aveste delle aggiunte da segnalare o qualche suggerimento da farmi, lasciateli come sempre nei commenti e provvederò ad integrare la guida: il vostro contributo è sempre prezioso.

Il W3C abbandona XHTML, il futuro è HTML 5

La presa di posizione del W3C: stop allo sviluppo di XHTML 2 per portare avanti solo HTML 5.

Il W3C ha chiarito la sua posizione sul futuro della specifica XHTML: con una news pubblicata il 3 Luglio ha chiuso lo sviluppo di XHTML 2, per dedicare tutte le risorse al futuro HTML 5.

Dalle notizie della settimana appena conclusa infatti è possibile leggere:

2009-07-02: Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the Working Group, W3C hopes to accelerate the progress of HTML 5 and clarify W3C’s position regarding the future of HTML.

Una decisione sicuramente importante per il futuro di chi sviluppa sul web, ma non così sorprendente come potrebbe sembrare. Ammetto di avere sperato in XHTML 2, ma i segnali colti fino ad ora non sono mai stati rassicuranti. Quest’ultima notizia è solo la conferma della strada fortemente voluta e consigliata (in modo più o meno forzato) da Google e dai vari sviluppatori di browser, che da tempo stanno spingendo per la specifica HTML 5.

Alla luce di quanto accaduto la decisione di Dave Shea, sviluppatore americano, che ha deciso di abbandonare XHTML da qualche tempo, non appare così sbagliata. Ne avevo parlato nel post “Abbandonare XHTML?”, ma in ogni caso non c’è alcun motivo di avere fretta di cambiare. Per quanto mi riguarda resto fermo sulla mia posizione: finchè HTML 5 non sarà pienamente supportato, XHTML 1.0 resterà la mia scelta principale; è semplicemente arrivato il momento di approfondire lo studio della nuova specifica per chi non l’avesse ancora presa in considerazione, visto che tra qualche tempo sarà largamente diffusa.

Come punto di partenza vi segnalo le Faq del W3C sul futuro di XHTML, ed il post “HTML 5: approfondimenti ed evoluzioni future”, dove troverete diversi link utili.

A proposito di tempi: quanto ci vorrà per vedere HTML 5 supportato da tutti i principali browser? Sicuramente qualche anno, ma la data potrebbe non essere così lontana. In alcuni casi certe funzionalità sono già ben supportate, e questo indica che gli stessi produttori hanno interesse a seguire la specifica. Non sarà comunque un cambiamento improvviso: c’è tutto il tempo per documentarsi ed approfondire.

Abbandonare XHTML?

E’ logico abbandonare XHTML in attesa di HTML 5? Un approfondimento sulle recenti discussioni in rete.

Tutto è iniziato con un post di Dave Shea su Mezzoblue, che sollevando non poco stupore ha dichiarato:

Back to HTML 4.01 Strict for now, then HTML5 whenever that happens.

Un salto indietro di svariati anni, per tornare a realizzare pagine in semplice HTML, abbandonando una specifica ben più rigorosa come l’XHTML.

Questo cambiamento è da interpretare in proiezione futura, per via del supporto di alcuni browser (Opera soprattutto) e dell’attuale stato delle specifiche. Non è un mistero che XHTML 2 sia ancora indietro, mentre con HTML 5 sia già possibile ottenere dei risultati: ne avevo parlato anche in un articolo sui form.

La discussione per quanto riguarda l’Italia è proseguita su Edit, dove nei commenti del post Bye Bye XHTML si scontrano le due posizioni. Chi difende il web semantico e XHTML ha le sue ragioni, ma non è così incomprensibile appoggiare la semplicità di HTML 5.

E’ veramente ora di abbandonare XHTML?

La risposta a questa domanda va in controtendenza con quanto affermato da Dave Shea.

La specifica XHTML infatti è attualmente la scelta migliore.

Che senso avrebbe tornare a HTML 4? Dal mio punto di vista sarebbe un passo indietro, non giustificabile guardando al futuro. E’ lecito prepararsi a HTML 5, diversi siti lo stanno già facendo, ma il suo supporto è appena agli inizi: qualsiasi cambiamento è ancora prematuro. Ovviamente è un’opinione personale, se la pensate diversamente mi farebbe piacere discuterne nei commenti.

I form con HTML 5: novità importanti

Una panoramica sulle possibilità di controllo dei form offerte dalla nuova specifica HTML.

Dopo aver affrontato una prima volta l’argomento HTML 5 su questo sito, nelle ultime settimane ho sperimentato diverse soluzioni interessanti di questa nuova specifica.

Il linguaggio è stato semplificato e reso molto più immediato, ma ci sono diversi elementi come i form che hanno subito una rivoluzione. Per capire di cosa sto parlando vi basterà installare l’ultima versione di Opera, che supporta le novità di HTML 5 e vi permetterà di fare alcune prove.

Per far sì che una pagina segua la specifica, è sufficiente usare questa doctype:

<!DOCTIPE html>

Come vedete, è tutto molto più immediato rispetto alle dichiarazioni in uso attualmente.

Utilizzando i form vi renderete conto che le novità sono ancora più interessanti. Sono supportati infatti una serie di attributi e valori per gestire i campi obbligatori, la validazione dei moduli ed i diversi tipi di elementi.

Ad esempio type=”email” su un campo impedisce l’invio del form se il dato inserito non è un formato email valido. La stessa cosa vale per gli indirizzi web con type=”url”. Il tutto è interamente gestito dal browser, senza bisogno di script aggiuntivi.

Usando invece type=”date” su un campo input, al click appare un box per la selezione della data come quello che potete vedere qui sotto. Niente JavaScript e altri elementi nella pagina, basta un attributo.

Selezione della data su un form in HTML5

Per i campi obbligatori invece basta specificare required all’interno dell’elemento richiesto. Così un campo email potrà essere definito:

<input name="email" type="email" required>

Potete vedere alcuni esempi e sperimentare le potenzialità dei form in HTML 5 in questa pagina, ricordando di utilizzare l’ultima versione di Opera. Gli altri browser si comporteranno senza errori, ma vedrete dei semplici campi input. Per quanto riguarda invece la selezione della data, Bruce Lawson ha realizzato un semplice esempio, correlato ad un articolo molto interessante su HTML 5 e WAI-ARIA.

Questa nuova specifica HTML non sarà largamente supportata entro breve, ma è tempo di iniziare a conoscerla. Potrebbe diventare una realtà prima del previsto senza bisogno di attendere molti anni: tra gli obiettivi c’è anche quello della retrocompatibilità, e questo gioca a suo favore.

HTML5: approfondimenti ed evoluzioni future

Una raccolta di materiale sulla specifica HTML 5, tra problemi di compatibilità presenti ed evoluzioni future.

Sono passati due anni e mezzo dalla pubblicazione dell’ultima bozza sulle specifiche XHTML 2.0 E’ passato più di un anno dalle discussioni su quale dovessere essere la direzione da seguire: XHTML 2.0 o HTML 5?

In questo contesto, sembra che negli ultimi tempi la questione abbia subito una decisa accelerata: si parla sempre più insistentemente di HTML 5 e molto probabilmente il 2009 sarà l’anno della sua affermazione.

Approfondimenti sulla specifica HTML 5

Per chi volesse saperne di più e scoprirne le basi è disponibile una Working Draft che illustra numerosi dettagli, i nuovi elementi a disposizione degli sviluppatori e l’utilizzo che ne dovrebbe essere fatto.

Inoltre proprio in questi giorni è stato pubblicato anche su A List Apart l’articolo Semantics in HTML 5 che affronta diversi argomenti, a partire dalla retrocompatibilità. Come era immaginabile, il problema principale è il mancato supporto di browser come Internet Explorer (6 e 7), mentre gli altri principali concorrenti si comportano egregiamente già adesso.

Parlando invece di nuove funzionalità, sul sempre eccellente Dev Opera è disponibile un articolo che illustra il funzionamento dei canvas, che permettono di creare della grafica direttamente in JavaScript.

In questo contesto, ci sono già stati i primi esperimenti:

il sito di An Event Apart, realizzato utilizzando (in parte) HTML 5
una pagina di test che comprende elementi come <header>, <nav> e <footer>, resa funzionante anche su IE grazie a JavaScript

Come è possibile vedere su quest’ultimo esempio, l’unico modo per rendere la specifica compatibile anche sul browser Microsoft è l’utilizzo di JavaScript: attenzione quindi perchè potrebbero esserci problemi per alcuni visitatori. Il modo più veloce per implementare questa soluzione è includere nella pagina questo script, tenendo presente i problemi di accessibilità.

Evoluzioni future

Allo stato attuale, è ancora prematuro parlare di HTML 5 su larga scala, soprattutto per i problemi di compatibilità citati. Dai numerosi interventi che sono stati pubblicati in questo inizio 2009 è comunque facile immaginare che sarà un anno importante per lo sviluppo della specifica.

Tenete presente però che lo stato di Proposed Recommendation è ancora lontano: qualcuno ha parlato addirittura del 2022. E’ sempre utile rimanere aggiornati sull’evoluzione degli standard web, ma le priorità attuali per un web designer sono ben altre.

La mia personale speranza è che ci sia la possibilità di continuare a vedere evolversi anche l’XHTML, ma non so quanto sarà possibile. E’ vero che anche adesso coesistono senza troppi problemi le due soluzioni, ma visto che lo stesso W3C ha voluto seguire con più convinzione una strada, non mi stupirei se questa restasse l’unica.

Guida WordPress 2.7: come personalizzare i post

Con la nuova versione di Wordpress è possibile personalizzare i post con facilità: ecco come modificare il codice del proprio template.

La versione 2.7 di WordPress è arrivata: la nuova interfaccia di amministrazione fa parlare di sè, ma ci sono altri cambiamenti che possono aiutare gli sviluppatori a personalizzare i temi, senza più bisogno di hack e plugin esterni.

Una delle novità più interessanti riguarda la personalizzazione dei post. Adesso infatti è presente una nuova funzione chiamata post_class() che assegna automaticamente a tutti i post contenuti nel loop alcune classi HTML. Queste classi possono essere utilizzate nel CSS, per modificare l’aspetto delle pagine e degli articoli.

La funzione post_class()

Per sfruttare la nuova funzione è sufficiente individuare nel template il blocco di codice HTML relativo ad ogni post, che si apre con:

<div class="post" id="post-<?php the_ID(); ?>">

A questo punto sostituitelo con:

<div <?php post_class(); ?> id="post-<?php the_ID(); ?>">

La nuova funzione genera automaticamente la classe post e ne crea di nuove, contenenti tra l’altro informazioni su categorie e tag. Se avete bisogno di aggiungere una classe a quelle di WordPress, vi basta specificarla con la funzione:

<?php post_class('nome-classe'); ?>

o se avete bisogno di più classi:

<?php post_class('classe1 classe2 altra-classe'); ?>

Infine se volete utilizzare la funzione all’esterno del loop o nelle pagine dei singoli post, potete farlo passando come secondo parametro l’ID del post:

<?php post_class('', $post_id); ?>

Come risultato finale avrete numerose classi a disposizione con cui personalizzare i vostri temi. Questo è l’elenco nel dettaglio:

.post: classe generica, applicata a tutti gli articoli
.sticky: classe assegnata ai post in evidenza, che con WordPress 2.7 possono essere visualizzati prima di tutti gli altri
.hentry: classe usata nei microformats
.category-nomecategoria: classe che indica la categoria di appartenenza del post, può essere più di una
.tag-nometag: classe che indica il tag di appartenenza del post, può essere più di una

Potete già immaginare le possibilità offerte da questa nuova funzione di WordPress 2.7. Niente che prima non si potesse fare con qualche hack, ma adesso è tutto pronto all’uso e collaudato, all’interno della piattaforma. Ora creare un post in evidenza con un aspetto diverso dagli altri è semplice, così come assegnare un’icona o uno sfondo differente ad ogni articolo, a seconda della categoria.

Nel prossimo post dedicato alla nuova versione di WordPress descriverò come personalizzare i commenti.

Layout a tabelle con i CSS

Con Internet Explorer 8 sarà possibile usare la proprietà CSS display:table. Cambierà qualcosa per i web designer?

Dopo aver abbandonato l’uso delle tabelle per il layout, in questo periodo si sta tornando a parlare del loro utilizzo in forma diversa: non più all’interno del codice HTML, ma con la proprietà display dei CSS.

Come fa notare Digital Web Magazine, con l’imminente uscita di Internet Explorer 8 questa proprietà supporterà correttamente i valori table, table-row e table-cell per la prima volta su un browser Microsoft. Le ultime versioni di Safari, Opera e Firefox seguono già gli standard e non dovrebbero avere alcun problema.

Come funziona la tecnica?

Basta realizzare una semplice struttura nel codice HTML con dei div:

<div id="main"> <div id="nav"> ...contenuto della colonna </div> <div id="content"> ...contenuto della pagina </div> </div>

Quindi è sufficiente applicare gli stili relativi, facendo in modo che il contenitore principale abbia un display: table, e le singole colonne un display: table-cell:

#main { display: table; border-collapse: collapse; } #nav { display: table-cell; width: 180px; } #content { display: table-cell; width: 580px; }

Da notare che una tecnica simile dal punto di vista della semantica del codice non presenta alcuna controindicazione. L’aspetto tabellare infatti viene gestito interamente tramite i fogli di stile, il markup è ben organizzato e non ha particolari differenze rispetto a quello di un layout con i float.

Incompatibilità e difetti

Per ogni nuova tecnica è fondamentale considerare quanto essa sia realmente applicabile. Nel caso dei layout a tabelle con i CSS, uno dei punti deboli è sicuramente il mancato supporto di IE6 e IE7. Non poter usare questa soluzione sui due browser che da soli rappresentano più del 70% del mercato, la rende di fatto inutilizzabile: al momento è poco più che esercizio di stile.

Un altro aspetto poco considerato è l’ordine dei contenuti all’interno del codice HTML. Con questa tecnica si ripresenta uno dei difetti principali delle tabelle: l’impossibilità di organizzarli secondo la loro importanza. Usando un layout tabellare tutti i vantaggi del posizionamento con i float spariscono, dovendo per forza di cose ordinare gli elementi secondo il loro ordine di apparizione nella pagina.

Se volete continuare ad approfondire il discorso, vi rimando ad un post di Edit di qualche settimana fa. Dal mio punto di vista, potrebbe essere interessante sperimentare la tecnica per il futuro, ma con qualche riserva. Sarà infatti possibile usarla quando IE6 e IE7 spariranno dalla circolazione, ma i CSS3 saranno ormai alle porte con nuove soluzioni per gestire il layout di un sito.

Guida all’utilizzo di ID e classi nel codice HTML

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.