Libertà! Uguaglianza! Validità!

Come una nazione o una casa, una pagina che presenta dei "dissidi interni" non sta in piedi-- perlomeno non in browser attinenti agli standard. Ogni pagina ha una struttura, il che significa che usando i metodi di costruzione con disattenzione si otterrà una struttura debole, imperfetta, e potenzialmente pericolosa. Se si ha mai provato a caricare una pagina in Opera o Netscape 6 o Internet Explorer e questa è stata visualizzata in modo pessimo, significa che è stata costruita inavvertitamente una struttura traballante.

Si immagini di costruire una casa su fondamenta di sabbia, oppure usando travi di gomma. La stragrande maggioranza delle persone non lo noterebbe neppure, mentre altri non sarebbero sorpresi di vedere enormi crepe sui muri, pavimenti non in piano, o addirittura il collasso della struttura stessa. Ancora oggi molti autori di pagine Web restano shockati nello scoprire che le proprie pagine cadono a pezzi sui browser moderni. La reazione più comune è dire che "la pagina era a posto fino a poco fa!", il che equivale a dire "la mia casa con colonne di gomma non si è sbriciolata lo stesso giorno che l'ho costruita!" Forse no, ma c'è sempre il pericolo che cada.

Quindi, come ci si può assicurare di avere una buona, solida casa nel Web? Usando codice ben strutturato. Una struttura pulita per un documento è essenziale per assicurarsi che funzioni nei browser presenti e futuri. Fortunatamente, correggere la struttura di una pagina dopo la sua realizzazione è molto più facile e meno costoso che correggere le pecche strutturali di una casa! Infatti, esistono validatori HTML che possono aiutare ad identificare il problema e correggerlo velocemente. Raccomandiamo caldamente il Validatore HTML del World Wide Web Consortium-- non solo perché fornito dalle stesse persone responsabili delle specifiche HTML e XHTML, ma anche perché per molti degli errori viene fornito un link ad una spiegazione del loro significato. In alcuni casi, ovviamente, è possibile riconoscere il significato dei messaggi di errore senza ricorrere alla spiegazione, ma se si è alle prime armi questi file di aiuto sono di inestimabile valore.

L'obiettivo è semplice: portare la propria pagina ad uno stato in cui non vengono generati errori di sorrta. Come punti bonus, si potrebbe provare ad eliminare anche ogno avvertimento, ma è anzitutto importante evitare di avere errori. In pratica, esistono due tipi di errori:

• Avvertimenti sugli elementi, che sono i più critici e possono realmente rovinare una pagina se lasciati non corretti. Ad esempio, un errore come "element 'TD' not allowed here", il quale significa che si ha un elemento TD fuori da una tabella, o così almeno pensa il validatore. Entrambi i motivi rappresentano comunque un problema rilevante, per cui capire il perché accade dovrebbe essere un problema prioritario. Un element error (errore di elemento) è equivalente ad un fornitore che vi dice di aver lasciato alcune travi di sostegno fondamentali fuori dalla vostra casa.

• Avvertimenti sugli attributi, i quali sono meno importanti considerato che molti browser ignoreranno ogni attributo che non riescono a comprendere. Questo non significa che gli attribute error (errori di attributo) possono esssere ignorati, ma che generalmente richiedono meno attenzione di quella data agli errori di elemento.

Man mano che il codice viene ripulito rimuovendo errori, si può notare che ne vengono generati altri-- o che improvvisamente molti di questi spariscano. Ad esempio, se si aggiunge un tag di fine tabella mancante (</table>) ad un documento, si potrebbero aver risolto tutti gli errori "element not allowed here" (elemento non valido in questa posizione) che lo seguono. In ogni caso, l'obiettivo di ogni autore è di non avere alcun errore di nessun tipo.

Validazione e DOCTYPE

