Translations of this article are available.
Traduzione italiana di Mirko Corli e Franco Carcillo.
Questo documento spiega in che modo e perché l'uso degli standard web vi permette di creare siti facendo risparmiare tempo e denaro a chi sviluppa e fornendo un'esperienza migliore a chi li visita. Vengono discussi anche altri metodi, linee guida e pratiche di progetto che aiutano a creare siti di alta qualità, il più possibile accessibili.
Quando, nella seconda metà degli anni '90, Internet e il Web diventarono fenomeni di massa, i produttori di browser non avevano ancora implementato i CSS (fogli di stile a cascata) al punto da utilizzarli per controllare la presentazione dei contenuti di un documento HTML. La mancanza è in parte comprensibile, se pensiamo che le specifiche per i CSS 1 furono pubblicate nel 1996 e quelle per i CSS 2 nel 1998.
La mancanza di supporto dei CSS nei browser, unita alle pretese dei grafici, abituati al livello di controllo sulla pagina dato dalla stampa, ha portato ad abusare in ogni modo dell'HTML per controllare la presentazione e l'aspetto delle pagine web. Un esempio è la grande breccia aperta quando i designer scoprirono che, usando l'attributo border="0" per nascondere i bordi delle tabelle, si creava una griglia invisibile da utilizzare per controllare il layout. Un altro esempio è l'uso delle GIF trasparenti, e quindi invisibili, per controllare i layout.
Dal momento che l'HTML non fu mai inteso come strumento di controllo della presentazione di un documento, si utilizzarono trucchi, codici non validi ed elementi (tag) proprietari. La validazione era qualcosa di conosciuto e usato da pochi. Zuppa di tag è forse l'espressione che meglio descrive quel codice.
Nel momento in cui furono rilasciate nuove versioni di browser, il supporto dei CSS venne migliorato ed esteso ma non fino al punto in cui avrebbe dovuto esserlo. Nonostante la lentezza dei produttori di browser a implementare i CSS, ormai siamo a un punto in cui i browser con un supporto ragionevole dei CSS vengono usati da un numero tale di persone per cui non ha più senso non usare l'HTML nel modo in cui era stato concepito in origine: per descrivere la struttura di un documento, e non la sua presentazione. Per quest'ultimo compito, adesso, possiamo usare i CSS, che sono stati concepiti proprio per questo scopo.
Gli standard web sono tecnologie ideate e sviluppate dal W3C
e da altri organi normatori, che vengono utilizzate per creare e interpretare contenuti per il web. Queste tecnologie sono ideate per documenti pubblicati sul web in grado di resistere al tempo e accessibili al pubblico più vasto possibile.Questo documento si concentra su XHTML 1.0 Strict per la struttura dei documenti, CSS livello 1 e 2 per la presentazione, ed ECMAScript 262 per la programmazione (non che contenga molti esempi di programmazione).
Quando si dice che un documento è in linea con gli standard web, significa che a parte utilizzare le tecnologie appena nominate:
Notate che "funziona su ogni browser", non significa "ha lo stesso aspetto su ogni browser". Rendere un documento identico nell'aspetto sui vari browser è praticamente impossibile. Neanche usare soltanto immagini renderebbe un sito web identico ovunque. I documenti pubblicati sul web vengono visualizzati da un gran numero di dispositivi di navigazione, su molti sistemi operativi, con schermi di qualità e dimensioni diverse (o anche senza schermo), da utenti che potrebbero aver modificato le dimensioni base dei caratteri del loro browser e altre opzioni. Accettare tutto questo renderà la vostra vita molto meno frustrante. Chiunque crei dei siti web deve capire che ci sono dei prerequisiti tecnici da considerare, allo stesso modo in cui chi pubblica su carta o gira un film o lavora in televisione ha altri prerequisiti da considerare.
Alcuni sviluppatori e web designer hanno alcune perplessità nell'usare gli standard web. Argomenti tipici sono è troppo complicato
, funziona anche senza
e gli strumenti che uso creano codice non valido
.
è semplice reagire emotivamente e creare delle resistenze ad apprendere cose nuove e abbandonare tecniche conosciute e confortevoli. Tuttavia, guardando alle cose con un po' di logica, si vedrà che ci sono molti benefici nell'apprendere e utilizzare gli standard web. Alcuni esempi:
Gli standard web possono far risparmiare tempo e denaro a chi crea siti, e fornire un'esperienza migliore a chi li visita. In più, rappresentano il futuro. Se ancora non li usate, è questo il momento di iniziare a farlo, o rischierete di restare indietro.
Un documento del W3C su come migliorare la qualità del codice del vostro sito
La dichiarazione di intenti del Web Standards Project.
La spiegazione del Web Standards Project di cosa sono gli standard e del perché usarli è cosa buona e giusta.
Un articolo di Netscape DevEdge su come un'azienda può avere benefici economici dall'uso degli standard web.
Un articolo del Web Standards Project destinato ai responsabili del marketing, della comunicazione e dei dipartimenti IT.
La validazione è il processo che controlla che un documento aderisca alle regole formali del linguaggio utilizzato al suo interno. Potete paragonarla al controllare gli errori di battitura di un testo.
La validazione è un momento importante dello sviluppo web. Molti errori difficili da scoprire vengono alla luce durante la validazione. Un errore può andare dal banale refuso al più utilizzo di un elemento o di un attributo in modo scorretto.
Sfortunatamente, molti non validano i loro documenti. Alcuni possono non essere a conoscenza della validazione, altri la dimenticano, e poi ci sono quelli che la evitano intenzionalmente. Questa situazione può essere decisamente attribuita ai produttori di browser. Molti browser cercano di interpretare l'HTML non valido nel modo migliore possibile, cercando di indovinare le intenzioni dell'autore invece che visualizzare un messaggio di errore. Questo comportamento ha portato al markup trasandato oggi così comune. Il problema con questo tipo di markup è l'imprevedibilità dei risultati, unita al fatto che si appoggi alla gestione degli errori dei browser web.
Non vi sono ragioni per non validare i vostri HTML e CSS. Al contrario. Ci sono solo benefici.
Why we won't help you è l'eccellente spiegazione di Mark Pilgrim circa i vantaggi della validazione. L'articolo spiega anche perché validare i documenti prima di sottoporli ad altri è importante per ricevere un aiuto concreto da chi partecipa a forum e mailing list.
Molti editor HTML, come ad esempio BBEdit e Homesite, hanno strumenti di validazione integrati al loro interno. Se il vostro software di sviluppo non li ha, potete usare i servizi online del W3C:
Capire i messaggi di errore generati dai validatori può essere un po' complicato. Un errore all'inizio di un documento può causarne molti successivamente. Riparando il primo errore e rivalidando avrete di solito una forte riduzione degli errori. Alcuni comuni messaggi di errore sono spiegati in Common XHTML Validation Errors su Black Widow Web Design.
è sempre una buona idea assicurarvi che il vostro codice sia interamente valido, ma ci sono dei casi in cui alcuni errori di validazione sono difficili da evitare. L'esmepio più ovvio è inserire Flash o altri contenuti che richiedono un plugin in un documento. Potete leggere qualcosa in più sui problemi con Flash all'interno di Flash Satay: Embedding Flash While Supporting Standards, e Embedding flash without <embed>.
Parlando di standard web, qualcosa di cui si sente parlare spesso è la separazione tra struttura e presentazione. Capire la differenza tra i due può essere difficile all'inizio, specialmente se siete abituati a non pensare alla struttura semantica di un documento. Comunque, è molto importante afferrare il concetto, dal momento che controllare la presentazione attraverso i CSS è assai più semplice se struttura e presentazione sono separati.
La struttura è formata dalle parti indipensabili di un documento, più la marcatura semantica e organizzata dei contenuti del documento.
La presentazione è lo stile che date al documento. Nella maggior parte dei casi la presentazione riguarda il modo in cui un documento appare, ma può anche riguardare il come si sente - non tutti utilizzano un browser grafico.
Separate struttura e presentazione più che potete. Idealmente, dovreste avere un documento HTML che contenga la struttura e il contenuto e controllarne la presentazione interamente con i CSS.
Questa separazione non è così comune oggi sul Web. La maggior parte dei siti ha un codice che difetta sia dal punto di vista della struttura sia della semantica.
Per separare la struttura dalla presentazione dovete utilizzare i CSS invece delle tabelle per controllare l'aspetto dei documenti. Se siete abituati a utilizzare le tabelle per il layout potrebbe sembrarvi complicato e strano, ma non è così difficile come può sembrare a prima vista. Molti aiuti possono essere trovati sul Web, e i vantaggi sono talmente tanti che vale decisamente la pena di imparare il diverso modo di pensare che è richiesto.
Le slide utilizzate per la presentazione tenuta a Seybold 2003.
Un altro passo importante nella separazione di struttura e presentazione è quello di usare una marcatura semantica per strutturare il contenuto di un documento. Quando esiste un elemento XHTML con un significato strutturale idoneo per la parte di contenuto che si sta codificando, non ci sono ragioni per usare altre soluzioni. In altre parole, non usate i CSS per fare in modo che un elemento HTML assomigli ad un altro elemento HTML: ad esempio uno <span> invece di un <h1> per marcare un titolo.
Utilizzando HTML semantico, renderete le varie parti di un documento significative per ogni browser, che sia l'ultimo browser grafico su un moderno PC, un vecchio browser che non gestisce i CSS, o un browser testuale in una shell Unix.
Per marcare i titoli usate <h1>, <h2>, <h3>, <h4>, <h5> o <h6> a seconda del livello di titolazione. <h1> è il livello più alto.
<h1>Titolo del documento</h1> <h2>Sotto titolo</h2>
Usate <p> per marcare i paragrafi. Non usate <br /> per creare spazi tra i paragrafi. I margini tra i paragrafi sono gestiti dai CSS, e richiedono una corretta marcatura dei paragrafi.
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec risus. Ed rhoncus sodales metus. Donec adipiscing mollis neque. Aliquam in nulla.</p>
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec risus. Sed rhoncus sodales metus. Donec adipiscing mollis neque. Aliquam in nulla.
Una lista di cose deve essere contrassegnata come una lista. L'XHTML offre tre diversi tipi di liste: non ordinate, ordinate, e di definizioni.
Le liste non ordinate, conosciute anche come liste puntate, cominciano con <ul> e terminano con </ul>. Ogni elemento di lista è poi racchiuso in un <li>.
Le liste ordinate cominciano invece con <ol> e terminano con </ol>.
Le liste di definizioni sono leggermente diverse, e possono essere usate per marcare una lista di termini e le loro descrizioni. Cominciano con <dl> e finiscono con </dl>. Ogni termine che viene descritto è contenuto in un elemento <dt>, e la descrizione in uno o più <dd>.
<ul>
<li>Elemento 1</li>
<li>Elemento 2</li>
<li>Elemento 3</li>
</ul>
<ol>
<li>Elemento 1</li>
<li>Elemento 2</li>
<li>Elemento 3</li>
</ol>
<dl>
<dt>sito web</dt>
<dd>Un insieme di pagine collegate tra loro che rappresentano
un'azienda o una persona.</dd>
<dt>pagina web</dt>
<dd>L'unità base di informazione sul Web; contiene testo,
grafica, e altri media.</dd>
</dl>
I CSS rendono possibile utilizzare le liste anche quando non si vuole che il loro contenuto venga presentato come una lista tradizionale. Una barra di navigazione, che altro non è se non una lista di link, è un buon esempio. Il vantaggio di usare una lista per un menu è che il menu avrà un senso anche nei browser che non supportano i CSS.
L'elemento <q> dovrebbe essere usato per citazioni brevi, all'interno dei paragrafi. I browser dovrebbero visualizzare automaticamente le virgolette prima e dopo quanto contenuto nell'elemento <q>. Sfortunatamente, Internet Explorer non lo fa; in alcuni casi, inoltre, <q> può dare problemi di accessibilità. Per questo motivo alcuni sconsigliano l'uso di <q> e suggeriscono di inserire a mano i segni di citazione. Inserire le citazioni brevi in elementi <span> con una classe apposita permette di stilizzarle via CSS, ma non ha un significato semantico. Leggete l'articolo di Mark Pilgrim The Q tag per avere un'idea dettagliata dei problemi che l'elemento <q> porta con sè.
Per citazioni più lunghe (uno o più paragrafi), si dovrebbe usare l'elemento <blockquote>. I CSS possono essere usati per stilizzare le citazioni. Notate che non è permesso inserire del testo direttamente in <blockquote>: quest'ultimo deve essere all'interno di un altro elemento, di solito un <p>.
L'attributo cite può essere usato sia con <q> sia con <blockquote> per fornire una URL con la fonte della citazione. Usando <span> invece di <q>, questo attributo non può essere usato.
<p>Il W3C afferma che <q cite="http://www.w3.org/TR/REC-html40/ struct/text.html#h-9.2.1">La presentazione degli elementi della frase dipende dal programma dell'utente </q>.</p>
Il W3C afferma che La presentazione degli elementi della frase dipende dal programma dell'utente
.
<p>Il W3C afferma che <span class="quote">“La presentazione degli elementi della frase dipende dal programma dell' utente.”</span>.</p>
Il W3C afferma che "La presentazione degli elementi della frase dipende dal programma dell'utente.".
<blockquote cite="http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html">
<p>“La sezione seguente affronta il tema della strutturazione del testo.
Gli elementi che presentano il testo (allineamenti, caratteri, fogli di stile,
etc.) vengono discussi altrove in queste specifiche. Per informazioni sui
caratteri, consultate la sezione sul set di caratteri dei documenti.”</p>
</blockquote>
"La sezione seguente affronta il tema della strutturazione del testo. Gli elementi che presentano il testo (allineamenti, caratteri, fogli di stile, etc.) vengono discussi altrove in queste specifiche. Per informazioni sui caratteri, consultate la sezione sul set di caratteri dei documenti."
<em> viene usato per dare enfasi al suo contenuto, <strong> per un'enfasi maggiore. La maggiorparte dei browser web visualizzano il testo enfatizzato in corsivo, e quello fortemente enfatizzato in grassetto. Questa non è però una certezza, quindi per essere certi di come il testo enfatizzato venga visualizzato, la soluzione migliore è usare i CSS per precisare la loro presentazione. Evitate di usare l'enfasi quando quel che volete è solo un effetto visivo.
<p><em>Il testo enfatizzato</em> è visualizzato di solito in corsivo, mentre quello <>fortemente enfatizzato</strong> è di solito in grassetto.</p>
Il testo enfatizzato è visualizzato di solito in corsivo, mentre quello fortemente enfatizzato è di solito in grassetto.
Le tabelle XHTML non vanno usate a scopi di layout. Per strutturare dei dati tabellari, invece, le tabelle sono ciò che serve. Per rendere le tabelle di dati il più possibile accessibili è importante conoscere e usare i vari componenti che possono formare il markup di una tabella. Alcuni esempi sono: titoli (<th>), sommari (attributo summary), e legende (elemento <caption>).
<table class="example" summary="Questa tabella mostra la crescita annuale della
popolazione svedese tra il 1999 e il 2003.">
<caption>Crescita annuale della popolazione in Svezia, 1999-2003</caption>
<thead>
<tr>
<td> </td>
<th scope="col">1999</th>
<th scope="col">2000</th>
<th scope="col">2001</th>
<th scope="col">2002</th>
<th scope="col">2003</th>
</tr>
</thead>
<tbody>
<tr>
<th>Popolazione</th>
<td scope="row">8 861 426</td>
<td scope="row">8 882 792</td>
<td scope="row">8 909 128</td>
<td scope="row">8 940 788</td>
<td scope="row">8 975 670</td>
</tr>
<tr>
<th>Crescita</th>
<td scope="row">7 104</td>
<td scope="row">21 366</td>
<td scope="row">26 368</td>
<td scope="row">31 884</td>
<td scope="row">34 882</td>
</tr>
</tbody>
</table>
| 1999 | 2000 | 2001 | 2002 | 2003 | |
|---|---|---|---|---|---|
| Popolazione | 8 861 426 | 8 882 792 | 8 909 128 | 8 940 788 | 8 975 670 |
| Crescita | 7 104 | 21 366 | 26 368 | 31 884 | 34 882 |
Per una descrizione più dettagliata delle tabelle e del loro uso, leggete Tables in HTML documents e HTML Techniques for Web Content Accessibility Guidelines 1.0.
Una risorsa eccellente per imparare le motivazioni che spiegano come marcare qualcosa in modo semantico.
Per creare siti web moderni, ben strutturati, e rispettosi degli standard è possibile usare anche HTML 4.01. Tuttavia, per completare la transizione verso il markup pulito e semantico ed essere preparati al meglio per la possibile transizione a XML e altri futuri linguaggi, l'XHTML 1.0 Strict è la soluzione che vi raccomando. Per gli esempi di questo documento ho usato XHTML 1.0 Strict.
L'XHTML 1.0 è una riscrittura dell'HTML 4 in XML 1.0, ed è stato sviluppato per rimpiazzare l'HTML. L'XHTML 1.0 Strict - che vi raccomando di usare - non consente marcature di presentazione (non lo fa neanche l'HTML 4.01 Strict, ma l'XHTML è ciò su cui mi concentro qui): per questo, rafforza la separazione di struttura e presentazione.
L'XHTML 1.1 (l'ultima versione di XHTML) è tecnicamente un po' più complesso da usare, dal momento che le specifiche affermano che i documenti XHTML 1.1 dovrebbero avere una codifica MIME application/xhtml+xml e non dovrebbero essere servite come text/html. Usare text/html non è esplicitamente proibito, ma è comunque sconsigliato. D'altra parte l'XHTML 1.0, che dovrebbe usare application/xhtml+xml può anche usare il MIME text/html se è compatibile con HTML. La nota del W3C XHTML Media Types contiene un riepilogo delle codifiche MIME raccomandate.
Sfortunatamente alcuni browser datati e Internet Explorer non riconoscono il MIME application/xhtml+xml, e finiscono quindi per visualizzare il codice sorgente, o anche rifiutare di visualizzare il documento.
Se volete usare application/xhtml+xml, dovreste lasciare al server il compito di controllare se il browser che richiede il documento può interpretare questa codifica MIME, e usarlo in questo caso; utilizzerete invece text/html per gli altri browser.
Se utilizzate PHP per lo scripting lato server, lo script di negoziazione del contenuto che segue può essere usato per servire documenti con MIME diversi a browser diversi:
<?php
if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml") ||
stristr($_SERVER["HTTP_USER_AGENT"],"W3C_Validator")) {
header("Content-Type: application/xhtml+xml; charset=iso-8859-1");
header("Vary: Accept");
echo("<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n");
}
else {
header("Content-Type: text/html; charset=iso-8859-1");
header("Vary: Accept");
}
?>
Lo script controlla se il programma utente invia un'intestazione HTTP Accept con valore "application/xhtml+xml", oppure se il programma utente è il validatore del W3C, che non invia un HTTP Accept corretto ma gestisce correttamente application/xhtml+xml. Se una delle due è la risposta ricevuta, il documento viene servito come application/xhtml+xml. A questi browser viene anche servita una dichiarazione XML. Agli altri browser, incluse tutte le versioni di Internet Explorer, il documento è servito come text/html. Non viene aggiunta nessuna dichirazione XML, dal momento che porterebbe IE/Win a non comportarsi in modo standard (Quirks mode), cosa che non vogliamo.
Dopo l'intestazione Content-Type, viene inviata un'intestazione Vary per comunicare a tutte le cache intermedie come i server proxy che il tipo di contenuto del documento varia a seconda delle capacità del software che lo richiede.
Per uno script PHP di negoziazione più avanzata, leggete Serving up XHTML with the correct MIME type. Questo script considera il q-rating (quanto bene afferma di gestire una qualsiasi codifica MIME) dei vari software utente e converte l'XHTML in HTML 4 prima di inviare il documento come text/html ai software che non gestiscono application/xhtml+xml.
Di seguito ecco uno script simile per chi usa ASP e VBScript:
<%
If InStr(Request.ServerVariables("HTTP_ACCEPT"), "application/xhtml+xml") > 0
Or InStr(Request.ServerVariables("HTTP_USER_AGENT"), "W3C_Validator") > 0 Then
Response.ContentType = "application/xhtml+xml"
Response.Write("<?xml version=""1.0"" encoding=""iso-8859-1""?>" & VBCrLf);
Else
Response.ContentType = "text/html"
End If
Response.Charset = "iso-8859-1"
%>
Notate che quando il MIME è application/xhtml+xml alcuni browser, come ad esempio Mozilla, non visualizzeranno documenti che contengono errori. Questa è una cosa positiva durante lo sviluppo, ma può portare problemi ad un sito online che viene aggiornato da persone non esperte di XHTML, a meno che non possiate assicurare che tutto il codice pubblicato sia valido. Se questo è il caso, considerate l'uso alternativo di HTML 4.01 Strict.
Ecco qui una lista dei punti più importanti da considerare quando si usa XHTML 1.0 Strict invece dell' HTML:
Usate sempre caratteri minuscoli e inserite sempre i valori degli attributi tra virgolette: Tutti i nomi degli elementi e degli attributi devono essere minuscoli. Tutti i valori degli attributi devono essere compresi tra virgolette.
Non valido: <A HREF="index.html" CLASS=internal>
Corretto: <a href="index.html" class="internal">
Chiudete tutti gli elementi: In HTML alcuni elementi non devono essere chiusi per forza, vengono chiusi automaticamente quando l'elemento successivo viene aperto. L' XHTML invece non lo consente: tutti gli elementi devono essere chiusi, anche quelli che non hanno un tag di chiusura come <img>.
Non valido: <li>Item 1
Corretto:
<li>Item 1</li>
Non valido: <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Corretto: <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
Non valido: <br>
Corretto: <br />
Non valido: <img src="image.jpg" alt="">
Corretto: <img src="image.jpg" alt="" />
Gli attributi non si possono minimizzare: In HTML alcuni attributi possono essere minimizzati. L'XHTML non lo consente.
Non valido: <input type="checkbox" id="checkbox1" name="checkbox1" checked>
Corretto: <input type="checkbox" id="checkbox1" name="checkbox1" checked />
Non usate gli elementi sconsigliati: Alcuni elementi e attributi consentiti in HTML 4.01 Transitional e XHTML 1.0 Transitional sono sconsigliati in XHTML 1.0 Strict (e in HTML 4.01 Strict). Alcuni esempi sono <font>, <center>, alink, align, width, height (per alcuni elementi), e background.
Il Web Standards Project chiede al W3C se si debba usare l'HTML o XHTML, e perché.
Un articolo di A List Apart sulla transizione da HTML a XHTML.
Una buona spiegazione di come usare XHTML e CSS.
Il W3C spiega la differenza tra XHTML 1.0 e HTML 4
Un sunto delle differenze tra XHTML 1.0 Strict e Transitional
Il Web Standards Project chiede al W3C quale codifica MIME debba essere usata per l'HTML e XHTML,e perché.
Un sunto di quali tipi di media siano da usare per servire documenti XHTML.
La guida di HTML Dog agli elementi ed attributi che non vanno usati in XHTML.
Un documento sulle codifiche MIME e su come effettuare la negoziazione dei contenuti con diversi linguaggi di programmazione lato server.
Un documento del W3C su XHTML e codifiche MIME.
Al momento, davvero pochi documenti HTML hanno una doctype (Dichiarazione di Tipo di Documento) corretta e completa. Era una consuetudine più decorativa che funzionale, ma a cominciare da alcuni anni fa, la presenza di una doctype può influenzare in modo sensibile la visualizzazione di un documento in un browser web.
Tutti i documenti HTML e XHTML devono avere una doctype per essere validi. La dichiarazione afferma quale versione di HTML o XHTML viene usata nel documento, e viene utilizzata dal validatore quando valida e dai browser per decidere quale metodo di visualizzazione adottare. Se un documento contiene una doctype corretta e completa, molti browser web passeranno alla visualizzazione di tipo standard, il che significa che seguiranno le specifiche CSS in modo più rigoroso. Il documento si visualizzerà anche più velocemente, perché il browser non deve interpretare e cercare di compensare l'HTML non valido. Questo riduce anche le differenze di visualizzazione tra i vari browser.
La doctype che segue dichiara che il documento è XHTML 1.0 Strict, e farà in modo che i browser in grado di attuare il cosiddetto "doctype switching" usino la visualizzazione standard.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> Un articolo di A List Apart su come usare le doctype e perché
Un riassunto di come le diverse dichiarazioni influenzano i browser che hanno il doctype switching.
La lista ufficiale del W3C che contiene le doctype corrette.
Tutti i documenti XHTML devono specificare la loro codifica dei caratteri.
La via migliore per specificare la codifica dei caratteri è quella di configurare il web server in modo che invii un'intestazione HTTP content-type con la codifica dei caratteri. Per informazioni dettagliate su come fare questo, controllate la documentazione del web server che state usando.
Se state usando Apache, potete specificare la codifica dei caratteri aggiungendo una o più regole al vostro file .htaccess. Per esempio, se usate utf-8 come codifica, aggiungete quel che segue:
AddDefaultCharset utf-8
Per specificare una codifica per file con una certa estensione, utilizzate invece:
AddCharset utf-8 .html
Se il vostro server vi permette di eseguire script PHP, potete usare il seguente per specificare la codifica dei caratteri:
<?php
header("Content-Type: application/xhtml+xml; charset=utf-8");
?>
Per servire le vostre pagine come HTML, cambiate application/xhtml+xml in text/html. Se, per qualsiasi motivo, non potete manipolare il web server e specificare la corretta codifica dei caratteri, utilizzate i tag <meta> nella sezione <head> del documento. è una buona idea specificare i caratteri in questo modo anche quando il vostro server è configurato correttamente.
Per esempio il codice dell'elemento <meta> che segue dice al browser che il documento usa la codifica ISO-8859-1:
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
Il Web Standards Project chiede al W3C come andrebbero specificate le codifiche dei caratteri.
Un articolo sulle differenti codifiche dei caratteri.
Una spiegazione su come usare caratteri nazionali e speciali nei documenti HTML.
Un tutorial su come scegliere e dichiarare una codifica dei caratteri.
Anche se è stato principalmente utilizzato per specificare le proprietà dei caratteri, il CSS può essere usato per controllare l'intera disposizione (layout) di un documento. Tuttavia, per farlo efficentemente, è necessario un approccio sostanzialmente differente rispetto all'uso delle tabelle per il controllo della disposizione della pagina.
Per poter controllare efficentemente la disposizione di un documento, il CSS necessita di XHTML strutturato e semantico.
Come menzionato precedentemente, il supporto del CSS nei browser è stato notevolmente migliorato negli ultimi anni. Sfortunatamente, tutti i produttori di browser non sembrano interessati nell'implementare gli standard aperti, di conseguenza il livello del supporto varia da browser a browser. Soprattutto ci sono malfunzionamenti software che fanno agire i browser in modo anomalo.
Attualmente (2004), i browser che hanno la migliore resa con CSS sono:Mozilla (e altri browser basati su Gecko: Firefox, Camino, Netscape 6+), Opera e Safari (e altri browser basati su WebCore: OmniWeb 4.5 e succ.). Internet Explorer 6/Win non ha lo stesso livello di supporto del CSS, ma copre comunque gli aspetti base. Internet Explorer 5/Mac ha un ottimo supporto di CSS 1, ma non di CSS 2. IE 5.* per Windows lo supporta un po' di più, ma ha problemi che è opportuno conoscere. Le precedenti versioni di Internet Explorer non hanno supporto che valga la pena di essere menzionato. Lo stesso vale per le versioni di Netscape prima della 6.
Poichè attualmente la maggior parte degli utenti usa Internet Explorer per Windows, occorre avere questo come il punto di riferimento minimo. Ciò non vuol dire che non dobbiate o possiate usare le funzionalità dei browser con una miglior resa in CSS per migliorarne la progettazione specifica.
Non tutti i browser attualmente utilizzati hanno il livello di supporto del CSS necessario per visualizzare in modo graficamente accattivante un sito che lo utilizzi in modo completo per la disposizione delle pagine. Fortunatamente in molti siti web solo una piccola percentuale di visitatori utilizza un browser troppo vecchio per una resa appropriata dei CSS.
è importante notare che queste persone non verranno escluse dalla fruizione del sito. Negli anni 90 erano molto popolari gli script che controllando la versione del browser in uso ridirezionavano gli utenti con il browser 'sbagliato' (normalmente tutti quelli che non usavano Internet Explorer per Windows) su una pagina che chiedeva loro di aggiornare il proprio bowser per poter accedere al sito.
Oggi si possono gestire questi utenti in modo migliore. Uno dei grandi vantaggi nell'usare XHTML, in modo semantico e logico, è rappresentato dal fatto che i documenti risultano accessibili ed usabili anche senza i CSS. La presentazione - il modo in cui il documento viene visto - non sarà lo stesso come nei browser più compatibili, ma il contenuto sarà sempre disponibile. In molti casi, per la maggior parte dei visitatori di un sito, il contenuto è ben più importante del modo con cui viene presentato. Ecco perché è meglio inviare una pagina scarna e senza stile CSS che non presentarli affatto.
Ci sono più modi per farlo. Uno dei più comuni è usare @import per richiamare il file contente il foglio di stile CSS. Netscape 4 e gli altri browser più vecchi non capiranno @import e conseguentemente non caricheranno il file CSS. Ci sono un sacco di modi, poi, per nascondere ai browser il CSS. Hanno tutti in comune il fatto di basarsi su errate interpretazioni del codice CSS da parte dei browser. Ciò implica che c'è sempre il rischio che l'aggiornamento di un browser abbia la correzione all'errore che viene sfruttato per nascondere o aggirare il CSS ma non la correzione del problema che ne aveva suggerito l'uso. Dunque, meno ci si affida a questi trucchi (hacks) meglio è.
Ovviamente si può ricorrere alla tecnologia lato server per verificare il browser ed inviare opportunamente CSS differenti (o nessuno) a seconda del browser stesso. Nell'usare questo metodo occorre assicurarsi che il programma che rileva il browser sia sempre aggiornato in modo da non sbagliare ad inviare ad esempio un CSS errato ad un browser aggiornato o del tutto nuovo.
Eric Meyer descrive quattro modi per nascondere il CSS ad alcuni browser.
Ampia raccolta di tecniche per nascondere i CSS.
Un documento sui vari modi di migliorare l'esperienza dell'utilizzatore di browser moderni.
Ci sono diverse modalità di applicare CSS agli elementi di un documento HTML.
Ci sono diversi vantaggi a trattenere tutte le regole CSS in uno o più file separati. I documenti HTML sono più piccoli, i CSS sono memorizzati nella memoria cache del browser e sarà necessario scaricarli una sola volta, e a voi basterà modificare un solo file per cambiare la presentazione di un intero sito. Un CSS esterno può apparire così:
h1 {
font-weight:bold;
}
Notate: non ci sono elementi <style> in un CSS esterno.
Si può collegare un file CSS ad un documento HTML usando l'elemento <link> :
<link rel="stylesheet" type="text/css" href="styles.css" />
oppure usando la regola @import in un elemento <style> :
<style type="text/css">
@import url("styles.css");
</style>
Usando l'attrributo style, si può applicare CSS direttamente ad un elemento HTML:
<h1 style="font-weight:bold;">Rubrik</h1>
Questa modalità dovrebbe essere evitata poichè mischia la struttura con la presentazione.
Il CSS interno è contenuto in un elemento <style> che, a sua volta, si trova nell'elemento<head> :
<style type="text/css">
h1 {
font-weight:bold;
}
</style>
Anche questa modalità dovrebbe essere evitata, poichè perchè è meglio tenere HTML e CSS in file separati.
Una spiegazione, tra l'altro, dell'import CSS e dei 'media types' .
Una regola CSS consiste in un selettore e di una o più dichiarazioni. Il selettore determina a quale elemento, o elementi, HTML viene applicata la regola. Ogni dichiarazione consiste di una proprietà e di un valore. Il blocco contentente la dichiarazione è delimitato dalle parentesi graffe { }, e ogni dichiarazione termina con un ; (punto e virgola).
Una semplice regola CSS appare così:
p {
color:#0f0;
font-weight:bold;
}
In questo caso, p è il selettore, ciò significa che la regola si applicherà a tutti gli elementi <p> del documento. La regola ha due dichiarazioni, che, insieme, faranno apparire tutto il testo contenuto all'interno dell'elemento <p> in verde e grassetto.
Per una descrizione più dettagliata delle regole CSS, fare riferimento, ad esempio, a CSS Beginner's Guide, oppure a CSS from the Ground Up o ad un libro sui CSS.
Con l'aiuto dei lettori, Dave Shea ha redatto una lista di aiuti pratici nell'uso del CSS.
John Gallant e Holly Bergevin spiegano come scrivere CSS compatti.
Una buona spiegazione dei diversi selettori CSS e del loro funzionamento.
Quando si inizia con il CSS, è molto comune commettere l'errore di usare elementi XHTML non necessari, come classi superflue, o un numero eccessivo di elementi <div> . Ciò non significa necessariamente che il codice non sia valido, ma viene meno una delle ragioni per separare struttura dalla presentazione; avere un codice di marcatura semplice e pulito
Un esempio di uso di elementi XHTML superflui:
<h3><em>Headline</em></h3>
Se si vogliono le intestazioni in corsivo ad esempio, basta usare il CSS per dare un nuovo stile all'elemento <h3>:
h3 {
font-style:italic;
}
L'uso di classi superflue può apparire così:
<div id="main">
<div class="maincontent">
<p class="maincontenttext">
Lorem ipsum dolor
</p>
</div>
</div>
Mentre avrebbe lo stesso effetto:
<div id="main">
<div>
<p>
Lorem ipsum dolor
</p>
</div>
</div>
Per controllare gli elementi contenuti in div#main in CSS si possono usare i selettori contestuali. In questo caso potrebbe apparire così:
div#main p {
/* rules */
}
In molti casi i CSS possono essere usati per dare uno stile logico ad elementi XHTML logici senza aggiungere ulteriore codice di marcatura. Tuttavia ci sono casi in cui vale la pena aggiungere qualche ulteriore codice di marcatura.
Ovviamente, una volta inziato ad usare il CSS in modo serio, ci si potrà imbattere in problemi di varia natura. Alcuni di questi sono causati dalla non corretta interpretazione del codice CSS, altri da specifiche non chiare ovvero da browser che hanno ancora troppi errori nel loro codice interno. Il CSS Crib Sheet ha una raccolta di buoni consigli, curati da Dave Shea. Eccone alcuni dei più importanti, più qualcuno che non trovate in Crib Street.
Per prima cosa, validate: Prima di provare il codice, controllate sia l'HTML che il CSS con i sistemi di validazione. Molti problemi sono causati da codice non valido.
Provate prima sui browser più recenti, poi fatelo funzionare con gli altri: Se provate con un vecchio browser con una cattiva o errata interpretazione del CSS, vi troverete ad adattare il CSS a quel browser. Quando passere a provare con un browser più avanzato, è probabile che le cose non appariranno come supponevate. E' meglio lavorare dapprima con i browser più recenti, e adattare poi il codice per quelli meno capaci ad interpretare correttamente i CSS.
Capire il 'box-model' del CSS: Per ottenere l'ampiezza e l'altezza di un elemento dovete aggiungere il padding e il border alla sua width (ampiezza) o alla sua height (altezza). In Internet Explorer 5.*/Win, padding e border sono inclusi nella width o nella height fornita.
Supponete di avere il seguente codice CSS:
div.box {
width:300px;
padding:20px;
border:10px solid;
}
L'ampiezza (width) totale di questo div risulta 360px.
10px + 20px + 300px + 20px + 10px = 360px
In Internet Explorer 5.*/Win, l'ampiezza totale risulta invece di 300px, e l'ampiezza della zona riferita al solo contenuto è conseguentemente di 240px.
300px - 10px - 20px - 20px - 10px = 240px
Per aggirare questo problema, si può usare un trucco CSS che passa differenti valori a seconda del loro comportamento nel valutare il box model, oppure potere evitare di specificare sia width che padding oppure border di un elemento.
Per una esaustiva spiegazione del CSS box model, fare riferimento a Box model.
Specificate le unità di misura per i valori numerici che non siano zero: CSS richiede che le unità di misura siano specificate per le proprietà quali width, height, e font-size. Una eccezione riguarda il valore 0 (zero). In questo caso non è necessario esprime l'unità perchè zero è sempre zero, a prescindere dall'unità di misura.
Capire gli elementi galleggianti 'float': Il concetto degli elementi galleggianti può essere difficile da capire, ma è molto importante perchè è frequentemente utilizzato nelle impaginazioni con CSS. Alcuni buoni articoli sul float sono (in inglese) Containing Floats, Floatutorial, e Float: The Theory.
"LoVe/HAte": Definire pseudo classi per i link nell'ordine Link, Visited, Hover, Active.
"TRouBLed": Se si usano scorciatoie per specificare il margin, padding o border, ricordarsi di farlo in senso orario partendo dal top (sopra-destra-giù-sinistra)): Top, Right, Bottom, Left.
Denominare le classi e le ID per la loro funzione svolta, non come presentano l'elemento: Se si chiama una classe .smallblue, e poi decidete di avere il testo in grande e rosso, il nome della classe non potrà che confondere. E' meglio avere nomi che descrivono la funzione o la struttura, come .copyright o .important.
CSS è sensibile al maiuscolo/minuscolo: I valori dell'attributo HTML class e id è sensibile al maiuscolo/minuscolo quando viene usato con il CSS (vedi CSS2 syntax and basic data types).
Controllare gli ID: Solo un elemento nel documento può avere un certo valore per l'attributoid, mentre qualsiasi numero di elementi può condividere lo stesso nome di class .
Usare solo i caratteri ammessi in class e id: i nomi di Class e id possono contenere solo i caratteri [A-Za-z0-9] ae il trattino (-), e non possono iniziare con un trattino o con un numero (vedi CSS2 syntax and basic data types).
Commentare in modo corretto: Nei CSS i commenti iniziano con /* e finiscono con */:
/* This is a comment */
Ci sono molti esempi e descrizioni passo passo su come usare i CSS nelle impaginazioni. Un buon consiglio è iniziare con una impaginazione semplice, capire come funziona, e poi passare a schemi più complicati.
Un esempio di come creare una semplice impaginazione con testata, due colonne ed una base
Una raccolta di colelgamenti a vari schemi CSS.
L'accessibilità non riguarda solo l'utenza disabile, anche se è la principale ragione per rendere un sito accessibile. Un sito accessibile funziona meglio per tutti, disabili e non, e può essere utilizzato da più persone con più tipi di browser o altri apparati di navigazione
Un errore comune è credere che un sito accessibile sia meno attraente di uno non accessible. Non è così. L'accessibilità infatti non ha alcun effetto sulla presentazione.
Ecco un esempio di come l'accessibiltà può aiutare tutti: un sito web ha un modulo che può essere usato per iscriversi ad un seminario. Nel modulo si può scegliere di partecipare al seminario in una fra tre città proposte. Ogni città ha il suo nome vicino ad un 'radio button' (selettore a pallino). Se lo sviluppatore del modulo non ha in mente le tecniche di accessibilità, gli utenti con un browser grafico dovranno posizionare il cursore sul piccolo pallino e cliccarlo per indicare la città prescelta. Se lo sviluppatore conosce i temi di accessibilità e ha marcato l'eltichetta vicino ad ogni pallino con l'elemento <label> , si potrà anche cliccare sul nome della città (e non solo sul pallino) per sceglierla. Quale modo è più semplice per coloro che usano il modulo?
Usare XHTML semantico e ben strutturato vi porterà avanti verso la costruzuione di un sito accessibile. Per farsi un'idea di come un documento sia accessibile, cercate di vederlo in un browser testuale, come Lynx e verificate se il contenuto ha ancora senso. Questo è solo uno dei controlli di accessibilità che dovreste fare, ma è un buon punto di partenza.
A molti progettisti web piace usare le frame per dividere la finestra del browser in più parti indipendenti, in ognuna delle quali è presente un proprio, e separato, documento HTML. Questo potrebbe essere utile per applicazioni presenti in una intranet. Su un sito pubblico, tuttavia, ci sono molti inconvenienti nell'usare i frame:
robots.txt per informare i motori di non indicizzare le sottopagine. In altri siti, viene usato un Javascript per reindirizzare alla homepage coloro che arrivano da un motore di ricerca. Ambedue questi metodi funzionano, soprattutto se l'obbiettivo è avere pochi visitatori.
Inoltre complicate la vita a voi stessi. I siti con i frame sono tecnicamente più complessi.
E' molto comune interpretare il "non usare tabelle per impaginare" come "non usare tabelle del tutto". Non dovrebbe essere interpretato in questo modo. Se dovete incolonnare dei dati che appartengono ad una tabella, dovreste usare proprio una tabella. Tuttavia è importante sapere che, quando costruite tabelle di dati, ci sono molti modi per renderle più logiche ed accessibili. .
Collegamenti ad articoli che descrivono come realizzare tabelle accessibili.
Un articolo su come usare le tabelle per dati incolonnati.
I moduli sono spesso, inopportunamente, difficili da usare, anche perchè sono realizzati sia in modo illogico sia con un utilizzo del codice HTML omettendo quegli elementi, che esistono, per realizzare moduli più accessibili e facili da usare. Gli elementi <label>, <fieldset> e <legend> esistono e vale la pena usarli.
Una domanda comune riguarda cosa usare per impaginare un modulo. Alcuni sostengono che un modulo può essere considerato come dati tabulati, e devono essere marcati come una tabella, mentre altri sostengono che si dovrebbero usare i CSS. Potete scegliere, ma se usate una tabella, assicuratevi che il modulo abbia senso e sia usabile quando la tabella contenente il modulo viene linearizzata.
Un articolo di WebAIM sui moduli accessibili.
Un articolo sulle basi per realizzare moduli migliori e più accessibili.
Evitate di dipendere dal JavaScript. Più persone di quanto crediate, hanno il Javascript disabilitato, vuoi per ragioni di sicurezza vuoi per evitate le finestre a comparsa 'pop up'. Potrebbe inoltre usare un browser che non è progettato per usare Javascript. Secondo TheCounter.com, 6% degli utenti web non hanno JavaScript. W3Schools.com indica un 8%.
In molti casi in cui è usato JavaScript, non produce un reale beneficio per l'utente. Certamente vi sono casi in cui Javascript può essere usato per fornire una migliore esperienza di consultazione. Ad esempio quando di tratta di convalidare i dati introdotti tramite un modulo.
Notate che ciò non significa che dobbiate evitare l'uso di JavaScript. Dovreste evitare di realizzare un sito che dipende da Javascript per funzionare.
Lo stesso vale per i cookie. Non usate i cookie in modo da bloccare l'uso del sito per coloro che non gli accettano.
Questa sezione non riguarda strettamente gli standard web e l'accessibilità, ma è qui perchè il modo con cui l'URL è costruita può avere grande conseguenze su come il sito possa essere ben indicizzato dai motori di ricerca e su come l'URL sia usabile per l'utenza.
I sistemi automatici utilizzati da alcuni motori di ricerca per l'indicizzazione dei siti non seguono i collegamenti di URL che terminano con una stringa di interrogazione. Questi tipi di URL sono molto comuni nei siti dinamici che recuperano il contenuto da un archivio, e possono apparire così:
http://yourdomain.com/products.asp?item=34627393474632&id=4344
Il modo più semplice per costruire un URL che sia l'ideale, vuoi per un motore di ricerca vuoi per un utente, è di cambiarlo in modo che punti ad una cartella del sito (directory). L'esempio precedente quindisarebbe stato cambiato per apparire così:
http://yourdomain.com/products/item/34627393474632/id/4344/
Il server web interpreta quindi il nuovo URL e lo converte internamente nell'URL originale, completo della stringa di interrogazione. Al fondo di questa sezione ci sono alcuni collegamenti a siti che illustrano come realizzare questa funzionalità.
Una modo persino migliore, ma per certi versi più complicato, per cambiare l'URL è di riscrivere compeltamente la parte visibile e renderla umanamente compresibile:
http://yourdomain.com/products/flowers/tulips/
Questi i vantaggi: una migliore indicizzazione da parte dei motori di ricerca, lettura dell'URL più facile anche per l'utente, si evita inoltre di rivelare la tecnologia server utilizzata. Poichè l'URL non contiene le estensioni specifiche del server, .asp, .cf, .cgi or .jsp, sarà più facile cambiare la tecnologia utilizzata sul server, se ciò si rendesse necessario.
Se scegliete di usare le stringhe di interrogazione nell'URL, è importante codificare tutte le at commerciali (ampersands), &, nella lora entità HTML &. Se non lo fate, alcuni browser vedranno &, come dovrebbero, quale inizio di una entità HTML, e se il testo che segue corrisponde ad una entità HTML, il browser convertiràl'URL e, in molti casi, interromperà la stringa.
Vale inoltre menzionare che, per molti siti, l'utilizzo del sottodominio www non è necessario e che http://yourdomain.com/ potrebbe benissimo essere usato al posto di http://www.yourdomain.com/. Per maggiori informazioni su questo punto, consultate no-www.org. Sia che usiate il sottodominio www o meno, è comunque una buona idea configurare il server web in modo da redirigere le richieste dihttp://www.yourdomain.com/ e quelle di http://yourdomain.com/ alla stessa URI.
Un articolo che spiega i problemi di certi tipi di URL, e come rendere migliori i vostri URL.
Un articolo sul perchè sia bene terminare un URL con "/",
Un raccolta di collegamenti ad articoli e guide sui URL.
Una lunga spiegazione dei problemi con della ampersand nelle stringhe di interrogazione, con un caso di prova.
Una selezione di libri, siti web e mailing list raccomandati.
Un libro, basato su progetti concreti, che spiega come usare CSS.
Il secondo libro di Eric Meyer su CSS.
Un libro che spiega le raccomandazioni CSS.
La progettazione e lo sviluppo di siti, veri, secondo gli standard web.
Un libro completo sull'accessibilità e su come realizzare siti accessibili.
Le specifiche ufficiali del W3C.
Le specifiche ufficiali del W3C.
Una mailing list dedicata agli usi pratici e alle applicazioni di CSS.
Un sito con una grande raccolta di guide, corsi e articoli su HTML e CSS.
Un gran numero di esempi su come usare CSS per presentare lo stesso documento HTML in tanti modi completamente differenti.
Molti articoli, ben scritti, su CSS.
Articoli, dimostrazioni, errori dei browser, ed altro.
Un settimanale web con articoli che esplorano la progettazione, lo sviluppo ed il significato dei contenuti web, con una speciale attezione alle tecniche ed ai benifici della progettazione con gli standard web.
Unamailing list per coloro coinvolti nella crazione del web. Discute molti argomenti riferiti alla progettazione ed allo sviluppo web.
Le specifiche ufficiali del W3C.
Un sito con una grande raccolta di guide, corsi e articoli su HTML e CSS.
Il libro di Joe Clark sull'accessibilità, online.
Il libro di Mark Pilgrim book sull'accessibilità.
Le linee guida W3C per siti accessibili.
Raccolta di informazioni, curata dal W3C, sugli strumenti per valutare e migliorare l'accessibilità dei siti web.
"Il Web Standards Project è una coalizione che lotta affinchè gli standard consentano a tutti di accedere alle tecnologie web in modo semplice ed economico."
La missione di MACCAWS è di fornire agli autori del web le risorse necessarie per promuovere gli standard web come una scelta commercialmente desiderabile per i clienti. Due documenti che vale la pena leggere: What Every Web Site Owner Should Know About Standards: A Web Standards Primer e The Way Forward with Web Standards.
La guida di Dave Shea per colore che vogliono iniziare ad usare i web standard.
Le specifiche ufficiali del W3C.
Un sito con una grande raccolta di guide, corsi e articoli su HTML e CSS.
Una lista di riferimenti curata da Mirko Corli e Franco Carcillo
Commenti, domande o suggerimenti? Per cortesia, ditemi.
© Copyright 2004 Roger Johansson. Traduzione italiana di Mirko Corli e Franco Carcillo.