Sei sulla pagina 1di 45

Introduzione

26 gennaio 2000: il World Wide Web Consortium (W3C) rilascia la prima specifica del linguaggio di markup
destinato a sostituire HTML. Quel linguaggio si chiama XHTML. La specifica di XHTML occupa una sola
pagina. Non ci sono nuovi tag, non troverete nulla di rivoluzionario rispetto ad HTML 4.0. Eppure, quello che
attualmente il linguaggio raccomandato dal Consortium per la realizzazione di pagine web, davvero un
passo decisivo e fondamentale.
L'elemento chiave la X. Sta per EXTENSIBLE, la stessa X su cui si fonda quella che sicuramente la
pietra angolare della comunicazione digitale del futuro: XML (Extensible Markup Language). La cosa
"rivoluzionaria" appunto questa: HTML ora una parte della grande famiglia XML, ne condivide regole di
base e potenzialit. Risultato: il tempo dell'anarchia, del codice "sporco ma basta che funzioni", degli
elementi proprietari imposti finito. E tutti quelli seriamente interessati allo sviluppo di un web migliore
dovrebbero esserne felici. Con questa guida tenteremo di darvi un quadro complessivo di questo linguaggio,
mettendone in evidenza la struttura, i vantaggi, i problemi di implementazione, gli scenari di applicazione
presenti e futuri.

Struttura della guida


La guida si articola in due sezioni e far riferimento soprattutto a XHTML 1.0. Le lezioni della prima parte, pi
"teoriche" ma con costanti e precise proposte di codice di esempio, copriranno i seguenti argomenti:

Definizione e vantaggi di XHTML

Le regole di base e le differenze con HTML 4.0

Analisi e realizzazione di una pagina XHTML valida

La validazione dei documenti

La compatibilit con i browser

Editor e tools per la realizzazione e la conversione di pagine in XHTML

Esempi di applicazioni avanzate

La seconda parte sar invece centrata su un tutorial che vi guider nella realizzazione di un blog
interamente scritto in XHTML. Senza la pretesa di essere esaustivi, vedremo come questo linguaggio si
integri naturalmente con gli altri standard proposti dal W3C (XML, XSL, CSS) e come questa integrazione
potr cambiare il nostro approccio alla progettazione di siti e applicazioni web.
Nel corso delle lezioni si far costante riferimento alle risorse di HTML.it. In particolare, riteniamo utile, come
lettura propedeutica o complementare, la consultazione della guida ad HTML, ai CSS e del corso su XML.
Alla fine delle singole lezioni daremo riferimenti ad articoli e risorse online sugli argomenti trattati e
aggiungeremo alla fine della guida una bibliografia essenziale.

Idee guida
Nessun progetto nasce senza un'idea guida. Le idee fondamentali che ci hanno guidato nella scrittura di
queste lezioni sono tre:
1. Standard: se non ora quando? Ormai non ci sono pi scuse. Tutti gli attori sul mercato dei browser
producono, oggi, programmi aderenti ai principali standard del W3C. La situazione non potr che
migliorare, con supporti pi adeguati e bug residui finalmente colmati. Per la prima volta da quando
esiste il web chi progetta una pagina "standard compliant" ha la certezza che sar visualizzata
senza problemi con questi strumenti e che lo sar nel futuro. E' l'ora della "forward compatibility".
2. Gli standard: separati ma integrati. Prima si faceva tutto con HTML. Layout, stile, contenuto.
Lavorare con gli standard significa invece usare un linguaggio per lo scopo per cui stato concepito.
La forza sta nell'integrazione dei singoli elementi.
3. Cambiare mentalit. Separare il contenuto dalla presentazione e dalla logica di programmazione.
Non uno slogan vuoto. Significa progetti pi gestibili. Informazioni pi facili da ritrovare. Siti pi

accessibili e trasportabili su altri sistemi. Ma significa anche cambiare le modalit operative, il modo
stesso di pensare un sito o una singola pagina. E' una sfida da raccogliere. Cercheremo di aiutarvi a
capire se ne vale la pena. Buona lettura.

Cos XHTML
Per definire cos' XHTML possiamo iniziare con una semplice espressione:
HTML + XML = XHTML
Esaminiamo i termini dell'operazione.
HTML
Se siete su questo sito sapete di cosa parliamo. HTML un linguaggio di marcatura per presentare i
contenuti di una pagina web. La sua semplicit la base dell'esplosione di Internet. L'ultima
raccomandazione rilasciata dal W3C la 4.01 (dicembre 1999).
XML
XML una sorta di "super-linguaggio" che consente la creazione di nuovi linguaggi di marcatura. Potente,
flessibile e rigoroso alla base di tutte le nuove specifiche tecnologiche rilasciate dal W3C e adottate ormai
come standard dall'industria informatica. I principali obiettivi di XML, dichiarati nella prima specifica ufficiale
(ottobre 1998), sono pochi ed espliciti: utilizzo del linguaggio su Internet, facilit di creazione dei documenti,
supporto di pi applicazioni, chiarezza e comprensibilit. Nella visione di Tim Berners Lee destinato ad
essere il fondamento di un web finalmente universale.
XHTML
XHTML la riformulazione di HTML come applicazione XML. Ci significa essenzialmente una cosa: un
documento XHTML deve essere valido e ben formato. Torneremo in seguito su questi concetti. Per ora
importante chiarire il punto di vista del W3C su XHTML.
Piuttosto che sfornare una nuova versione del linguaggio, un HTML 5.0, gli uomini del Consortium hanno
compiuto un'opera di ridefinizione. Niente nuovi tag, attributi o metodi. Questi rimangono essenzialmente
quelli di HTML 4.0. In pratica: il vocabolario rimane uguale, ma cambiano le regole sintattiche. Se si
comprende questo fatto, sar chiaro come XHTML risponda a due esigenze fondamentali:
1. portare HTML nella famiglia XML con i benefici che ci comporta in termini di estensibilit e rigore
sintattico
2. mantenere la compatibilit con i software che supportano HTML 4.0
Visto cos, XHTML un ponte tra passato e futuro. E' un modo per imparare a pensare in XML partendo da
un linguaggio che conosciamo, senza dover rinunciare, dunque, alle conoscenze gi acquisite.

Versioni di XHTML
Le versioni di XHTML attualmente disponibili e pubblicate come raccomandazioni dal W3C sono tre.

XHTML 1.0
Pubblicata il 26 gennaio 2000 e seguita da una versione rivista dell'ottobre 2001. Consiste, come detto, nella
riscrittura in XML di HTML 4.0 e si basa sulle tre DTD gi definite per questo linguaggio:

DTD Strict

DTD Transitional

DTD Frameset

XHTML Basic
E' una versione "ridotta" del linguaggio. Specificamente pensata per dispositivi mobili (PDA, cellulari),
contiene solo gli elementi che si adattano a questi dispositivi (esclude, ad esempio, i frames che non hanno
ovviamente senso in tale contesto). E' destinata a sostituire WML come linguaggio di base per le
applicazioni WAP.

XHTML 1.1
Basata sulla DTD Strict della versione 1.0, rappresenta la prima formulazione pratica del concetto di
modularit. In questa visione, gli elementi fondamentali (in pratica l'insieme di tag che definiscono la struttura
di un documento) sono raggruppati in una serie di moduli indipendenti, che possono essere implementati o
esclusi secondo le necessit. Secondo il W3C la base della futura estensione di XHTML con altri set di
linguaggi o moduli, anche personalizzati.

Riferimenti
La guida HTML di HTML.it
Il corso su XML di HTML.It
XHTML sul W3C: news, specifiche, definizioni e discussioni
Traduzione italiana della specifica XHTML 1.0 (di Patrizia Andronico)

Vantaggi di XHTML
Quando si propone una nuova tecnologia fatale sollevare dubbi e obiezioni. Consideriamo il quadro
d'insieme degli attuali linguaggi web.
Milioni di pagine sono scritte in HTML. Una gran parte di esse non valida rispetto alle raccomandazioni del
W3C, ma funziona. L'adozione di un nuovo linguaggio (XHTML) non obbligatoria n forzata: tutti i browser
in commercio sono in grado di interpretare HTML 4. XHTML non introduce nuove features rispetto al suo
predecessore. "Perch allora imparare un nuovo linguaggio?". "Perch dovrei riscrivere tutto il mio sito?".
Sono domande scontate, ma legittime. Ecco alcune possibili risposte ed un semplice elenco dei vantaggi di
XHTML.

Codice pulito e ben strutturato


Il passaggio ad XHTML pu essere visto come un ritorno alle origini. HTML nato come linguaggio per
definire la struttura di un documento. Non ha nulla a che vedere con la presentazione. Eppure, stato
stiracchiato da tutte le parti, costretto a svolgere compiti per cui non stato creato. Il caso delle tabelle
quello macroscopico. Sono nate per la presentazione di dati tabulari. Sono state impiegate come l'unico
mezzo per costruire il layout della pagina.
E ancora: quando si sent la necessit di gestire la tipografia dei documenti, venne introdotto il tag <font>
con i relativi attributi. La conseguenza quella di pagine cariche di elementi inutili, pi pesanti, difficili da
modificare.
La responsabilit principale per questo uso improprio di HTML non ricade sugli sviluppatori. Nel 1996 (le
date sono importanti!) il W3C ha rilasciato la versione definitiva di CSS1. Era questa la tecnologia destinata
a definire la presentazione dei documenti. L'idea era chiara: HTML per la struttura, CSS per lo stile e il

layout. Eppure, per avere browser che supportano decentemente questi standard si dovuto attendere il
2000-2001. Quattro anni, tre generazioni di browser, milioni di siti costruiti tentando di risolvere
incompatibilit e bug.
Con XHTML, almeno nella sua versione Strict, si torna ad un linguaggio che definisce solo la struttura.
Semplicemente, se inserite elementi non supportati (font, larghezza per le celle di tabelle o margini per il
body, per citare solo alcuni esempi) il documento non valido. Quindi: la formattazione si fa con i CSS. Mai
pi tag <font>, mai pi gif di un pixel. Tra poco, forse, niente pi tabelle per il layout. Risultato: codice pi
pulito, pi logico, pi gestibile.
Esempio: due pagine realizzate secondo le due impostazioni, diciamo "old style" e "new style". Attenzione al
codice riportato in fondo. Nel secondo caso tutta la formattazione definita in un CSS e si vede! Peso delle
due pagine: "old style" 3 kb, "new style" 1 kb.

Portabilit
Portabilit la capacit/possibilit di un documento di essere visualizzato e implementato efficacemente su
diversi sistemi: PC, PDA, cellulari WAP/GPRS, WebTV. Ora, se pensate alle limitazioni in termini di
memoria, ampiezza dello schermo e usabilit di un terminale mobile, capirete perch importante un
linguaggio essenziale, centrato sulla struttura del documento, privo di orpelli inutili. Ci che ha senso avere
un titolo della pagina, un'intestazione, un paragrafo, una lista per scandire gli argomenti.
Sulla portabilit poggia l'enfasi con cui aziende del calibro di Nokia, Motorola, Ericsson o Siemens guardano
ad XHTML. Dopo l'accettazione da parte del Wap Forum si pu affermare con certezza che la piattaforma
WAP 2 e tutta l'evoluzione dei servizi mobili sar fondata sull'integrazione tra XHTML e CSS, con il supporto
delle necessarie tecnologie sul lato server.
Nelle immagini, tratte da un documento di Nokia, chiarissimo lo schema di distribuzione delle informazioni
fondato su questa interazione. In breve:

nella pagina XHTML incorporiamo diversi CSS per ciascun supporto

il browser viene identificato

su un PC vedremo il layout standard

su un cellulare visualizziamo un layout "ridotto" e adatto alle caratteristiche del mezzo

ci che non cambia sono i contenuti

E' solo uno degli scenari possibili. Se al quadro si aggiungono le enormi potenzialit del linguaggio XSL, si
comprende come l'epoca delle tante versioni di uno stesso sito sia davvero al termine.

Estensibilit
Dal momento che XHTML XML diventa estensibile. Significa che sar facilissimo incorporare in un
documento parti scritte in uno dei tanti linguaggi della famiglia XML.
Esempio. Dovete inserire in una pagina delle formule matematiche complesse. Baster dichiarare il
namespace relativo al linguaggio MathML e inserire nella pagina i tag specifici di quest'ultimo (il codice
tratto dal sito del W3C).
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en">
<head>
<title>A Math Example</title>
</head>
<body>
<p>The following is MathML markup:</p>
<math xmlns="http://www.w3.org/1998/Math/MathML">
<apply> <log/>

<logbase>
<cn> 3 </cn>
</logbase>
<ci> x </ci>
</apply>
</math>
</body>
</html>
I frutti di questo approccio, che il pi semplice dei tanti possibili, sono ancora lontani dalla maturit.
L'implementazione da parte dei browser infatti carente, ma non mancano esempi funzionanti e di grande
potenza. Parleremo in un'altra lezione di FML (Form Markup Language), un linguaggio che estende in
maniera impressionante l'uso dei classici form di HTML.

Accessibilit
Una altro punto fondamentale. I documenti scritti in XHTML e validati sono naturalmente pi accessibili. Da
una parte la validazione richiede l'uso obbligatorio di funzionalit come il testo alternativo per le immagini.
Dall'altra, una pagina che evita elementi non standard, ben definita nella struttura di gran lunga meglio
gestibile da browser alternativi come quelli vocali o testuali. Per questi aspetti obbligatoria la lettura delle
linee guida per l'accessibilit del contenuto Web rilasciate dal W3C e tradotte anche in italiano.

Riferimenti
XHTML linguaggio del futuro: l'articolo espone la visione su XHTML di Nokia e delle principali aziende del
settore mobile.
The fear of X: Molly Holzschlag una delle personalit pi influenti del web design americano. In questo
articolo (tradotto sul numero di Novembre 2001 di PC Professionale) espone la sua visione su XHTML e sui
vantaggi di questo linguaggio. Da leggere altri suoi articoli sull'argomento.

Regole di base
Entriamo nel vivo della conoscenza di XHTML esponendo le sue regole di base. Sono quelle che rendono
un documento strettamente conforme (punto 3.1.1 della specifica) e che ne definiscono i requisiti minimi
essenziali. In pratica: se non si rispettano questi semplici punti il documento non pu essere definito XHTML.