Quando si valida un documento, si ha la possibilità di scegliere quale Document Type Definition (DTD) si voglia usare come standard. Ci sono molte opzioni disponibili, da HTML 2.0 fino ai più recenti standard (mentre scriviamo l'ultimo è XHTML 1.1). Se si vuole che le proprie pagine funzioni nei browser odierni, la milgiore scelta è un DTD recente. Data la natura di generale retrocompatibilità di HTML e XHTML, la validazione con un DTD recente dovrebbe significare che sarebbe tutto a posto anche con vecchi browser.

Piuttosto che prendere un DTD dalla lista fornita, è possibile anche inserire un elemento DOCTYPE in testa al proprio documento document, indicando quindi che si sta utilizzando uno specifico DTD. Diciamo che vogliate usare il DTD di HTML 4.01 Strict. In questo caso, la prima riga del proprio documento (inserita anche prima del tag <html>) dovrebbe essere:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"https://www.w3.org/TR/html4/strict.dtd">

Una volta aggiunto questo elemento in testa al documento, si può usare l'opzione Document Type "(specified inline)" ed il validatore W3C userà il DTD dichiarato per validare il codice.

I browser più recenti (Firefox 2, Internet Explorer 7, Seamonkey 1, Camino 1, Opera 9, Galeon 2) fanno uso dell'elemento DOCTYPE per determinare il modo d visualizzazione (o modo di rendering) che si vuole che il browser usi per mostrare il proprio documento. Parlando in generale, ogni DTD "transitional" o "loose" o anche la mancanza di un DOCTYPE, farà scegliere al browser di usare un modo di visualizzazione che emula il comportamento di programmi più datati. I DTD "Strict" invece, faranno sceglie al browser un modo di visualizzazione aderente agli standard. Questo è un modo molto semplice per gli sviluppatori per decidere come si vuole che i browser gestiscano il proprio codice. Il sito Apple Developer Connection ha un articolo chiamato "DOCTYPE Explained" (DOCTYPE spiegato) che copre questa discussione in modo più dettagliato; notare che anche Internet Explorer 6 per Windows supporta "DOCTYPE switching" (cambio di DOCTYPE)) descritto in questo articolo.

Problemi comuni

Ci sono alcuni errori che gli autori vedranno molte, molte volte durante man mano che le loro pagine vengono vaildate. Ci sono inoltre alcuni particolari che un validatore non riesce ad inviduare (il software è perfetto quanto le persone che lo hanno scritto). Ecco alcuni degli errori e traboccehtti più comuni da evitare.

Dimenticare attributi importanti

Se si incappa in un errore relativo ad un attributo, è probabile che sia stato omesso un attributo richiesto. Questo include:

• l'attributo type per gli elementi script e style
• l'attributo alt per gli elementi img e area
• l'attributo summary per l'elemento table

Gli ultimi due attributi sono importanti per ragioni di accessibilità, dato che la loro inclusione è di supporto per gli utenti che usano browser solo testo o solo audio. Il primo attributo invece, type, è critico per la compatibilità all'indietro. Ad esempio, molti browser (incluso Netscape 6), ignoreranno ogni elemento STYLE che non hanno l'attributo type il quale ha l'effetto non voluto di disabilitare l'intero foglio di stile.

Una situazione simile si per il DOCTYPE strict per HTML e XHTML che non permette l'attributo language, quindi type è l'unico modo per per specificare il tipo di script usato. Cioè, se si ha uno script che inizia con:

<script language="Javascript">

Il validatore molto probabilmente lancerà un errore. Si può risolvere questo problema modificando l'elemento da leggere:

<script type="text/javascript">

Problemi con script

Accanto ai potenziali problemi causati dalll'attributo language, esistono altri modi con i quali gli script possono causare problemi nella validazione dell'HTML.

Se lo script contiene alcuni tag HTML all'interno di stringhe, ci si deve assicurare di aver usato correttamente la sequenza di escape per il simbolo slash. Ad esempio, si deve scrivere var docEle = "<html><\/html>" (notare il carattere in grassetto) per prevenire problemi di validazione. Questa è in ogni caso una buona pratica.

Si può inoltre racchiudere il contenuto dei propri SCRIPT elementi un un comment. Questo è di solito fatto per sia per gli elementi di script che per quelli STYLE, in modo da non avere problemi. Il modo usuale per fare ciò è simile a quello qui mostrato:

<script type="text/javascript"><!--
   (...script goes here...)
//--></script>

Notare il commento a singola riga di JavaScript (//) nella linea finale il quale si rende necessario per assicurarsi che il motore JavaScript del browser ignori la stringa -->.

Elementi annidati in maniera impropria

Nel corso degli anni, gli autori del Web hanno sviluppato un certo numero di trucchi per ottenere gli effetti da loro voluti e nasconderne altri. Sfortunatamente, molti di qyesti si basano su codice interamente non valido e causano la generazione di errori da parte del validatore. Inoltre tali trucchi portano con sé problemi di visualizzazione e di funzionamento nei browser che si attengono agli standard come Firefox 2 o Internet Explorer 6+ (nella modalità di visualizzazione strict), per questo devono essere comunque risolti o eliminati.

Un esempio molto comune è l'uso di un elemento FONT per racchiudere uno o più paragrafi, tabelle, o altri elementi di block-level (di livello blocco, inteso come contenitore). FONT è però un elemento inline, per cui non può contenere elementi block-level. Per cui il codice seguente è strutturalmente incorretto:

<font color="red">
<p>Hey, paragraphs can't be inside font elements!</p>
</font>

La stessa situazione si ha usando un elemento FONT per racchiudere una tabella. Se si deve colorare tutto il testo di una tabella, dovendo usare necessariamente FONT a questo scopo, allora deve essere incluso un elemento font in ogni cella della tabella. Ovviamente, i CSS semplificano di molto l'operazione:

<table style="color: red;">

Allo stesso modo, molti autori preferiscono evitare lo "spazio bianco" che l'elemento FORM introduce nelle celle di una tabella, utilizzando qualcosa di simile:

<table>
<form action="script.cgi" method="get">
<tr><td>(...form widgets here...)</td></tr>
</form>
</table>

codice come questo causerà un errore poiché non è possibile inserire FORM dentro alla tabella ma fuori da una cella. L'elemento form deve includere tutta la tabella (quindi essere posizionato al suo esterno), oppure inserito in una cella usando poi i CSS per impostare i margini a zero-- anche se in questo acso l'intero modulo dovrebbe essere posizionato nella singola cella. Se si sta usando una tabella per organizzare il modulo, allora from deve racchiuderla interamente, oppure includere una intera sezione del documento se questo non è possibile.

Maiuscole/minuscole errate per i valori di Class e ID

Malgrado HTML sia storicamente case-insensitive, i valori di attributi nei moderni in HTML ed XHTML (ed allo stesso modo XML) distinguono tra maiuscole e minuscole. Questo vale anche per i nomi di identificatori class e ID. Questo significa che ExternalLink non equivale a externalLINK e nemmeno a externallink. I browser attinenti agli standard come Netscape 6 osservano questo tipo di distinzione nei nomi di ID e classi. Comunque, i validatori non effettuano questo tipo di controlli tra varie istanze dello stesso valore, in un documento come in uno script o foglio di stile ad esso associato, così come non vengono individuate inconsistenze che potrebbero portare ad errori nella visualizzazione della pagina. Per maggiori informazioni su questo punto, vedere la nota tecnica "Case Sensitivity in class and id Names."

Commenti non adeguatamente formattati

Anche se potrebbe sembrare una pignoleria, è importante assicurarsi di aver formattato i commenti HTML in maniera corretta. La forma corretta di un commento HTML è

<!-- comment -->

Sonopresenti due tratteggi alla fine, non tre come alcuni autori sembrano compiacersi ad usare. In generale, si dovrebbe evitare ogni sequenza di tratteggi all'interno di un commento, e lasciare alle coppie di inizio e fine il compito di aiutare ad evidenziare il commento. (Vedere HTML 4.01, sezione 3.2.4 per maggiori informazioni.)

Ampersand

Dato che il carattere di ampersand (&) è riservata per le entità di caratteri, gli autori non dovrebbero mai utilizzarlo nel loro codice da solo -- e questo include gli ampersand all'interno di URL! Cioé, ogni URL che richiede un ampersand dovrebbe essere scritto in questo modo:

https://www.site.web/path/doc.html?var1=val1&var2=val2&var3=val3

Ogni istanza di & viene tradotta dal browser in un ampersand, senza provocare errori di validazione.

Presenza del valore di attributo e uso dei doppi apici

Se si sta effettuando una validazione utilizzando un DOCTYPE XHTML, ogni attributo deve avere un valore, racchiuso tra doppi apici. Inoltre ogni elemento aperto deve essere chiuso, quindi nel caso in cui non esistano tag di chiusura, il termine dell'elemento deve contenere un carattere di slash. Questi sono requisiti di XHTML (ed in generale di linguaggi basati su XML), per cui il validatore contrassegnerà ogni istanza in cui non vengono seguite tali regole. Un esempio di codice XHTML valido che ben si discosta dallo storico HTML:

<input type="checkbox" checked="checked" name="prefSys" value="MacOS" />

Notare l'aggiunta di un valore (tra apici) all'attributo checked e dello slash al termine del tag. Senza queste aggiunte, il frammento di codice non sarebbe cosniderato XHTML valido.

Conclusione

Anche se a prima vista può sembrare un lungo lavoro, la validazione del codice viene ripagata con un risparmio di tempo e di sforzi futuri. Non solo i propri documenti avranno più chance di essere visualizzati propriamente in tutti browser presenti e futuri, ma anche il mantenimento di propri documenti sarà molto più semplice, come pure la loro conversione da HTML ad altri linguaggi a marcatori, come ad esempio XML.

Anche se l'obiettivo ideale è quello di avere pagine che non generano alcun errore o avvertimento nella validazione, ci si deve concentrare anzitutto sull'eleiminazione degli errori effettivi. Similmente, ci si dovrebbe concentrare sugli errori degli elementi piuttosto che su quelli degli attributi, anche se nessuno dei due tipi può essere ignorato. Una volta ripulito il tutto fino a non avere errori, si può pensare all'elaborazione stilistica del documento e confidare nel fatto che la pagina sarà visualizzata più o meno da tutti i browser conosciuti, così come da ogni buon browser futuro.

Argomenti correlati in MDC

* Case Sensitivity in <code>class</code> and <code>id</code> Names

Collegamenti

• The W3C's HTML Validator
• W3C DTD List
• HTML 4.01, section 3.2.4
• Mozilla's Quirks Mode
• DOCTYPE Explained