1. Validazione
Un documento deve essere convalidato rispetto ad una delle tre DTD XHTML del W3C. Vedremo nella
prossima lezione come si effettua la convalida. Per ora sufficiente chiarire che essa controlla
essenzialmente due cose: che il documento sia valido e ben formato. Sono due concetti fondamentali
derivati da XML e su cui vale la pena soffermarsi.

Documenti ben formati


XHTML, ricordiamolo, fondato su XML. Da questo eredita il concetto di documento ben formato. Ci
significa che esso deve rispettare le regole della sintassi XML: presenza di un elemento radice, corretto
annidamento degli elementi, chiusura obbligatoria dei tag vuoti, etc. Affronteremo nei dettagli questi aspetti
nelle lezioni successive.

Documenti validi
Un documento valido se usa correttamente un linguaggio, vale a dire se usa nel modo giusto solo elementi
specifici e consentiti. Ma dove vengono stabilite queste regole? Per XHTML (e per XML in genere, anche se
in questo ambito si sta sviluppando l'uso degli schemi) le regole sono definite nelle DTD (Document Type

Definition). Una DTD identifica gli elementi (tag) consentiti, cosa essi significano, come devono essere
trattati (ad esempio, stabilisce quali sono gli attributi possibili per ciascun elemento). In un documento
XHTML la DTD deve essere obbligatoriamente specificata all'inizio. Per ora passiamo alla seconda regola di
conformit.

2. Elemento radice
Ogni documento XML deve contenere un elemento radice. Si tratta dell'elemento che contiene al suo interno
tutti gli altri:
<rubrica>
<contatto>
<nome>Marco</nome>
<cognome>Rossi</cognome>
</contatto>
</rubrica>
Nell'esempio l'elemento radice <rubrica>. In un documento XHTML l'elemento radice deve essere <html>.

3. Namespace XHTML
L'elemento radice <html> deve contenere la dichiarazione di un namespace XML (spazio dei nomi) tramite
l'attributo xmlns. Il namespace usato deve essere "http://www.w3.org/1999/xhtml".

4. Dichiarazione DOCTYPE
In un documento XHTML l'elemento radice deve essere preceduto da un elemento <!DOCTYPE>. All'interno
di questo elemento necessario specificare la DTD di riferimento e il suo URI.
Ora che conosciamo un p meglio XHTML possiamo finalmente creare la nostra prima pagina.

La prima pagina XHTML


Ecco come si presenta il codice di una semplice pagina XHTML basata sulla DTD Strict (figura 1):

Nell'immagine abbiamo evidenziato con colori diversi le quattro sezioni essenziali di un documento XHTML:

in rosso: il prologo

in verde: l'elemento radice (<html>)

in viola: la testata (<head>)

in giallo: il corpo del documento

Le analizzeremo nelle prossime lezioni, definendo nei dettagli la funzione di ciascuna e le differenze con
HTML. Per ora iniziamo con un p di pratica.
Il listato 1 contiene il codice della nostra prima pagina. Copiatelo e incollatelo, anche in un editor di testo.
Salvate, nominando il documento "test.html", visualizzate nel vostro browser preferito.
A questo punto, dopo aver tanto insistito sul concetto di documento valido e ben formato, opportuno
imparare a fare la convalida. All'url http://validator.w3.org possibile effettuare la validazione di qualunque
documento presente in rete: basta inserire l'URI della pagina e cliccare su "Validate this page". Dal momento
che la pagina appena creata localizzata sulla nostra macchina dobbiamo usare un altro metodo.
Il W3C d la possibilit di validare i documenti tramite l'upload del file sui suoi server. Usate quindi l'url
http://validator.w3.org/file-upload.html. Cercate il file da validare sul vostro PC e inviate la richiesta. Se il
documento valido riceverete, questo messaggio (figura 2):

Bene. La prova andata a buon fine, la pagina rispetta le regole. Possiamo ora passare all'analisi delle
quattro sezioni del documento. Cominciamo dal prologo.

Riferimenti
Un validatore alternativo: potete validare i documenti anche su htmlhelp.com. Il sito fornisce utilissime notizie
e suggerimenti su possibili problemi nella convalida.

Il prologo

La figura 1 mostra il prologo di un documento XHTML. Esso risulta composto da due parti: la dichiarazione
XML e la definizione del DOCTYPE.

Dichiarazione XML
La nostra pagina inizia con una riga di codice: <?xml version="1.0"?>. La sua funzione semplice: rendere
esplicito il fatto che il documento XML. Non obbligatoria, ma il suo uso consigliato dal W3C per tutti i
documenti XML. Quando viene usata non deve essere preceduta da altre istruzioni.
All'interno della dichiarazione possibile usare tre attributi. L'unico obbligatorio version (il solo valore
possibile "1.0", in quanto non esistono altre versioni del linguaggio). Un altro attributo, opzionale, ma
spesso usato encoding. Serve a specificare la codifica del linguaggio:
<?xml version="1.0" encoding="UTF-8"?>.

L'ultimo attributo possibile standalone. Se il valore "yes" vuol dire che il documento non fa riferimento ad
entit esterne.
Se il vostro obiettivo la massima compatibilit potete omettere la dichiarazione XML. Molti browser hanno
mostrato problemi cos come alcuni editor (Dreamweaver). Se avete la necessit di specificare una codifica
per i caratteri potete sempre usare un meta tag:
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />

Definizione del DOCTYPE


La dichiarazione del DOCTYPE (obbligatoria!) composta da due sezioni:
1. Un FPI (Identificatore Formale Pubblico) riferito ad una delle tre DTD XHTML (in rosso)
2. L'URI della DTD (in verde)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Essa, dunque, ha lo scopo di stabilire a quale delle tre DTD XHTML intendiamo conformarci e di dire al
browser dove essa collocata. Nel nostro esempio la DTD di riferimento quella Strict, collocata sul sito del
W3C. Il DOCTYPE, inoltre, non ha alcun effetto sulla presentazione della pagina. Serve solo al validatore
per stabilire le regole della convalida.
Notate anche la parola chiave PUBLIC. Significa che la DTD pubblica, creata dal W3C. In effetti, in XML,
anche possibile definire DTD "private", specifiche per la nostra applicazione. In tal caso si usa la parola
chiave SYSTEM.
Un'ultima notazione. Su molti siti (tra cui quello del W3C) vengono forniti schemi di dichiarazione DOCTYPE
per le tre DTD che presentano URI relativi:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"DTD/xhtml1-strict.dtd">
Quest'uso comporta talvolta problemi in fase di validazione, pertanto preferibile usare sempre URI assoluti.
Riportiamo per comodit le tre dichiarazioni per ciascuna DTD. Potete usarle nelle vostre pagine con un
semplice copia e incolla.

DTD Strict
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

DTD Transitional
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

DTD Frameset
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

L'argomento DTD merita comunque un approfondimento. E' ci di cui parleremo nella prossima lezione.

Riferimenti
Come vivere meglio con XHTML: recente articolo apparso su A list apart con trucchi e suggerimenti su un
uso appropriato del DOCTYPE.

Le DTD di XHTML 1.0


Giunti a questo punto dovrebbe essere ormai chiara la funzione di una DTD: descrivere in un linguaggio
comprensibile da una macchina la sintassi e la grammatica di un linguaggio XML. Il tutto allo scopo di
verificare la validit di un documento che a quella DTD fa riferimento.
Le DTD XHTML 1.0 sono contenute in tre documenti che potete anche scaricare sul vostro computer, sia per
imparare come sono fatte sia per usarle direttamente nel vostro sito. In questo modo dovrete modificare
l'URI nella dichiarazione DOCTYPE:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.miodominio.it/DTD/xhtml1-strict.dtd">
Nell'esempio si suppone che la DTD sia localizzata nella cartella DTD di un server miodominio.it. Se ci pu
sembrare una bizzarria ora non lo sar forse tra qualche anno quando milioni di browser tenteranno di
convalidare documenti XHTML contro le DTD del W3C. E' evidente che il pericolo quello di rallentamenti e
strozzature.
L'aspetto su cui ora vogliamo soffermarci il contenuto di una DTD. Il codice quanto di pi criptico si possa
immaginare, ma non mancano manuali che spiegano bene come interpretarle. Facciamo un esempio. Ecco
come viene definito nella DTD Strict l'uso dell'elemento <img>:
<!ELEMENT img EMPTY>
<!ATTLIST img
%attrs;
src %URI; #REQUIRED
alt %Text; #REQUIRED
longdesc %URI; #IMPLIED
height %Length; #IMPLIED
width %Length; #IMPLIED
usemap %URI; #IMPLIED
ismap (ismap) #IMPLIED
>
Traduzione in italiano:
L'elemento immagine vuoto (EMPTY). Puo assumere tutti gli attributi fondamentali (%attrs;): sono quelli
comuni alla maggior parte degli elementi (id, class, style, title). Altri attributi possibili sono: src, alt, longdesc,
width, height, usemap, ismap. Src e alt sono obbligatori (#REQUIRED). Gli altri opzionali (#IMPLIED).
Conoscere il contenuto di una DTD dunque importante. Se non inserite, per esempio, l'attributo alt per
un'immagine e validate la pagina vi verr segnalato l'errore e potrete correggerlo. Ma se si conoscono le
regole in partenza certamente meglio, si eviter di procedere per prova e correzione d'errore.
Per fortuna non necessario imparare una DTD. Esistono per lo scopo ottime reference, elenchi di tutti i tag,
degli attributi e degli eventi consentiti che spiegano in dettaglio il loro uso. Nella sezione riferimenti in fondo
alla pagina segnaliamo un paio di reference online, ma le trovate anche nei migliori manuali su XHTML o
HTML.

Il riferimento ad HTML non deve stupire. Le tre DTD XHTML 1.0 sono infatti basate sulle corrispondenti DTD
elaborate per HTML 4.0. Vedremo ora quali sono le principali caratteristiche di ciascuna.

DTD Strict
E' la DTD pi rigida, centrata esclusivamente sulla struttura del documento. Elimina diversi elementi ed
esclude tutti gli attributi che definiscono la presentazione. Per questo scopo vanno usati i CSS. Segue un
elenco degli elementi non supportati:
<applet>, <basefont>, <center>, <dir>, <font>, <frame>,
<frameset>, <iframe>, <isindex>, <menu>, <noframes>, <s>,
<strike>, <u>
Oltre agli elementi non consentiti particolare attenzione va posta ad attributi molto usati nella comune pratica
del web design. Elenchiamo alcuni casi e rimandiamo ad una buona reference per i dettagli:

sono esclusi tutti gli attributi del tag <body> tranne quelli comuni (vedi sopra)

non si pu usare align per l'allineamento del testo in paragrafi e altri elementi

non supportato l'attributo target per i link e i form

per una tabella (<table>) non si possono specificare il bordo, il colore di sfondo (bgcolor) o
l'allineamento (align)

le celle di tabella (<td>) non supportano il colore di sfondo, la larghezza (width), l'altezza (height).
Supportano invece l'allineamnto del testo (align)

DTD Transitional
Basata sull'omologa DTD di HTML 4.0 attualmente quella pi usata. La spiegazione semplice. Nelle
intenzioni del W3C essa deve essere una sorta di passaggio verso una ridefinizione pi rigida del linguaggio.
In effetti utile quando si voglia passare ad XHTML mantenendo il massimo grado di compatibilit con i
vecchi browser. Supporta tutti gli elementi e gli attributi di presentazione di HTML 4.0, anche quelli ritenuti
sconsigliati. Se dovete e volete ancora usare le tabelle per il layout o fare uso del tag <font> la DTD che fa
per voi.

DTD Frameset
E' identica alla Transitional, ma va usata quando si utilizzano i frame. L'unica differenza in pratica la
sostituzione del tag <body> con <frameset> nella pagina principale.

Riferimenti
XHTML Reference di W3Schools: W3Schools una specie di HTML.it americano. Tante guide e tutorial su
vari aspetti del web design con un linguaggio semplice ed efficace. La reference XHTML un capolavoro di
chiarezza e facilit d'uso.
XHTML Reference di zvon.org: ottimo sito che spazia da HTML ai linguaggi emergenti. La reference XHTML
completa ma poco chiara.

Lelemento radice
Riprendiamo l'analisi delle quattro sezioni della nostra pagina XHTML. E consideramo l'elemento radice:

Come abbiamo visto, l'elemento radice di un documento XHTML deve essere <html>, che deve a sua volta
contenere tutti gli altri elementi. Niente di nuovo direte, tutte le pagine HTML iniziano pi o meno cos:
<html>
<head>
<title>Lezione 7 - L'elemento radice</title>
</head>
<body bgcolor="#FFFFFF" text="#000000">
......... Contenuto della pagina ..............
</body>
</html>
Ma le differenze ci sono e qui potete capire davvero cosa significa il rigore di XML.

<HTML> obbligatorio
Perch prima non lo era? Incredibilmente la risposta : no! <html> era considerato di default. Piccola prova:
<head>
<title>Lezione 7 - L'elemento radice</title>
</head>
<body bgcolor="#FFFFFF" text="#000000">
<h1>Questo HTML!</h1>
</body>
Copiate e incollate queste poche righe in Blocco Note; salvate come "prova.html". Aprite in un browser. La
scritta "Questo HTML!" comparir bella ed evidente. Ma cosa volete farci, i nostri browser sono fatti cos.
Sanno perdonare molto, forse troppo. Si calcola che l'80% della potenzialit del parser HTML di un browser
venga usata per risolvere gli errori di scrittura presenti nelle pagine. E' evidente che sottoponendo questa
pagina a validazione non sarete nemmeno presi in considerazione. Semplicemente questo non un
documento XHTML. Se un giorno i browser (come auspicabile) effettueranno la verifica la nostra paginetta
di test verr sdegnosamente rifiutata perch non corretta. Ma affronteremo l'argomento browser in una
prossima lezione. Ora ribadiamo: <html> obbligatorio.

Il namespace
L'elemento <html> pu assumere questi attributi:
dir

Determina la direzione del testo

lang

Specifica il linguaggio di base dell'elemento


quando interpretato come HTML

xml:lang

Specifica il linguaggio di base dell'elemento


quando interpretato come XML

xmlns

Specifica il namespace predefinito per XHTML

L'unico attributo obbligatorio xmlns. Il W3C, come visto, specifica anche il valore obbligatorio di tale
attributo: "http://www.w3.org/1999/xhtml" (vedi figura 1).
La necessit di un namespace (spazio di nomi) dipende dalla derivazione da XML. Linguaggio estensibile
per definizione. E' possibile, infatti, estendere il set di tag di XHTML con elementi di altri linguaggi, anche
creati personalmente. Specificare uno o pi namespace evita la possibilit di conflitti tra i tag. Chiariamo
anche qui con un esempio.
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//OVERFLOW//DTD XHTML-FML

1.0//EN"
"http://www.mozquito.org/dtd/xhtml-fml1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:x="http://www.mozquito.org/xhtml-fml">
<head>
<title>Untitled</title>
</head>
<body>
<x:form>
</x:form>
</body>
</html>
Il codice riporta l'implementazione di FML (Form Markup Language) in un documento XHTML. FML, su cui
torneremo, un linguaggio che ridefinisce e potenzia l'uso dei form. Come si pu notare all'interno
dell'elemento <html> sono stati definiti due namespace: in rosso evidenziato quello standard di XHTML, in
blue quello di FML.
La differenza tra i due, a parte l'URI, sta nel prefisso. Il primo non ne ha. Il secondo ha come prefisso "x".
Significa che i tag non preceduti da prefisso sono quelli standard di XHTML e come tali verranno intepretati.
Ora date uno sguardo al codice. Nel corpo della pagina stato inserito un form. Ma il tag preceduto da x!
Vuol dire che esso appartiene al namespace FML e come tale deve essere trattato dal browser. Senza
specificare il prefisso avremmo avuto un classico form XHTML.
L'argomento namespace attualmente uno dei pi dibattuti nella comunit XML e dunque vi rimandiamo ad
uno dei tanti siti sull'argomento o ad un manuale aggiornato per chiarificazioni e approfondimenti.

Riferimenti
Nozione e uso dei namespace: dal corso XML di HTML.it una buona introduzione all'argomento.
Form Markup Language: articoli e reference su questa interessante estensione di XHTML

La testata del documento


Presente sin dalle prime specifiche di HTML, la testata (<head>...</head>) ovviamente supportata in tutte
le DTD XHTML:

La funzione principale della sezione <head> quella di contenere informazioni che non vengono
direttamente visualizzate nella pagina, ma che sono comunque di grande rilievo. Ecco l'elenco degli elementi
che possono apparire nella testata:

<base>

Usato per definire l'URL di base della pagina.


Utilissimo per la risoluzione dei link relativi.

<isindex>

Sconsigliato. E' un modo per creare elementi


simili alle caselle di testo.

<link>

Contiene informazioni su documenti esterni


collegati. Usato soprattutto per i CSS.

<meta>

Specifica informazioni di vario tipo sul


documento.

<noscript>

Usato per visualizzazioni alternative nei


browser che non supportano gli script.

<object>

Racchiude un oggetto.

<script>

Contiene script di programmazione .

<style>

Definisce le regole di formattazione per il


documento corrente

<title>

Specifica il titolo del documento che compare


nella barra del titolo del browser

Di questi elementi l'unico richiesto nelle DTD XHTML 1.0 title. In realt se esso viene omesso, il validatore
del W3C non segnala errori. Rimane il fatto che dare un titolo ad una pagina una buona norma da seguire
sempre ed anche utilissimo per i motori di ricerca, che sempre pi considerano questo elemento piuttosto
che le classiche keywords definite nei meta tag.
Tutti gli elementi della testata sono comunque ben noti a chi ha dimestichezza con HTML e nel passaggio ad
XHTML non hanno subito variazioni (a parte, come vedremo, il tag script). Vi rimandiamo pertanto ai
riferimenti per approfondimenti o per un semplice ripasso.

Riferimenti
I meta tag: dalla guida di HTML.it una panoramica sull'uso di questi fondamentali elementi.
Collegare fogli di stile: la guida ai CSS di HTML.it spiega il pi classico uso del tag <link>.
Stili incorporati: dalla stessa guida consigli utili su come formattare un documento con l'elemento <style>.

Il corpo del documento

Il corpo del documento la sezione in cui si sviluppa il contenuto. E' racchiusa, come in HTML, tra i tag
<body>...</body>. Gli elementi che possono comparire all'interno del corpo sono in genere suddivisi in due
categorie: elementi blocco ed elementi inline.

Elementi blocco
Gli elementi blocco sono quelli che definiscono la struttura del documento. Possono contenere altri elementi
blocco, elementi inline o testo. Quando sono inseriti danno origine ad una nuova riga nel flusso del
documento. Chiariamo: se si inseriscono in una pagina queste due righe di codice:
<h1>Titolo</h1>
<p>Paragrafo</p>
il testo "Paragrafo" si trover su una nuova riga, in quanto abbiamo inserito un nuovo elemento blocco (<p>).
Abbiamo riportato in allegato l'elenco di tutti gli elementi blocco XHTML, specificando per ciascuno il
supporto nelle tre DTD.

Gerarchie e annidamento degli elementi blocco


Nella strutturazione del documento fondamentale rispettare alcune semplici regole relative alla gerarchia e
all'annidamento degli elementi blocco. Il primo elemento della gerarchia dovrebbe essere <div>, che
definisce in pratica una sezione del documento. Al suo interno trovano posto gli altri elementi. La cosa
importante che bisogna evitare annidamenti errati, che i browser fanno passare senza problemi, ma che il
validatore segnala impietosamente in quanto violano le regole delle DTD. Esempio:
<p><div>Qui inserisco il mio testo</div></p>
Se inserite questa breve riga di codice in un documento visualizzerete regolarmente il testo. Niente problemi
allora? Non proprio. In realt il documento non valido, in quanto l'elemento <p> non pu contenere altri
elementi blocco. Il giusto annidamento questo:
<div><p>Qui inserisco il mio testo</p></div>
Avete imparato allora una cosa importante: non fidatevi dei browser per verificare se il documento che
scrivete funziona. Molto spesso ci che funziona non valido e in XHTML la correttezza formale
obbligatoria.
La consultazione di un buon riferimento XHTML o la consultazione diretta della DTD potr chiarirvi ogni
dubbio sul corretto annidamento degli elementi. Nella nostra lista abbiamo specificato le regole di contenuto
di base per i principali elementi blocco.

Elementi inline
Gli elementi inline si distingono da quelli di tipo blocco per due motivi: quando sono inseriti non danno
origine a una nuova riga e possono contenere solo dati (essenzialmente testo) o altri elementi inline.
Chiariamo anche qui con un esempio:
<p>Questo tasto <b>grassetto</b></p>
La parte delimitata dai tag <b>...</b> non sar posta su una nuova riga. Anche per gli elementi inline va
posta molta attenzione all'annidamento. Esempi come questo:
<b><p>Testo in grassetto</p></b>
sono tollerati dai browser, ma non reggono al giudizio della validazione in quanto un elemento inline non pu
contenerne uno di tipo blocco. Evitiamoli!
Anche per gli elementi inline forniamo in allegato una lista commentata.

Attributi di body
Gli attributi per il testo, i link, il colore di sfondo e i margini dell'elemento <body> sono espressamente vietati
solo nella DTD Strict, ma erano gi considerati sconsigliati in HTML 4.0. Non vanno pertanto usati e devono
essere sostituiti dai CSS. Li ricordiamo:

alink

background

bgcolor

link

text

vlink

Differenze con HTML


Nella prima lezione abbiamo evidenziato come XHTML sia essenzialmente una ridefinizione di HTML e
l'excursus tra le varie sezioni di una pagina ha confermato questa affermazione. Al di l delle differenze tra le
tre DTD, non abbiamo incontrato nuovi tag o elementi inusuali. Anche quelle che possono sembrare novit
assolute, come la dichiarazione del DOCTYPE, erano in realt gi previste nelle precedenti versioni di
HTML.
Le novit sostanziali riguardano piuttosto la sintassi, il modo in cui tag, attributi e valori vengono usati. Le
esamineremo ora una per una, proponendo sempre il confronto con HTML. Attenzione: l'uso di queste
convenzioni normativo. XHTML un'applicazione XML e alla sintassi di questo deve conformarsi. Non
rispettare queste regole significa non avere documenti validi e ben formati. La cosa che le accomuna che
queste regole pongono fine ad una serie di procedure che HTML consentiva e che ora sono invece vincolate
ad usi ben definiti.

1.Gli elementi devono essere correttamente annidati


HTML
<b><i>un test</b></i>

XHTML
<b><i>un test</i></b>

Il primo esempio non corretto in XHTML. Il tag <i> si sovrappone a <b>. La seconda colonna mostra
invece un corretto annidamento degli elementi. La prima pratica consentita in HTML. Certo, il browser
dovr interpretare qualcosa che ambiguo, ma alla fine ci restituir un testo in grassetto-corsivo (ci che
volevamo). In XHTML non possono sorgere ambiguit, tutto segue una regola.

2. I nomi di elementi e attributi devono essere in minuscolo


XML un linguaggio case sensitive. Significa che <table> e <TABLE> sono cose diverse. In XHTML
consentito solo l'uso delle minuscole per i nomi di elementi e attributi. Anche qui regole pi vincolanti.

HTML
<TABLE><TR><TD>un
test</TD></TR></TABLE>

XHTML
<table><tr><td>un
test</td></tr></table>

3. Gli elementi non vuoti devono essere chiusi


HTML
<p>Test1
<p>Test2

XHTML
<p>Test1</p>
<p>Test2</p>

In HTML la pratica esposta a sinistra tollerata, in XHTML non lo . Ogni elemento non vuoto (sono quelli
che contengono testo o altri elementi) deve avere dopo il tag di apertura quello di chiusura.

4. I valori degli attributi devon essere posti tra virgolette


Anche questa pratica tollerata in HTML. E, soprattutto, causata da molti editor che la "dimenticano" con
molta disinvoltura.

HTML
<img src=test.gif>

XHTML
<img src="test.gif">

5. Ogni attributo deve avere un valore


Alcuni attributi di HTML non hanno un valore (si dice che sono standalone). E' il caso dell'attributo selected
usato per identificare l'opzione di un menu a tendina selezionata all'apertura del documento. In XHTML
anche questi attributi devono essere valorizzati.

HTML

XHTML

<option
selected>test</option>

<option
selected="selected">test</option>

Il problema si pone anche nei form. Se ad esso non si assegna un'azione avremo questa situazione:
<form action=""></form>
Si pu risolvere assegnando un valore fittizio:
<form action="action"></form>

6. Gli elementi vuoti devono terminare con />


In XML tutti i tag devono essere chiusi. Ma cosa fare con gli elementi vuoti? Si tratta di quelli che non
possono contenere nulla al loro interno ma semplicemente ricevere attributi: <meta>, <br>, <hr>, <img>
sono i pi comuni. In XHTML tali elementi vengono chiusi terminando la dichiarazione con />.

HTML
<br>
<img src="test.gif">

XHTML
<br/>
<img src="test.gif"/>

7. Uso di id e name
Per identificare un elemento si deve usare l'attributo id e non name. Apparantemente la cosa non fa una
grinza. In questo modo si ha una perfetta conformit con XML dove id l'attributo standard per
l'identificazione dei frammenti. In realt qui il cambiamento con HTML notevole, perch per elementi come
<img> o <a> l'attributo di identificazione proprio name. Il passaggio a id non pone problemi nei browser pi
recenti, ma con altri (Netscape 4, per esempio) non funziona. In questo caso e se la compatibilit all'indietro
assolutamente necessaria, la stessa specifica XHTML 1.0 suggerisce di usare entrambi gli attributi, anche
se ci contro le regole:

HTML

XHTML
<a id="test">

<a name="test>

Per compatibilit:
<a id="test" name="test">

Nelle specifche successive (cosa che accaduta con XHTML 1.1) l'attributo name stato abolito
completamente.

Gli script in XHTML


Uno degli argomenti pi spinosi relativi a XHTML la gestione dei linguaggi di programmazione,
tradizionalmente incorporati nel documento con il tag <script>. Procediamo con ordine.

Uso di <script>
In HTML il tag <script> serve a incorporare nel documento codice di programmazione. Il linguaggio pi
comunemente usato Javascript. Il tag supportato anche in XHTML e va ugualmente inserito nella
sezione <head>....</head>. L'elemento <script> supporta i seguenti attributi:
charset

Specifica la codifica dei caratteri

defer

Dice al browser che lo script non genera


documenti

Specifica il linguaggio di scripting. E'


langauage obbligatorio quando l'attributo src non
specificato.
src
type

Contiene l'URL di uno script contenuto in un file


esterno
Obbligatorio. Indica il tipo MIME dello script: es
"text/javascript"

xml:space Usato per mantenere la spaziatura del codice


Dunque, uno script pu essere direttamente incorporato nella pagina oppure inserito in un file esterno e
richiamato:

Script incorporato
<script type="text/javascript" language="javascript">
<!-document.open()
document.writeln("Questo XHTML!")
document.close()
//-->
</script>

Script collegato
<script type="text/javascript" src="mioscript.js">
</script>

Caratteri pericolosi
Fin qui niente di nuovo. Il problema sorge quando nello script si utilizzano caratteri "pericolosi" (sensitive
characters nella definizione XHTML). Si tratta di caratteri che possono ingenerare confusione e
fraintendimenti perch il processore XML li interpreta in un modo, nel linguaggio di scripting hanno tutt'altro
significato. In Javascript > significa "maggiore di"; in XML indica la chiusura di un tag. Che fare? Il W3C
suggerisce due vie, ma entrambe presentano punti deboli.

Usare le sezioni CDATA


Nella specifica si suggerisce di racchiudere gli script all'interno di una sezione CDATA. Esse vengono usate
in documenti XML per racchiudere blocchi di testo contenenti caratteri che potrebebro essere interpretati
come elementi di marcatura.

Una sezione CDATA inizia con la stringa <![CDATA[ e termina con ]]>. Ecco come lo script visto in
precedenza apparirebbe:
<script type="text/javascript" language="javascript">
<![CDATA[
document.open()
document.writeln("Questo XHTML!")
document.close()
]]>
</script>
Il punto debole di questo approccio che i nostri browser non gestiscono affatto bene le sezioni CDATA.

Usare script esterni


Si potrebbe ovviare scrivendo gli script in un file esterno e collegandolo al documento. Tutto bene. Ma se
bisogna modificare lo script, magari con ASP o comunque con variazioni lato server? Non possibile farlo.
E allora? In effetti, se la situazione quella appena prospettata, non rimane che usare il vecchio metodo.
Avremo un documento non conforme al 100% in attesa che XHTML sia in grado di incorporare i linguaggi di
scripting diversamente.

Proibizioni in XHTML
In XHTML vengono ereditate da HTML alcune regole che proibiscono l'annidamento di determinati elementi.
Si tratta a volte di casi limite, ma sono comunque regole che importante conoscere. Vediamole:
1. un elemento <a> non pu contenere altri elementi <a>
2. l'elemento <pre> non pu contenere gli elementi <img>, <object>, <big>, <small>, <sub>, <sup>
3. l'elemento <button> non pu contenere <input>, <select>, <textarea>, <label>, <button>, <form>,
<fieldset>, <iframe>, <isindex>
4. l'elemento <label> non pu contenere un altro elemento <label>
5. l'elemento <form> non pu contenere l'elemento <form>

Questioni di compatibilit
La specifica XHTML 1.0 contiene nell'appendice C una serie di linee guida per mantenere la compatibilit
con i browser esistenti. Riguardano aspetti molto importanti e sono da tenere sempre presenti quando la
retrocompatibilit per voi fondamentale. Elenchiamo quelle principali, dal momento che ad alcune di esse
si gi fatto cenno.

1. Elementi vuoti
Quando si usano elementi vuoti opportuno, chiudendoli, lasciare uno spazio prima della slash. Usando la
sintassi standard (<br/>) si hanno problemi con certi browser. Dunque usate sempre questa forma: <br />,
<img... />, <hr />

2. Contenuto degli elementi vuoti


Capita frequentemente di lasciare vuoti elementi che richiedono un contenuto. Spesso, ad esempio, si usano
paragrafi vuoti per creare spazio nel documento. In tal caso preferibile usare la forma completa di chiusura
e non quella minimizzata. Useremo quindi <p></p> e non <p />.

3. Codifica dei caratteri

Se si usa la codifica dei caratteri usare sempre tale dichiarazione sia nella dichiarazione XML sia in un meta
tag:
<?xml version="1.0" encoding="UTF-8"?>
<meta http-equiv="Content-type" content='text/html; charset="UTF-8"' />

4. Uso del carattere &


Se si fa uso della e commerciale (&) in valori di attributi preferibile esprimerlo con un riferimento ad una
entit di carattere: "&amp;". Se, ad esempio, abbiamo un link di qusto tipo:
<a href="http://www.miodominio.it/indice.asp?nome=marco&cognome=rossi">
si scriver:
<a href="http://www.miodominio.it/indice.asp?nome=marco&amp;cognome=rossi">

5. CSS
Quando si collegano CCS esterni opportuno che questi utilizzino le minuscole.
Bene. A questo punto possediamo tutti gli strumenti concettuali per iniziare a lavorare con XHTML. E' giunto
il momento di affrontare questioni pi pratiche. Inizieremo dall'analisi della validazione.

Validazione dei documenti


Nella quinta lezione abbiamo effettuato una semplice prova di validazione della nostra prima pagina XHTML,
imparando che esistono due opzioni, a seconda che il documento sia online oppure offiline. Oltre al
validatore del W3C abbiamo anche segnalato quello alternativo del sito htmlhelp.com.
La prima validazione era, diciamo cos, "pilotata", dal momento che era effettuata su un documento
sicuramente valido. Entriamo ora nei dettagli, partendo dall'analisi delle opzioni che il validatore offre per
svolgere il suo lavoro.
Nella figura 1 abbiamo riportato la schermata della pagina iniziale (l'esempio fa riferimento alla procedura
con upload del file). Come si pu osservare, la prima casella destinata al file da convalidare: se non
ricordate il path preciso, potete ovviamente usare la funzione "Sfoglia" per cercare nelle cartelle del vostro
computer.
La seconda casella (Document type) serve a specificare un DOCTYPE e una DTD. L'opzione di default
"specified inline" . Significa che il DOCTYPE dichiarato nel documento e che la convalida avverr in base
a quello. Scorrendo la lista troverete tutti i possibili modelli, da HTML 2.0 fino a XHTML 1.0 STRICT.
Prima di effettuare la convalida si pu scegliere cosa verr mostrato nella pagina dei risultati. Non
selezionando nessuna casella verr visualizzato solo il rapporto che certifica la correttezza o gli errori
presenti nella pagina. Le quattro checkbox consentono di aggiungere i seguenti elementi:

il codice sorgente - Show source input

un sommario del documento basato sui tag <h1>..<h6> - Show outline of this document

il codice elaborato dal parser - Show parse tree

gli attributi di questo codice - Exclude attributes from the parse tree

Se il documento non valido si possono avere varie possibilit. Per esempio, non inserendo un DOCTYPE
e il namespace XHTML nell'elemento radice, verr riportato un "fatal error": significa che il documento non

stato praticamente preso in considerazione in quanto "ingiudicabile". In altri casi il validatore segnala con
precisione la riga e la colonna dove ha riscontrato gli errori ed offre la possibilit di avere ulteriori spiegazioni
o suggerimenti. Un piccolo consiglio: il validatore non gradisce l'assenza di una dichiarazione che specifichi
la codifica dei caratteri. In tali casi, pur constatando che il documento ben formato, non lo riterr valido.
Pertanto usate sempre un meta tag con una dichiarazione di codifica. Quella pi comune sicuramente:
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
Se il documento valido potrete inserire nelle pagine poche righe di codice che incorporano in essa la gif
(figura 2) che certifica la validit e puntano al validatore:

Validare con Opera


Il piccolo grande browser Opera (versione 5 e 6) offre una bellissima caratteristica per tutti gli sviluppatori.
Mentre siete connessi alla rete e visualizzate un qualunque documento (anche presente solo sul vostro
computer) premete CTRL+ALT+V. Si aprir una nuova finestra che vi porta dritti al validatore del W3C con i
risultati relativi al file che stavate visualizzando. Comodo ed efficace.

Supporto dei browser


La questione del supporto di XHTML da parte dei browser delle pi interessanti. Nel corso delle precedenti
lezioni abbiamo pi volte accennato all'argomento. Qui raccoglieremo le idee e fisseremo i punti chiave del
problema.

Compatibilit con il passato


XHTML 1.0 un linguaggio che garantisce la compatibilit con il passato. Basta salvare il documento con
estensione .html e il gioco fatto. Tutti i browser saranno in grado di rendere il documento, soprattutto se si
rispettano alcune semplici regole. Ne ricordiamo due che risolvono problemi con Netscape 4 e con Explorer
4 e 4.5 per Mac:
1. lasciare uno spazio prima della slash nei tag vuoti: <br /> e non <br/>
2. omettere la dichiarazione XML

Compatibilit con il futuro


Uno dei concetti su cui tante volte si insistito quello di documento valido e ben formato. Nell'ultima
lezione abbiamo imparato tutto sulla validazione. Tenetelo in mente e fatela sempre. Perch fin quando ci
saranno questi browser l'unico modo che avete per assicurarvi che i vostri documenti rispettino gli
standard. I browser attuali non hanno infatti un meccanismo di controllo della correttezza formale di un
documento. Chiariamo subito.
Nel listato 2 abbiamo riportato lo stesso codice della prima pagina XHTML, ma con una piccola modifica:
abbiamo eliminato il tag di chiusura del paragrafo. Copiate il codice, incollate e salvate come "test2.html".
Aprite nel vostro browser. Nessuna differenza rispetto al primo esempio. Ora procediamo alla validazione. Il
validatore vi avvertir che avete omesso il tag di chiusura: il documento non valido.
Cosa impariamo da questo? Che i browser di oggi hanno le maglie molto larghe, lasciano passare tutto, per
loro le DTD non esistono. Visto che per anni ha regnato l'anarchia del codice i loro parser HTML sono
abituati a tutto. Come stupirci? Pensate se fossero stati rigidi censori del nostro codice! Non riusciremmo a
vedere che una percentuale irrisoria di pagine (solo quelle scritte in modo corretto).

Ma facciamo un passo avanti e cerchiamo di capire come potrebbe essere il futuro. Non abbiamo bisogno di
costruire ipotesi. Possiamo provarlo sin da ora.
XHTML XML, ricordate? Bene. I browser recenti (quelli di quinta e sesta generazione) sono tutti in grado di
gestire, pi o meno bene, il formato XML. Ognuno di essi ha un parser XML, un processore che analizza il
documento. I parser XML sono di due tipi:

processori non validanti: verificano soltanto che il documento sia ben formato

processori validanti: oltre alla correttezza formale devono verificare che il documento sia conforme
alla DTD di riferimento

Quelli implementati nei principali browser sono parser del tipo non validante.
Ora prendete i due documenti (la prima pagina e la sua versione modificata). Rinominateli, assegnando
questa volta l'estensione XML (trovate una copia dei file "test.xml" e "test2.xml" nel file zip con i materiali del
tutorial).
I browser hanno comportamenti diversi nel modo di visualizzare l'output del primo documento (quello
corretto), ma tutti fanno la stessa cosa con quello che non ben formato: interrompono la visualizzazione e
segnalano l'errore. Non una bizzarria. E' quanto viene esplicitamente richiesto nella specifica XML: quando
incontra un errore un processore deve interrompere l'elaborazione del documento.
Abbiamo riportato per comodit l'output dei due file prodotto dai seguenti browser (le immagini sono
accompagnate da note di commento):

Explorer 6 Windows

Netscape 6 Windows

Opera 6 Windows

Mozilla Windows

Concludendo: i browser attuali tollerano, ma in futuro? Quando e se ci saranno browser XHTML una pagina
con errori non verr caricata. Torna il discorso di fondo: ci che oggi facoltativo domani sar necessario,
perch non prepararci per tempo al futuro?

XHTML tools: editor e convertitori


In questa lezione vedremo con quali strumenti possibile creare documenti XHTML. Valuteremo due
diverse situazioni: creare pagine ex novo e convertire vecchi documenti.

Editor
Scrivere in XHTML richiede, una grande attenzione al codice. Per certi versi, il passaggio ad un linguaggio
cos rigido nelle sue regole anche la vendetta degli editor testuali su quelli visuali. Chiariamoci subito: chi
scrive stato per anni sostenitore ed utilizzatore soddisfatto di editor WYSIWYG. Ma scrivere XHTML con
questi tools addirittura controproducente. Lavorando in modalit solo visuale la speranza di avere un
documento valido praticamente nulla. Correggere tutto porta via troppo tempo. Meglio scrivere con un
buon editor testuale, magari fornito di funzionalit avanzate come l'autocompletamento del codice. La
speranza, che quasi certezza stando alle dichiarazioni delle software house, che gli eredi delle attuali
versioni di Dreamweaver o GoLive offriranno un supporto maggiore verso gli standard.
A proposito di Dreamweaver, abbiamo inserito nei riferimenti a fondo pagina un ottimo tutorial curato da
Jeffrey Zeldman che offre una serie di utili suggerimenti per settare efficacemente il software di Macromedia
in vista di un suo utilizzo (sempre imperfetto) come editor XHTML.

Passiamo ora in rassegna quelli che appaiono oggi i tool pi efficaci. Abbiamo limitato la scelta a quelli che
ci paiono i migliori editor per il mondo Windows e Mac, di cui abbiamo preso in esame solo il supporto di
XHTML.

Macromedia Home Site 5.0 (Windows)


Home Site 5 un programma eccellente sotto vari aspetti e il supporto di XHTML certamente notevole. Se
si crea un nuovo documento con il wizard iniziale e si sceglie XHTML come formato, il programma adotta
automaticemente l'opzione "Set Document as XHTML", inserendo il DOCTYPE scelto dall'utente,
configurando nel modo giusto i tag di chiusura e usando solo le lettere minuscole. Stupisce negativamente
che non venga inserito l'attributo xmlns nel tag <html> di apertura: si tratta come sappiamo di una delle
quattro regole di base di XHTML.
Dopo che si scritto il codice, Home Site ci viene incontro con un'utile funzione di validazione, ma purtroppo
solo per la DTD Strict. Essa comunque molto precisa nella segnalazione degli errori.
Home Site fornisce anche potenti funzionalit come l'autocompletamento e il cosiddetto "tag insight".
Usando quest'ultimo, mentre si opera all'interno di un tag, viene automaticamente visualizzato un piccolo box
con tutti i possibili attributi, rendendo cos la scrittura molto pi rapida. Purtroppo il "tag insight" non di tipo
intelligente, nel senso che non si adegua alla DTD preselta. E' una funzionalit davvero utilissima di cui
invece dotato uno dei programmi di cui parleremo pi avanti.
Le piccole pecche cui si accennato sono comunque compensate dalla presenza nel programma di una
versione Macromedia di HTML Tidy, un potente convertitore che se ben settato riesce a trasformare in
XHTML e rendere valido qualunque documento. Ne parleremo pi avanti.

Altova XML Spy 4.0


XML Spy un altro grande prodotto, ma le sue caratteristiche sono molto diverse da quelle Home Site.
Mentre il software di Macromedia infatti esplicitamente rivolto al web design, il programma della austriaca
Altova tutto centrato su XML. Con esso potrete praticamente produrre qualunque documento legato a
XML: fogli di stile XSL, schemi, DTD complesse, file WML, SVG o RDF. Essendo XHTML parte integrante di
questa grande famiglia non poteva mancare un supporto per questo linguaggio.
La natura di editor XML evidente per chi viene dal mondo del web design. In XML Spy (la cui interfaccia
non delle pi intuitive) si lavora a livelli di astrazione notevoli, non c' praticamente spazio per ausilii visivi
o per wizard di qualunque tipo, anche se il programma consente una preview interna sfruttando la presenza
di Internet Explorer. Carente risulta anche l'aiuto in linea.
Nonostante ci, dotato di alcune caratteristiche davvero straordinarie. Il controllo sulla validit e sulla
correttezza formale incredibilmente preciso ed efficace, al punto da rendere praticamente inutile la
validazione del W3C. Questo perch tratta i documenti come XML e quindi effettua un confronto severo
rispetto alle DTD (di cui una copia presente anche in locale). Inoltre, la sua funzionalit di tag insight
intelligente. Se, ad esempio, si sceglie la DTD Strict, nel piccolo box compariranno solo gli attributi consentiti
in quella DTD. Si passa alla Transitional? Ecco che il software si adegua fornendo gli attributi corrispondenti.
Concludendo. Un programma eccellente, ma che risulter forse un p ostico a chi abituato a pensare ad
una pagina web principamente in termini visuali.
Una recensione ampia del programma (centrata per su XML) stata pubblicata sul numero di dicembre
2001 di PC Professionale ed disponibile sul sito della rivista.

BB Edit 6.5 (Mac)


Se lavorate in ambiente Mac, la scelta quasi obbligata: BB Edit di Bare Bones Software. La versione 6.5
disponibile anche per il nuovo MacOs X ed offre un supporto validissimo per XHTML.

Anche qui, come in Home Site, quando si crea un nuovo documento si pu contare su una sorta di wizard
iniziale che consente di settare gli elementi di base del documento. Rispetto ad Home Site le opzioni sono
per molto pi numerose: possibile scegliere il DOCTYPE, impostare la codifica dei caratteri, il titolo,
inserire o meno la dichiarazione XML. BB Edit, inoltre, inserisce correttamente il namespace XHTML. Al
termine della procedura abbiamo un documento XHTML di base valido e completo.
Al posto del tag insight, in BB Edit troviamo un eccellente tag maker, anch'esso sensibile al contesto e alla
DTD prescelta. Il tag maker attivabile in vari modi, ma purtroppo non automaticamente. Una pecca tutto
sommato piccola, se ci si abitua alle scorciatoie di tastiera e se si valuta il set di funzionalit di questo
programma che certamente il miglior editor di file testuali del mondo Mac e non solo.

Convertitori
Se si ha la necessit di convertire molte pagine HTML in XHTML si hanno due possibilit. Affrontare
un'estenuante operazione di riscrittura manuale (magari con uso massiccio di "Trova e sostituisci") o usare
HTML Tidy.
Si tratta di una straordinaria utility creata da Dave Raggett pubblicata sotto licenza Open Source e
disponibile per un numero incredibile di piattaforme. Cosa fa? Semplice: dato un file di configurazione in cui
sono contenute le regole di trasformazione, il programma ripulisce le vecchie pagine e le adegua allo
standard XHTML. Il numero delle opzioni selezionabili notevole, alcune riguardano aspetti (come la
codifica dei caratteri e delle entit) certamente criptici per i non esperti. In questo e nel fatto di essere
utilizzabile solo da linea di comando sta la sua maggiore difficolt d'uso. Una volta che si siano imparate le
regole, comunque, si rivela uno strumento efficace e insostituibile. Per chi volesse contare sulla potenza di
HTML Tidy ma sfruttando un'interfaccia amichevole rimane la possibilit di usare il tool integrato in Home
Site 5.0 di cui si parlato.

Riferimenti
Dreamweaver e XHTML: come usare il popolare software di Macromedia per scrivere XHTML valido (o
quasi).
Home Site 5.0: presentazione del prodotto e supporto sul sito di Macromedia.
XML Spy 4.0: la home page di uno dei migliori editor XML.
BB Edit: il sito di Bare Bones Software.
HTML Tidy: regole, impostazioni, tutorial e download di questo utilissimo e potente strumento di
conversione.

Uno sguardo al futuro: XHTML 1.1


Con XHTML 1.0 il World Wide Web Consortium aveva voluto esplicitamente creare un linguaggio di
transizione: passare ad XML ma mantenendo il pi possibile la compatibilit con il passato. La scelta di
basare le tre DTD su quelle di HTML 4.0 ne la prova pi evidente. XHTML 1.1 invece tutto proietatto
verso il futuro. Nelle intenzioni del Consortium esso sar la base per futuri linguaggi web estensibili e
facilmente adattabili ad un ampio numero di dispositivi.
La definizione di questa specifica strettamente legata ad un'altra raccomandazione, quella relativa alla
modularizzazione di XHTML. Se XHTML 1.0 era consistito nella riscrittura di HTML come applicazione XML,
questo nuovo approccio punta invece a frammentare il linguaggio in tanti moduli indipendenti. E' un
argomento complesso e un suo approfondimento va oltre gli scopi di questa guida. In questa lezione daremo
pertanto solo riferimenti essenziali.

Linguaggio pi "stretto"
In XHTML 1.1 il W3C ha portato al termine la sua redifinizione di un linguaggio di markup orientato solo alla
struttura. E' basato infatti sulla DTD Strict di XHTML 1.0: tutti gli elementi e gli attributi di presentazione sono
definitivamente esclusi. La dichiarazione DOCTYPE pu dunque fare riferimento solo ad una DTD e non a
tre:
<!DOCTYPE
html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
Rimangono invariate le altre regole di base relative all'elemento radice <html> e alla dichiarazione del
namespace con l'attributo xmlns.

Moduli
La DTD XHTML 1.1 diversa dalle precedenti. Non contiene una lista di elementi e attributi con le regole
che ne definiscono l'uso. E' invece costituita da diverse dichiarazioni che includono altrettanti moduli. Le
specifiche sui moduli XHTML fanno parte di un'altra raccomandazione, quella sulla modularizzazione di
XHTML.
Senza scendere nei dettagli, diciamo che ciascun modulo definisce un insieme di elementi e attributi per una
determinata classe di oggetti. Ecco perch si detto che XHTML 1.1 smonta il linguaggio. Esiste, ad
esempio, un modulo "structure" che serve a definire la struttura di base di un documento e che contiene:
body, head, html, title. E ancora, troviamo un modulo per il testo, uno per i form, uno per le liste e cos via.
Potete farvi un'idea precisa sui moduli e sul loro contenuto consultando la specifica XHTML 1.1.
Nella DTD XHTML 1.1 un modulo viene caricato con questa dichiarazione (l'esempio fa riferimento
all'inclusione del modulo form):
<!-- Forms Module ..... -->
<!ENTITY % xhtml-form.module "INCLUDE" >
<![%xhtml-form.module;[
<!ENTITY % xhtml-form.mod
PUBLIC "-//W3C//ELEMENTS XHTML Forms 1.0//EN"
"http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-form-1.mod" >
%xhtml-form.mod;]]>
L'approccio modulare stato ben descritto da Molly Holzschlag in uno dei suoi articoli su XHTML. Esso
viene paragonato all'uso di certi portatili in cui le varie periferiche possono essere inserite e tolte a seconda
delle necessit. Ho bisogno del floppy? Collego il floppy. Mi serve il CD-Rom ma non il DVD? Facile, attacco
il primo e stacco il secondo. Non mi serve nessuno dei tre? Non importa: il mio portatile continuer a
funzionare.
Ecco perch dei moduli inclusi nella DTD alcuni sono richiesti e altri opzionali. Quelli richiesti sono
indispensabili perch senza di essi non si potrebbe nemmeno parlare di un documento. E' come se al
portatile di prima togliessimo, invece del floppy, la RAM: si potrebbe chiamare ancora PC?

Altre differenze
Nella specifica XHTML 1.1 vengono anche indicate le differenze con la DTD Strict di XTML 1.0. Esse sono:

l'attributo lang sostituito da xml:lang

per gli elementi img e map l'attributo name sostituito da id

stata inserita la collezione di oggetti ruby

Riferimenti
Specifica XHTML 1.1: la raccomandazione definitiva datata 31 maggio 2001.
Come creare moduli XHTML: dal sito del W3C. Articolo-tutorial complesso ma essenziale.
Introduzione alla modularizzazione: sempre dal sito del W3C, breve e coinciso articolo sui moduli.
Specifica "Modularizzazione di XHTML": complessa, ricchissima, fondamentale. La seconda parte spiega in
maniera completa come implementare nuovi moduli ed estendere le DTD.

XHTML Basic e il Wap che verr


Il mercato della cosiddetta Internet Mobile certamente uno dei pi promettenti. L'avvento e l'affermazione
di tecnologie come GPRS e UMTS sono un'occasione importante non solo per le aziende tradizionali del
settore, ma anche per i fornitori di contenuti. Certo, le previsioni che volevano per il 2002 una percentuale
del 75% del traffico Internet diffuso su dispositivi mobili si sono rivelate premature, ma ci non ha diminuito
l'interesse per un settore che deve ancora dare il meglio di s.
La piattaforma finora usata per la diffusione di contenuti su cellulari e altri dispositivi mobili stata WAP 1.x,
che usava come linguaggio una delle prime applicazioni XML, WML (Wireless Markup Language). L'uso di
WML probabilmente uno dei motivi del mancato decollo del WAP. Difficolt e alti costi di implementazione,
la necessit per gli sviluppatori di dover imparare un linguaggio nuovo, l'adattamento dei server web sono
stati tutti fattori di ostacolo.
Le principali aziende del settore, riunite nel Wapforum, hanno iniziato cos un'opera di ripensamento e
ridefinizione della piattaforma. Uno dei cardini di questa operazione l'adattamento agli standard di Internet.
Il motivo facile da comprendere: si tratta di linguaggi facili, diffusi, che non richiedono drastiche operazioni
di ricostruzione e adattamento e che sono pi potenti e flessibili di WML. Quest'ultimo sar ovviamente
supportato dai prossimi browser mobili, ma il linguaggio elettivo della piattaforma WAP 2.0 XHTML.
Ma quale XHTML? I dispositivi mobili (cellulari, ma anche PDA e palmari di vario genere) sono limitati. Poca
memoria, schermi piccoli, navigazione oggettivamente poco agevole. C' bisogno dunque di un linguaggio
che implementi solo gli elementi adatti a questi dispositivi. Questo linguaggio si chiama XHTML Basic. E'
basato sull'approccio modulare visto nella lezione precedente, ma invece di estendere, snellisce e riduce
all'essenziale il linguaggio. Come? Includendo solo pochi moduli (la specifica XHTML Basic definisce quali
sono quelli supportati).
Tra gli elementi non supportati troviamo i frames, gli script di programmazione, l'uso di stili incorporati con
<style>, diversi elementi di testo, oltre a vari attributi di presentazione. E ancora: sono supportati solo i
moduli di base dei form, consentito l'uso delle tabelle ma non nidificate. Fondamentale la possibilit di
definire la presentazione dei documenti con CSS esterni collegati.
Le regole di base sono identiche a quelle di XHTML 1.0. La dichiarazione DOCTYPE per questa specifica,
che fa riferimento alla DTD XHTML Basic la seguente:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">

Riferimenti
La sezione riferimenti questa volta pi corposa del solito, ma una visita ai siti proposti vi dar un quadro
completo su XHTML Basic e sull'evoluzione dei servizi WAP. Cominciamo con le risorse di HTML.it:
Il corso di WML: per conoscere il linguaggio di base di WAP 1.x
Programmare WML: corso di base di WML scipt

Wapitalia: portale informativo sul mondo WAP


Punto di riferimento fondamentale, anche per XHTML Basic il sito del W3C:
Specifica: la raccomandazione ufficiale. Contiene tutto quello che c' da sapere, compreso il driver della
DTD e i riferimenti ai moduli implementati.
Traduzione italiana della specifica: ottima e provvidenziale, opera di Patrizia Andronico.
Tra i punti di riferimento obbligati su WAP e XHTML Basic va annoverato Forum Nokia, la sezione per gli
sviluppatori del sito della casa finlandese. Per accedere ai contenuti bisogna registrarsi (gratuitamente). Vi
consigliamo di farlo. La qualit e quantit di documentazione su XHTML di livello assoluto:
Il sito del Forum Nokia: pagina iniziale del portale.
La sezione browsing/wap: il posto dove cercare notizie e documenti su XHTML.
Linee guida XHTML: documento ricchissimo su come realizzare documenti in XHTML Basic. Questioni di
usabilit, design, compatibilit e differenze con WML: fondamentale!
Nokia Mobile Internet Toolkit: se siete seriamente interesasti allo sviluppo di applicazioni WAP non potete
non avere questo strumento. Consente la realizzazione, l'implementazione e il test di applicazioni mobili
basate su WML e XHTML. Scaricabili a parte sono i simulatori dei pi diffusi terminali Nokia.
XHTML Basic in azione: presentazione animata in Flash del Nokia Mobile Browser, ovvero il browser che ci
far navigare nelle pagine scritte in XHTML Basic.

Estendere XHTML: FML (Form Markup Language


Attenzione!: il sito Mozquito.com, cui si fa continuo riferimento all'interno di questa lezione, ha purtroppo
chiuso alcuni mesi dopo la pubblicazione di questa guida. Tuttavia, pur con la mancanza di questi link, la
lezione conserva la sua utilit didattica.
Mozquito una delle aziende pi impegnate nella ridefinizione dei linguaggi Web basati su XML e partecipa
attivamente ai lavori del W3C. Tra le sue realizzazioni ci occupiamo qui di FML (Form Markup Language). E'
un linguaggio che estende XHTML e che ridefinisce l'uso e le potenzialit dei classici form HTML. Stando
alla documentazione ufficiale dell'azienda, FML dovrebbe:

ottimizzare e potenziare l'interazione tra l'utente e il server

ottenere con un solo linguaggio di markup risultati raggiungibili solo con uso complesso di Javascript
o plug-in esterni

creare facilmente documenti distribuibili su varie piattaforme

Concretamente significa, ad esempio, creare velocemente slide-show, quiz, applicazioni di e-commerce,


sondaggi, motori di ricerca. Per apprezzare le possibilit di questo linguaggio potete visualizzare alcuni
esempi o il tutorial presente sul sito di Mozquito: tutta l'applicazione realizzata in una sola pagina, senza
uso di frame (un'altra delle potenti caratteristiche del linguaggio).
L'implementazione di FML un classico esempio funzionante di modularizzazione. Riprendiamo l'esempio
gi visto in un'altra lezione:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//OVERFLOW//DTD XHTML-FML
1.0//EN"
"http://www.mozquito.org/dtd/xhtml-fml1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:x="http://www.mozquito.org/xhtml-fml">

<head>
<title>Untitled</title>
</head>
<body>
<x:form>
</x:form>
</body>
</html>
Apparentemente un normale documento XHTML, ma le differenze ci sono:
1. La DTD (in verde) non quella pubblica del W3C ma una versione "modificata" che implementa le
caratteristiche di FML
2. Vengono dichiarati due namespace: quello standard di XHTML (in rosso), quello per FML (in blue)
Questo ci che vediamo nel documento. In realt, il cuore di tutto risiede nella DTD. Essa risulta come un
mix della DTD XHTML 1.1 per certi moduli e della DTD FML per altri. Come si ottiene questo risultato?
Escludendo i moduli riguardanti form, applet oppure oggetti e sostituendoli con quelli di FML. Il codice di
esempio riporta la dichiarazione di esclusione dei moduli di XHTML:
<!ENTITY % xhtml-applet.module "IGNORE" >
<!ENTITY % xhtml-script.module "IGNORE" >
<!ENTITY % xhtml-object.module "IGNORE" >
<!ENTITY % xhtml-form.module "IGNORE" >
<!ENTITY % xhtml-model.module "IGNORE" >

Subito dopo, scorrendo la DTD, troviamo la dichiarazione dei moduli FML che sostituiscono i form:
<!-- This section declares parameter entities used to provide
namespace-qualified names for all FML element types.
-->
<!-- module: fml-form-1.mod -->
<!ENTITY % FML.form.qname "%FML.pfx;form" >
<!ENTITY % FML.button.qname "%FML.pfx;button" >
<!ENTITY % FML.textinput.qname "%FML.pfx;textinput" >
------------------------------------Non entriamo in dettagli estremamente complessi: il meccanismo dovrebbe essere chiaro.
Realizzare documenti in XHTML-FML non difficile. Per provare basta scaricare la demo di Mozquito
Factory 1.5. Si tratta di un editor che implementa i form FML. I file prodotti dall'applicazione hanno come
estensione XHTML e sono di dimensione davvero ridotte se si pensa a quali caratteristiche implementano.
Ma con un ottimo meccanismo di codifica possono essere immediatamente convertite in HTML. Avrete le
stesse funzionalit, ma con codice Javascript e purtroppo con dimensioni maggiori: da 12kb si pu passare
a 71kb! Cosa fare? Aspettare che ci siano browser in grado di leggere direttamente le pagine XHTML-FML,
trasformare in HTML ma con gli svantaggi visti oppure appoggiarsi al Matrix Server della stessa Mozquito
che effettua le trasformazioni sul server mantenendo dimensioni accettabili.
Uno dei motivi per scaricare la demo di Mozquito Factory anche la presenza di molti esempi funzionanti,
che potranno rendere la giusta idea di questa eccellente estensione di XHTML.

Presentazione del tutorial


Cosa realizzeremo
Obiettivo del tutorial la realizzazione di un blog. Per i pochi che non lo sanno: blog l'abbreviazione di
weblog. E' una sorta di cronaca digitale personale con una serie di post su vari argomenti disposti in ordine
cronologico. Il fenomeno esploso da un paio di anni ed ha dato vita a sperimentazioni interessantissime:
sui contenuti, sul design, sulla creazione di sistemi di gestione dei contenuti (CMS).
Per fare un blog serve essenzialmente una cosa: avere qualcosa da dire. Tecnicamente, ci si pu
appoggiare a servizi dedicati (Blogger, Manila, LiveJournal, Pitas) o fare tutto da s. Se questa la vostra
soluzione, sappiate che per una gestione facile fondamentale avere a disposizione uno spazio web con
supporto di tecnologie server-side. Tutto va bene: Windows + ASP, come Apache con PHP e MySQL.

Come funziona un blog


Il funzionamento di un blog semplicissimo. Sono essenzialmente basati su una sola pagina principale che
ospita i post quotidiani, ma possono contenere una serie di link accessori interni (biografia, contatti, archivi e
cose del genere) o esterni (siti interessanti, segnalazioni, etc). Una visita a blogger.com potr darvi un'idea
su stili e tendenze.
La fase cruciale quella dell'aggiornamento e dell'inserimento dei nuovi post. Il metodo deve essere
semplice e deve consentire possibilmente la conservazione dei contenuti in database o sistemi simili. Ecco
perch importante avere a disposizione tecnologie server-side. Per il nostro blog non ci baseremo su
database, ma useremo il pi semplice XML. E visto che si parla di linguaggi, vediamo quali sono le
tecnologie che adotteremo.

Quali linguaggi useremo


L'idea guida di questo tutorial che i linguaggi standard del W3C danno il meglio di s se usati per lo scopo
per cui sono stati creati. Sono come singoli musicisti che vanno messi insieme per fare un'orchestra. Ecco,
allora, la lista ragionata dei nostri "suonatori":

Linguaggio

Funzione

XHTML

Lo useremo per definire la struttura delle nostre


pagine.

CSS

Con i CSS imposteremo il layout e lo stile


grafico/tipografico del blog.

XML

In un file XML conserveremo i post che


andremo poi a incorporare nella pagina
principale.

XSL

Con XSL (Extensible Stylesheet Language)


trasformeremo in XHTML i contenuti del
documento XML.

ASP

Grazie ad ASP, che lavorer sul lato server,


supereremo le difficolt di implementazione di
XML nei browser.

Il workflow dell'applicazione pu essere cos schematizzato:

Con ASP carichiamo il documento XML e il foglio di stile XSL che lo trasformer. Il risultato della
trasformazione, che avviene sul server, sar un documento XHTML con un CSS collegato che ne definisce
lo stile. Questo documento sar la pagina principale del blog.

Come procederemo
Le lezioni del tutorial affronteranno, nell'ordine, questi punti:
1. creazione dei prototipi grafici
2. creazione della struttura di base in XHTML
3. definizione dello stile e del layout con i CSS
4. gestione dei post con XML
5. trasformazioni con XSL
6. gestione del sito con ASP
7. aggiornamento del blog

Quali strumenti ci servono


Potrebbe bastare un editor di testo. Sia perch scrivendo si ha un controllo perfetto sul codice, sia perch
forniremo di ogni documento il codice sorgente (basta un copia e incolla). Comunque, se lavorate in
Windows, vi suggerisco il terzetto Macromedia Home Site + XML Spy + Top Style Pro 2.10. Per testare tutto
opportuno installare e settare correttamente il Personal Web Server o Internet Information Server.

Materiali
Abbiamo riunito in un file zip tutti i file completati e commentati della nostra applicazione. Potete scaricarli
per seguire meglio le lezioni o testare subito il blog. Scompattando il file verr creata automaticamente una
cartella "blog".
Scarica il file blog.zip.

Riferimenti
Tra i riferimenti sono compresi ovviamente i siti citati nella lezione. Aggiungo i link di altri blog dedicati al web
design e accomunati da alcune specifiche tecniche per noi importanti: scrittura in XHTML, validit, rispetto
degli standard, utilizzo dei CSS. Tra essi (perdonatemi) il link del mio blog. Questo tutorial non altro che la
spiegazione di come stato realizzato, anche se cambiano alcune funzioni avanzate e la grafica che stata
per l'occasione notevolmente semplificata:
4 banalitaten: il mio blog.

Zeldman.com: pi di un blog: un riferimento assoluto.


Waferbaby: stile essenziale, contenuti originali. Un concentrato di intelligenza.
Hivelogic: pulito, ottima tipografia, il blog di Dan Benjamin.

Struttura e stile del Blog


Un passo preliminare e importante in un progetto web la realizzazione di un prototipo grafico. Esso utile
per evidenziare la struttura e gli elementi stilistici di base che saranno poi tradotti in codice XHTML (per la
struttura) o CSS (per lo stile).

La struttura
Iniziamo con la struttura. Ecco l'immagine del prototipo strutturale realizzato con Fireworks.
La pagina principale del nostro blog (X-blog) costituita da sei sezioni:
1. Sezione principale: quella che contiene tutte le altre e che definisce lo spazio della pagina
destinato al blog
2. Testata: qui inseriremo il logo
3. Menu: barra di navigazione orizzontale con link alle sezioni interne del sito
4. Contenuto: una sorta di box che definisce la sezione centrale, a sua volta distinta in due
sottosezioni
5. Navigazione: contiene link esterni suddivisi in categorie
6. Post: qui verranno inseriti i post di X-blog
Al momento di tradurre in XHTML questa struttura non faremo uso di tabelle. Ogni elemento deve fare il suo
lavoro. Quando vorremo mostrare la classifica della serie A, useremo una tabella. Qui si tratta di definire
sezioni, blocchi di contenuto generici e in XHTML l'elemento da usare <div>.

Lo stile
A questo punto possiamo dare un p di vita alla nuda collezione di box annidati vista in precedenza. E' il
momento creativo. Qui imposteremo colori, margini, font, spaziature. Ed anche questa volta opportuno,
prima di mettere mano al nostro editor CSS preferito, preparare il terreno con un buon prototipo grafico.
Da questa immagine potete farvi un'idea abbastanza precisa di come apparir X-blog. Analizziamo alcuni
dettagli:

il font principale Verdana, ma nel CSS vanno definiti caretteri alternativi

la sezione menu ha uno sfondo giallo con testo rosso

lo sfondo della sezione navigazione richiama quello della testata

l'intestazione delle categorie va differenziata dai link: la prima sar definita con un tag <h1>, i
secondi con un <p>

nella sezione post abbiamo questa struttura: titolo del post (<h1>), data (<h2>), testo (<p>)

Codice
Ora si pu finalmente tradurre l'idea in codice. Ovviamente definiremo la struttura in XHTML, lo stile in un
CSS.

Nel listato 3 abbiamo riportato il codice del documento "blog.html", la pagina principale. Notate innanzituto il
rispetto delle regole di base XHTML (DOCTYPE, namespace, chiusura degli elementi, uso delle minuscole).
Osservate poi la pulizia e l'essenzialit. La DTD usata quella Strict. Il listato 4 contiene invece una versione
commentata dello stesso documento: vi aiuter a chiarire ogni aspetto relativo alla struttura. Attenzione per:
il codice di questo documento vi serva da punto di riferimento, non consideratelo come un punto d'arrivo.
Nella nostra applicazione esso sar generato automaticamente grazie alla magia di XSL. Certo, il gioco
potrebbe anche finire qui. Ma pensate al momento in cui dovrete inserire nuovi post. Vi sembra comodo
dover intervenire ogni volta sul documento XHTML? Il nostro obbiettivo separare i contenuti dalla
presentazione. Quindi, ancora un p di pazienza, ci arriveremo.
Nel foglio di stile "mainstyle.css" definiamo invece le regole di formattazione. Anche di questo file forniamo,
nel listato 5, una versione commentata. Il CSS piuttosto semplice.
Dopo le regole generiche per il tag <body>, contiene sei id (contraddistinti dal simbolo #), uno per ciascuna
sezione:

sezprinc

testata

menu

contenuto

navigazione

post

Di ognuno sono definite le regole di formattazione (larghezza, margini, bordi, colori, font, etc) e ognuno viene
associato ad un <div> nel file XHTML tramite l'attributo id:
<div id="sezprinc">, <div id="menu">, etc.
Inoltre, sono stati creati dei selettori contestuali. Visto che intendiamo usare il tag <p> o <h1> in diverse
sezioni e visto che devono avere una formattazione diversa si usa questa particolare forma di selettore. Con
#navigazione h1 stabilisco come deve apparire l'elemento <h1> all'interno della sezione navigazione, con
#post h1 come appare nella sezione post.
Ricordiamo che tutti i documenti sono contenuti nell'allegato file dei materiali. Volendo testare il tutto,
scompattate lo zip e aprite nel browser il documento "blog.html".

E le tabelle?
Ritorniamo ad un punto appena accennato. Il layout di X-blog fatto senza tabelle. E' una tecnica ancora
non completamente matura, ma che comincia a dare buoni frutti proprio nel settore dei siti personali e dei
blog. La non perfetta implementazione dei browser costringe ancora a usare vari trucchetti per superare
alcune incompatibilit. Nei browser recenti (quinta e sesta generazione di Explorer, Netscape e Opera, pi
Mozilla) non avrete problemi. Rimangono i browser datati. Per questi il supporto di questo tipo di layout
carente. Ma un blog un sito personale e se non si sperimenta qui non vedo dove. Le tecniche per
l'implementazione di layout senza tabelle sono molte. La sezione riferimenti contiene un elenco di ottimi siti
dedicati all'argomento. Nella prossima lezione ci limiteremo a spiegare il metodo usato per X-blog.

Riferimenti
La sezione riferimenti di questa lezione intende darvi un quadro dell'implementazione di layout senza tabelle,
basati solo sui CSS:
Introduzione al layout con i CSS: introduzione? E' un articolo completo, ben scritto, ricco di esempi, il
migliore sull'argomento. Eric Costello sul sito di Apple.
CSS layout tecniques: il sito personale dello stesso Costello

CSS Edge: esperimenti con i CSS di Eric Meyer


Box Lesson: raccolta incomparabile di trucchi, tecniche e layout pronti per l'uso.

Tabelle addio
In questa lezione analizzeremo alcuni dettagli relativi al foglio di stile "mainstyle.css". In particolare
spiegheremo in che modo sia stato realizzato il layout senza fare uso di tabelle.

Centrare
Abbiamo visto nella precedente lezione che gli elementi fondamentali del CSS sono i sei #id che definiscono
le propriet di formattazione delle corrispondenti sezioni (identificate con il tag <div> nel documento
XHTML). La prima cosa da evidenziare il metodo usato per centrare il box principale (#sezprinc).
In HTML avremmo inserito una tabella centrandola con l'attributo align:
<table align="center">
Nei CSS non possibile usare un attributo simile se non per il testo (propriet text-align). L'ostacolo pu
essere superato con un uso accorto della propriet margin. L'id #sezprinc cos definito:
#sezprinc {
background: #FFFFFF;
------------------margin : 20px auto;
text-align : left;
width : 574px;
}
Per centrare si procede in questo modo:
1. Si assegna al box una larghezza esplicita (width: 574px;)
2. Si assegna ai margini sinistro e destro il valore auto. In questo modo essi avranno una larghezza
identica.
Nel nostro caso il valore della propriet margin va cos interpretato: il margine superiore di 20 pixel, quello
degli altri lati sar calcolato automaticamente (auto). Questo importante, perch ci consente un design
fluido e ci fa essere certi che cambiando risoluzione il box sar sempre centrato. Alla risoluzione di 800x600
(figura 1), ad esempio, i margini sinistro e destro saranno di 113 pixel (800-574=226/2=113). A 1024x768 di
225 pixel (figura 2).
Per...C' un piccolo problema nell'uso di questo metodo: Explorer 5 per Windows non interpreta bene la
tecnica. Ma il modo per ingannarlo c'. Il browser di casa Microsoft non gestisce secondo gli standard
nemmeno l'attributo text-align. Infatti, applica l'allineamento anche ai box e non solo al testo che contengono.
Allora, visto che #sezprinc contenuto nell'elemento body basta aggiungere tra gli attributi di quest'ultimo
l'istruzione "text-align: center;". Ecco il codice del nostro CSS, dove lo stile dell'elemento body occupa infatti
il primo posto:
body {
background : #FFFFFF;
------------------text-align : center;
}
Tutto bene? Un attimo. Explorer 5 in questo modo centrer correttamente il box, ma sorge un problema. Se
definiamo l'attributo "text-align:center;" per l'elemento body succede che in tutti i box sottostanti il testo sar

centrato. Rimediare ancora facile. Basta specificare nelle propriet di #sezprinc l'attributo "text-align:left;",
cosa che, come potete osservare sopra, abbiamo fatto puntualmente.

Testata
L'id #testata non presenta particolari problemi. In questo caso abbiamo settato esplicitamente l'altezza
(height: 75px;), ma non la larghezza: essa sar pertanto identica a quella del box parente (#sezprinc).

Menu
Poche osservazioni anche sull'id #menu. Abbiamo voluto che fosse meno ampio della testata. La sua
larghezza infatti di 512px. Con i margini abbiamo quindi impostato la sua posizione rispetto agli altri box:
margin : 0px 26px 1px;
Ricordiamo qui che l'ordine in cui vanno letti i valori di margin il seguente: TOP, RIGHT, BOTTOM, LEFT.
In pratica, bisogna seguire, a partire dall'alto un senso orario. Nel nostrio caso, la sezione menu sar
praticamente unita alla testata (top = 0px), avr un margine di 26px a destra e di un solo pixel in basso. E a
sinistra? Bene, nei CSS esistono delle semplici regole per evitare la replica dei valori. Quando manca il
valore per il lato sinistro (dovrebbe essere il quarto), esso sar uguale a quello del lato destro (il secondo).
Quindi, il margine sinistro di 26px.

Contenuto
Il box #contenuto una sorta di scatola vuota che serve semplicemente a delimitare la sezione centrale e a
stabilirne le misure di base. La larghezza e i margini sono identici a quelli della sezione #menu. La sua utilit
consiste anche nel facilitare la gestione dei due box che contiene.

Navigazione
A parte i bordi, il colore di fondo e il padding, il menu di navigazione a sinistra ha due propriet importanti
che influenzano il layout generale della pagina.
La prima la dichiarazione float: left; . Per capire la propriet float dovete pensare al modo usato in HTML
per far scorrere il testo attorno ad un'immagine. Se si usa l'attributo <img align="left"> l'immagine rimane a
sinistra e il testo scorre intorno alla sua destra (figura 3). Allo stesso modo, definendo per l'id #navigazione
float: left; facciamo in modo che esso rimanga a sinistra e che gli altri elementi adiacenti vengano spostati
alla sua destra, ma non su una riga diversa, cosa che avviene per il box #post. Ecco cosa accade se
eliminiamo l'istruzione (figura 4).
La seconda propriet importante la larghezza, che uguale a 140px. Rimane la questione dell'altezza. Vi
renderete conto che se non si specifica nessun valore, essa sar basata sul contenuto. Se volete un'altezza
fissa, usate height come per la testata.

Post
Siamo alla fine. L'id #post ha una larghezza di 350px ed posizionato alla destra di #navigazione. Ma dove
va posizionato precisamente? Qui entra in gioco il margine sinistro. Esso ha come valore 142px (margin :
0px 0px 0px 142px;), calcolati a partire dall'elemento parente (l'id #contenuto). Non casuale. Se avessimo
settato una distanza minore esso si sarebbe sovrapposto a #navigazione. Infatti, i 142px non sono altro che
uguali alla larghezza di #navigazione + 2 pixel. L'immagine potr chiarirvi questi particolari che possono
sembrare un p astrusi.
Bene. Il consiglio a questo punto quello di sbizzarrirvi. Giocate un p con il foglio di stile. Cambiate colori,
margini, bordi, font. Capirete che la creativit si esprime proprio nei CSS, mentre il documento XHTML
rimane intatto nella sua struttura.

Ora per dobbiamo riempire X-blog con i nostri post. E' il momento di pensare ai contenuti.

I contenuti: i post del Blog


Nelle lezioni precedenti abbiamo evidenziato soprattutto una delle caratteristiche di XML: il suo rigore.
Correttezza formale e validit rispondono all'esigenza di avere un markup finalmente pulito e controllato.
Ora, affronteremo un'altra importante dimensione di questo linguaggio.

Gestione dei contenuti con XML


XML una sorta di lingua franca. Non ha nulla dei linguaggi proprietari. Un documento XML
semplicemente un file di testo e come tale leggibile su qualunque macchina. Si capisce, dunque, come si
riveli uno strumento potentissimo in applicazioni centrate sullo scambio di informazioni e sulla distribuzione
di contenuti su vari supporti. Inoltre, grazie alla possibilit di creare tag personalizzati, i documenti sono
autoesplicativi. Ogni tag mi dice esattamente la funzione che svolge e il tipo di dati che definisce. La lettura
di un buon manuale o del corso XML di HTML.it potr chiarire questo e altri aspetti. Ora passiamo alla
pratica e torniamo al nostro blog.
I dati che intendiamo conservare in XML sono i post che quotidianamente arricchiscono la nostra cronaca
digitale. Il motivo fondamentale per cui operiamo questa scelta semplice: vogliamo tenere i contenuti
separati dal resto. In questo modo, le operazioni di aggiornamento e archiviazione dei post saranno
estremamente semplificate e volendo potremmo facilmente distribuirli su sistemi alternativi.
La struttura tipo di un post per X-blog molto semplice. Ciascuno di essi avr:
1. un titolo
2. la data di invio
3. un testo
4. eventuali link nel testo
Nel file "blog.html" (listato 3) abbiamo visto come questo schema si traduce in una struttura:

Sezione dei post


<div id="post">
<h2>08/03/2002</h2>
<h1>Titolo 1</h1>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed
diam nonummy
nibh euismod tincidunt ut laoreet dolore magna aliquam erat
volutpat.....</p>
Nel listato 6, invece, abbiamo riportato il codice del documento base di X-blog. Copiate, incollate e salvate
come "news.xml". Aprendo il file con Internet Explorer apprezzerete al meglio la struttura ad albero del
documento, con i singoli nodi strutturali contenuti all'interno dell'elemento radice. Qualche nota di commento:
1. il documento inizia con la dichiarazione XML
2. la seconda dichiarazione serve a incorporare un foglio di stile XSL (ne parleremo pi avanti)
3. l'elemento radice <news> che racchiude tutti i post
4. il tag <post> definisce un singolo aggiornamento del blog
5. <post> ha tre elementi figlio: <titolo>, <data>, <testo>
6. all'interno dell'elemento <testo> possibile avere un altro nodo, <link> (per collegamenti a siti
esterni citati nel testo)

Presentare XML
Come evidente, il documento "news.xml" non contiene alcuna informazione su come verr presentato. Non
una limitazione. E' cos che deve essere. Per effettuare la formattazione di un documento XML in vista
della sua presentazione si possono seguire due metodi.
Il primo non vi risulter nuovo: si usano i CSS. Applicare un foglio di stile CSS ad un documento XML
infatti semplicissimo. Supponiamo di voler collegare a "news.xml" il foglio di stile "news.css". Dovremo
aggiungere, subito dopo la dichiarazione XML, quest'istruzione:
<?xml version="1.0" ?>
<?xml-stylesheet type="text/css" href="news.css" ?>
Il secondo metodo quello che andremo ad analizzare nei dettagli nelle prossime due lezioni. E' basato su
XSL (Extensible Stylesheet Language), un linguaggio ben pi potente dei semplici CSS in grado di
trasformare qualunque documento XML in vari formati: testo semplice, HTML, XHTML, persino PDF.
Finalmente capirete come "blog.html" sia generato automaticamente.

Trasformare XML: introduzione a XSL


XSL certamente uno dei pi importanti linguaggi standard del W3C. Esso risulta composto di tre parti,
ciascuna delle quali rientra nella specifica XSL 1.0, pubblicata nell'ottobre 2001:
1. XSLT: un linguaggio che consente di trasformare documenti XML in altri formati (vedi la Guida a
XSLT di HTML.it)
2. Xpath: definisce espressioni e metodi per accedere ai nodi di un documento XML
3. XSL FO (Formatting object): usato per formattare in maniera precisa un oggetto trasformato
Per il nostro tutorial si far riferimento solo a XSLT e Xpath.

Cosa fa un foglio XSL


Un foglio di stile XSLT un documento XML valido e ben formato. Fornisce un meccanismo per trasformare
un documento XML in un altro. Dal punto di vista del web design e per la nostra applicazione la
trasformazione che ci interessa quella da XML in XHTML.
Una trasformazione pu essere cos schematizzata:

Dato un documento XML d'origine e un foglio XSLT ad esso associato, un processore XSL produrr un terzo
documento. In quest'ultimo, i contenuti saranno presi dal primo documento, la struttura e le regole di
presentazione dal secondo.

CSS e XSL
La parola "stylesheet" contenuta nel nome XSL pu far pensare a una parentela con i CSS. In realt questi
due linguaggi sono molto diversi. Ci che va per spiegato che essi non sono da considerare alternativi,
ma complementari. E come tali li useremo in X-blog. Vediamo comunque le principali differenze.

Innanzitutto, XSL di gran lunga pi potente. Un foglio di stile CSS, infatti, pu contenere principalmente le
regole che definiscono lo stile dei vari elementi di una pagina. Come abbiamo visto, anche possibile
stabilire importanti caratteristiche del layout, come posizione e dimensioni, ma tutte le regole devono
poggiare su una struttura definita altrove (in genere in un documento XHTML).
XSL va molto oltre. Pu generare esso stesso lo stile di presentazione, ma pu anche:

aggiungere nuovi elementi alla struttura

creare nuovi contenuti

filtrare e ordinare dati

generare documenti con diversi gradi di compatibilit

usare complesse espressioni condizionali

Insomma, si pu intuire che si tratta di operazioni che sono tipiche pi di linguaggi come ASP che di CSS.

Applicare un foglio XSL


Affrontiamo ora una questione cruciale. L'applicazione di un foglio XSL a un documento XML in realt
molto semplice. La sintassi simile a quella vista nella lezione precedente per i CSS:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="news.xsl"?>
La cosa complicata il supporto dei browser. Diciamolo subito: l'unico che garantisce un supporto ottimale
Explorer 6 . Questo grazie alla presenza del parser MSXML 3.0, che ha notevolmente migliorato il gi
discreto supporto della precedente versione 2.6. Il mancato supporto dei browser fa s che l'applicazione di
fogli XSL nel modo visto in precedenza (con elaborazione sul lato client) sia oggi quasi impraticabile. Non
mancano comunque esempi di siti interamente realizzati con XML+XSL. Se avete Explorer 6 potrete farvi
un'idea precisa visitando l'eccellente XML/XSL Portal. Provate a visitarlo con qualunque altro browser per
apprezzare le differenze.

Riferimenti
Questa una guida a XHTML, pertanto non qui possibile fornire approfondimenti su XSL. I riferimenti
proposti sono ottimi punti di partenza per iniziare ad orientarsi tra le principali regole del linguaggio.
XSL sul W3C: da qui potete accedere a tutte le risorse del Consortium sul linguaggio, comprese le
specifiche ufficiali.
XSL School: dal sito W3Schools un eccellente tutorial introduttivo.
XSL e CSS: ottimo tutorial sulla formattazione di documenti XML con fogli di stile CSS o XSL.
XSLT.com: portale su XSL con tutorial e link a risorse sul web.
XSL Info: altro portale ricco di risorse e informazioni sul linguaggio, compresa una sezione su parser e tool di
sviluppo.

Trasformare XML: come lavora XSL


In questa lezione vedremo quali sono le fondamentali regole di funzionamento di un foglio XSLT. Nella
prossima, dove analizzeremo il foglio definito per X-blog, scenderemo maggiormente nei dettagli:
affrontando un caso concreto: faremo una specie di anatomia di un documento XSL.

Struttura di base
Un foglio di stile XSLT un documento XML, pertanto sottoposto alle stesse regole sintattiche: deve
essere insomma un documento valido. La struttura minima contiene due parti:

il prologo

l'elemento radice

Nel prologo si specifica in genere solo la dichiarazione XML:


<?xml version="1.0">
Per essa valgono le stesse regole gi viste per XHTML.
Subito dopo il prologo necessario dichiarare l'elemento radice. In un documento XSL l'elemento radice
<xsl:stylesheet>. Esso deve contenere un attributo che definisca la versione del linguaggio e almeno una
dichiarazione di namespace. Quest'ultima ha come valore: "http://www.w3.org/1999/XSL/Transform".
La struttura di base di un foglio XSLT si presenta dunque cos:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
....................................
</xsl:stylesheet>
Tra il tag di apertura e quello di chiusura dell'elemento radice vanno definite tutte le regole di trasformazione.

Scegliere il metodo di output


Prima della definizione delle regole di trasformazione possibile specificare il formato del documento finale.
Ci avviene tramite la dichiarazione <xsl:output>. All'interno di tale dichiarazione si possono specificare vari
attributi. Il pi importante certamente method, con cui si pu impostare il formato di output scegliendo tra
xml, html e text:
<xsl:output method="html"/>
Altri attributi consentono di definire il DOCTYPE con la relativa DTD, la dichirazione XML, la scelta della
codifica dei caratteri. Ne vedremo un esempio concreto nella nostra applicazione.

Regole e templates
Un foglio di stile XSLT vede un documento XML come un albero fatto di nodi. Torniamo al file "news.xml"
(listato 6). Nella figura 1 abbiamo evidenziato graficamente la sua struttura:

<news> l'elemento radice; <post> un suo elemento figlio. <data>, <titolo> e <testo> sono sullo steso
livello, ma tutti sono figli di <post>. L'elemento <link> un nodo figlio di <testo>. Esso ha anche un attributo:
href.
Un processore XSLT pu trattare sette tipi di nodi presenti in un documento XML:

l'elemento radice

gli attributi e i loro valori

i commenti

gli elementi

i namespace

le istruzioni di elaborazione

il testo contenuto in un nodo

Ora, in un foglio XSLT necessario specificare delle regole per trasformare i singoli nodi. Ogni regola viene
definita in un template. Quando si crea un template come se si dicesse: caro processore XSL, quando
incontri il nodo x esegui questa trasformazione. Esempio. Supponiamo di voler trasformare "news.xml" in
XHTML e che l'elemento <testo> con il suo contenuto debba essere racchiuso in un paragrafo. In XSL
creeremo questo template:
<xsl:template match="post">
<p><xsl:value-of select="testo"/></p>
</xsl:template>
Il processore percorrer tutto l'albero del documento. Quando incontrer l'elemento <post>, verificher che
<testo> sia presente come elemento figlio, trasformer il testo in un paragrafo.

Rintracciare i nodi
Per individuare i singoli nodi si ricorre alla sintassi Xpath. Per capire come funziona Xpath si pu fare
riferimento al modo in cui si individuano file e cartelle in un file-system. Se scrivo: C:\documenti\ritratto.jpg
significa che individuo:

un elemento radice (C:\)

una cartella al suo interno

un file all'interno della cartella

Se volessi specificare il path per l'elemento <testo> del file news.xml scriverei cos in Xpath:
<xsl:template match="news/post/testo">
La sintassi Xpath notevolmente pi complessa e se ben usata consente di individuare e trasformare ogni
aspetto di documenti XML, anche molto complessi.

Elementi principali
Elenchiamo ora alcuni dei pi importanti tag XSLT specificando per ciascuno la funzione. E' solo un breve
elenco, ma potr darvi un'idea delle potenzialit di questo linguaggio. Per approfondimenti vi rimandiamo alla
sezione "Riferimenti" della lezione precedente, mentre per un uso concreto di alcuni di essi, vi aspetta la
prossima lezione.

xsl:apply-templates

Applica le regole definite in


un tamplate.

xsl:attribute

Crea un attributo per un


elemento.

xsl:comment

Genera un commento nel


documento finale

xsl:element

Crea un nuovo elemento

xsl:for-each

Stabilisce una struttura


ciclica ripetendo un template
tutte le volte che un dato
nodo viene incontrato.

xsl:if

Usato per impostare semplici


strutture condizionali.

xsl:include

Include un foglio XSL


esterno

xsl:sort

Ordina un insieme di nodi in


bse ai parametri forniti.

xsl:stylesheet

Elemento radice di un
documento XSL

xsl:template

Genera un template.

xsl:text

Genera nuovo testo nel


documento di output

xsl:value-of

Restituisce il valore di un
elemento o di un attributo.

xsl:when

Usato per espressioni


condizionali complesse
Per maggiori informazioni su XSLT rimandiamo alla Guida a XSLT pubblicata su HTML.it.

XSL al lavoro
In questa lezione analizzeremo e spiegheremo nei dettagli il foglio di stile "xstyle.xsl" con cui trasfomeremo
in formato XHTML il documento "news.xml".
Iniziamo subito con una semplice prova. Nel listato 7 (ma lo trovate anche nel file dei materiali) riportiamo il
codice del foglio XSL. Copiate, incollate nel Blocco Note e salvate come "xstyle.xsl". Riprendete ora il file
"news.xml", apritelo, se il vostro browser, con Explorer 6. Quello che vedrete esattamente identico al
documento "blog.html" creato nel corso della lezione 21 (a parte il testo delle news). La differenza? Il
secondo documento frutto di una trasformazione XSL, il primo statico.

Analisi di xstyle.xsl
Dichiarazioni preliminari

Per prima cosa inseriamo la dichiarazione XML con l'attributo version. Subito dopo inseriamo l'elemento
radice <xsl:stylesheet>. Anche qui specifichiamo la versione. Segue la dichiarazione dei namespace. Il
primo fa riferimento a XSL , il secondo a XHTML. Significa che nel documento i tag senza prefisso vanno
interpretati come XHTML, quelli con il prefisso come XSL.

Output del documento

Con la dichiarazione <xsl:output> specifichiamo che il documento finale dovr essere di tipo HTML e che il
codice verr indentato. Dal momento che vogliamo produrre un documento XHTML valido, necessario
definire un DOCTYPE con FPI e URI della DTD (vedi lezione 5). Scegliamo la DTD Strict.

Template del nodo radice

Stabiliamo un template per l'elemento radice. In Xpath esso viene indicato con la slash ( / ). Questa
dichiarazione in genere la prima regola da stabilire. In questo modo il processore XSL applicher le
trasformazioni sotto specificate a partire dal primo elemento, quindi a tutto il documento.

La parte statica del documento

Ritorniamo alla struttura di X-blog. Come ricorderete, esso avr una parte statica (testata, menu, barra di
navigazione laterale) e una da aggiornare (quella con i post). La parte statica la riprendiamo cos com' dal
documento "blog.html". Ora capite la potenza di XSL. Di questa parte non vi traccia in "news.xml", l

abbiamo solo i post. Ma con un foglio XSL noi la possiamo creare da zero. Notate anche che abbiamo
incorporato il CSS "mainstyle.css": come vedete XSL e CSS fanno cose diverse, sono complementari.

Gestione dei post

Finora niente di particolare, direte. Abbiamo semplicemente creato una parte della nostra pagina usando
puro XHTML. Ora viene il bello. Siamo infatti arrivati alla sezione dei post contenuti nel documento XML.
Notate innanzitutto che tutto avviene all'interno del <div> che definisce la sezione.
Con la prima dichiarazione, <xsl:for-each select="news/post">, diciamo: applica le regole definite qui sotto
ogni volta che incontri un elemento <post>. Chi ha un p di dimestichezza con ASP capir subito che un
meccanismo simile a quello usato per visualizzare i dati di un database con le espressioni do while e loop.
Oppure all struttura ciclica di VB Script con For Each...Next.
Subito dopo (<xsl:sort.../>) specifichiamo che i post vanno ordinati in ordine discendente in base al valore
dell'elemento <data>, che di tipo testo. Dunque, consigliabile, nella gestione dei post, usare sempre le
due cifre per il giorno (01, 02, 03, etc).
A questo punto, con la dichiarazione <xsl:value-of>, inseriamo nel documento di output i valori degli elementi
<titolo> e <data>. Il primo sar racchiuso in un tag <h1>, il secondo in un <h2>.
Con l'ultima dichiarazione stabiliamo che il contenuto dell'elemento <testo> sar racchiuso in un paragrafo.
In questo caso applichiamo le regole di trasformazione sono state definite in un template separato che
esamineremo tra poco.

Chiusura del documento XHTML

In questa sezione chiudiamo il documento XHTML e il tamplate per il nodo radice definito all'inizio.

Gestione dei link

All'interno del testo dei post possiamo anche inserire dei link e abbiamo visto come ci si definisce in
"news.xml" (listato 6). Alla fine del documento XHTML, dobbiamo creare un template per la gestione di
questo elemento. Con l'attributo match stabiliamo che le regole vanno applicate ogni volta che il processore
incontra <link>. Ma cosa deve fare? Un link in XHTML definito dal tag <a> e dall'attributo href che contiene
l'URL del file da visualizzare. Quindi: ogni volta che incontra <link> il processore dovr creare un elemento
<a> (<xsl:element name="a">) con un attributo href (<xsl:attribute name="href">) prima del testo contenuto
da <link>. Il valore di href inserito con <xsl:value-of>. La chiocciola indica che il valore preso da
un'attributo e non da un elemento (figura 8):

Chiudono i tag di chiusura ben annidati.

Fine del documento

Alla fine del documento troviamo il tag di chiusura dell'elemento radice.


Fatto. Per vostra comodit abbiamo inserito una versione commentata del foglio di stile che sintetizza le
osservazioni di questa lezione (listato 8).
A questo punto, se tutti i browser funzionassero come Explorer 6, avremmo finito. Basterebbe aprire nel
browser, come nella prova fatta all'inizio, "news.xml". Ma purtroppo cos non . Dobbiamo effettuare le
trasformazione sul server. E' il momento di usare ASP.

Il ruolo di ASP
Il ruolo di ASP nella nostra applicazione dovrebbe ormai essere chiaro. Grazie a questa tecnologia, facciamo
in modo che la trasformazione e la gestione dei documenti XML avvenga sul server. Il file ASP da usare,
come vedrete, dei pi semplici. Prima per diamo qualche indicazione sui requisiti software per poter
implementare il sistema.

Requisiti software
Se provate il sistema in locale avete bisogno di un server web con supporto ASP. In ambiente Windows, la
scelta si restringe a Personal Web Server (Windows 95 - 98 - Millennium) o IIS (Windows 2000). In entrambi
i casi dovrete settare una directory virtuale che ospiti tutti i file.
Un requisito fondamentale la presenza sul vostro sistema di un parser XML in grado di gestire le
trasformazioni XSL. Sin dai tempi di Exlorer 4, Microsoft distribuisce un parser con le sue principali
applicazioni. La prima versione che garantisce il supporto delle specifiche XSL del W3C per la 3.0. Essa
va installata in modalit REPLACE. In pratica, deve rimpiazzare le precedenti versioni del parser e diventare
quella di default del sistema. Per ottenere questo risultato avete due sistemi a disposizione:
1. installare Internet Explorer 6
2. scaricare e installare dal sito Microsoft il pacchetto MSXML 3.0 SP2 (clicca qui per andare alla
pagina di download)
Al momento della pubblicazione dovrete ovviamente verificare che il vostro server abbia queste
caratteristiche.

Il file "default.asp"
Il listato 9 riporta il codice commentato del file "default.asp". Come vedete molto semplice. Carica in
memoria il documento XML, il documento XSL e restituisce il risultato della trasformazione. Vi consiglio di
imparare queste poche righe di codice. Sono il metodo pi semplice per caricare un documento XML sul lato
server.
Ora, supponendo che abbiate una directory virtuale "blog", potete aprire il documento usando l'URL:
http://nome_del_server/blog/default.asp, oppure
http://127.0.0.1/blog/default.asp

Gestione del Blog


Siamo alla fine del nostro percorso. Abbiamo creato il blog, ora bisogna imparare a gestirlo. Il fatto di aver
tenuto separati i contenuti dagli elementi strutturali e di presentazione ci render la vita molto facile.
La pi comune operazione l'inserimento di nuovi post. Il metodo pi semplice quello di aggiungere
manualmente i post in una copia locale del file "news.xml" e di inviare la copia aggiornata sul server con ftp o
sistemi simili. Non manca la possibilit di creare un'interfaccia di amministrazione via web, come si fa con i
database. Sar magari l'argomento di un prossimo articolo.
Se avete intenzione di cambiare gli aspetti tipografici e del layout dovrete invece intervenire sul file
"mainstyle.css", senza toccare altro.
Un'ultima possibilit che vogliate intervenire sulla struttura del documento, magari per inserire nuovi
elementi nel menu di navigazione o per cambiare quelli esistenti. Visto che la pagina principale di X-blog
generata da un foglio XSLT, dovrete modificare il documento "xstyle.xsl".

Risorse XHTML e XML sul web


In questa sezione della guida forniamo utili riferimenti su XML e XHTML. E' un universo in continua
evoluzione, che cambier sicuramente il modo di lavorare di chi opera sul Web. La nostra speranza quella
di aver stimolato la vostra curiosit.

XHTML
XHTML sul W3C: sito di riferimento per novit, specifiche, aggiornamenti.
XHTML Guru: contiene introduzioni alle varie versioni del linguaggio, una sezione di link e libri, una piccola
raccolta di FAQ.
XHTML School: un buon tutorial introduttivo e un'eccellente reference sul sito di W3Schools
Startkabel: mini-portale con link ad articoli e risorse
XHTML.org: pagina con news e riferimenti su XHTML, comprese mailing-list e newsgroup sull'argomento.
Ottimi articoli su XHTML si trovano anche nei pi importanti siti di web-design e nei siti su XML riportati qui
sotto.

XML
XML sul W3C: la voce del Consortium
XML Directory: raccolta di link e risorse
XML School: tutorial ed esempi da W3Schools
XML.com: il sito su XML legato alla casa editrice O'Reilly&Associates. Una garanzia di eccellenza.
XML Pitstop: sito ricchissimo sotto ogni aspetto. Incomparabile la raccolta di modelli di fogli XSLT.
XML/XSL Portal: non solo interamente costruito in XML e XSL, ma fornisce una serie incredibile di trucchi
e risorse.
Perfect XML: ottimo e ricco. La cosa migliore la raccolta di capitoli di esempio tratti dai migliori manuali sui
linguaggi legati a XML.

Libri su XHTML
I riferimenti sono ai libri ritenuti pi validi dall'autore di questa guida.

In italiano
Tra i libri in italiano o tradotti in italiano su XHTML solo uno davvero eccellente:
Molly E. Holzschlag, XML, HTML, XHTML Magic, Addison Wesley, 2002
Un ottima sezione su XHTML si trova anche nel manualone di Steven Holzner su XML:
Steven Holzner, XML Tutto & Oltre, Apogeo, 2001

In inglese
Steven Holzner, XHTML Black Book, Coriolis Group, 2000
AA.VV, Beginning XHTML, Wrox Press, 2000

Chuck Musciano & Bill Kennedy, HTML & XHTML : The Definitive Guide, O'Really, 2000
Michael Morrison & Dick Oliver, Sams Teach Yourself HTML and XHTML in 24 Hours, Sams, 2001
Altri volumi li potete trovare nella sezione libri di HTML.it.