Andrea Gandino

Pensieri sparsi sulle letture che ho avuto modo di effettuare in questi giorni. Premetto che innanzitutto mi sono reso conto come fossi (sono) drammaticamente poco ferrato sulla materia; fortunatamente, con un po’ di pazienza, è possibile aggiornarsi e recuperare lo svantaggio.

La seconda premessa è che le mie conoscenze a proposito degli argomenti trattati qui sotto sono più che mai in evoluzione, dunque correzioni, obiezioni, critiche e quant’altro sono più che mai accettate e incoraggiate.

In questi giorni, dicevo, ho letto parecchio materiale riguardo alla questione, in sé piuttosto datata, riguardante la scelta tra XHTML e HTML.

Mi rendo conto che, in passato, sono caduto anch’io in uno degli errori più comuni che si possono fare, ovvero usare XHTML soltanto perché è percepito come la novità, o come la cosa di moda. In realtà, dopo aver indagato più a fondo, sono giunto alla conclusione, diametralmente opposta alle mie idee di non più di un paio di mesi fa, che usare HTML4 è una scelta tanto rispettabile quanto quella di usare XHTML, e che non vi sono vere e proprie ragioni per cui il secondo debba essere preferito al primo, o comunque possa dirsi oggettivamente migliore.

L’inghippo è sostanzialmente uno: l’XHTML che usiamo ogni giorno non è trattato come XML. Per fare in modo che l’XHTML sia effettivamente gestito dai browser come tale, dovremmo infatti assicurarci che il nostro documento sia inviato come un tipo MIME che faccia effettivamente parte della “famiglia” di XML, ovvero application/xhtml+xml.

Normalmente, però, quando scriviamo un documento in XHTML, esso è gestito dal server come normalissimo text/html, di fatto eliminando gran parte (se non la totalità) dei vantaggi dell’usare XHTML: se non serviamo XHTML come application/xhtml+xml l’unico effetto che otteniamo è che il nostro documento è trattato come se fosse HTML e nulla più.

Potremmo dunque chiederci cosa ci trattenga dall’usare application/xhtml+xml su base quotidiana. La risposta è che non tutti gli User Agent sono in grado di leggere correttamente tale tipo MIME, uno su tutti l’amato (da pochi)/odiato (da molti) Internet Explorer 6 (Si veda questa tabella per una comparazione tra i vari browser oggi disponibili).

Quindi diciamo che gli scogli da superare se volessimo utilizzare detto tipo MIME sono due:

1. Le impostazioni dei server, dal momento che trattano automaticamente i file .html come text/html, sostanzialmente fregandosene del DOCTYPE da noi impostato.

2. Lo scarso supporto di application/xhtml+xml da parte degli user agent. Qui ci possiamo fare relativamente poco, anche se esistono dei modi, un po’ tortuosi forse, per far digerire application/xhtml+xml anche a IE.

Per quel che concerne il primo punto, possiamo pensare di gestire la cosa in due modi. Dal momento che gli header HTTP hanno priorità più elevata rispetto alle indicazioni fornite dal documento nell’apposito elemento meta, possiamo intervenire modificando tali header con i metodi già conosciuti e forniti da linguaggi di programmazione quale ad esempio PHP, oppure divertendoci con il file .htaccess.

Con i linguaggi di programmazione come PHP, inoltre, è possibile tentare anche un abbozzo di browser sniffing, andando a controllare l’esistenza di $_SERVER["HTTP_ACCEPT"], un header inviato dai browser che può contenere la stringa application/xhtml+xml, cosa che permette dunque il riconoscimento automatico degli user agent che supportano XHTML mediante un semplicissimo controllo if.

Utilizzare XHTML secondo le modalità con cui è stato realmente concepito ci porta in un mondo tutto nuovo, in cui l’essere well-formed è una caratteristica essenziale, non più solo un valore aggiunto, o comunque qualcosa che, qualora mancasse, non comprometterebbe la visualizzazione della nostra pagina.

Il discorso che faccio è iper-semplificato, anche e soprattutto per le lacune del sottoscritto a riguardo, ma in pratica, se si utilizza un parser XML al posto del solito parser HTML, ci si avvicina molto di più alla situazione che si ha in programmazione, nella quale un singolo errore causa il blocco dell’intero programma. Similmente, un errore nella well-formedness del documento, causerebbe una schermata di errore, impedendo drasticamente la visualizzazione della pagina intera.

Ad oggi tutti i browser implementano vari sistemi di correzione degli errori, in modo che, anche in presenza di imperfezioni nel markup, la pagina venga sempre caricata e mostrata all’utente.

Naturalmente il dibattito è tra chi è un sostenitore della rigidità anche nei linguaggi di marcatura adoperati sul Web, e chi invece reputa giusto l’inserimento di meccanismi per la correzione degli errori. Se è vero che la prima ipotesi sensibilizzerebbe gli autori/sviluppatori a scrivere codice valido e ben formato (che sono due cose diverse, non necessariamente sovrapponibili), è anche vero che non è pensabile stampare solo un messaggio di errore in presenza di una pagina che non sia conforme a XML, dal momento che la stragrande maggioranza delle pagine Internet non lo sono.

Comunque, questo è un altro argomento. La scelta del tipo MIME con cui i nostri documenti XHTML sono inviati appartiene solo a noi. Nella maggior parte dei casi non vi sono veri e propri vantaggi nell’inviare XHTML come application/xhtml+xml, per le ragioni illustrate precedentemente.

Inoltre, le differenze tra HTML e XHTML non finiscono qui, e toccano anche altri aspetti della programmazione per il web, come ad esempio le funzioni Javascript del DOM: non è possibile usare la funzione, molto diffusa, document.write (sostituita da document.createElementNS), funzioni di uso comune come getElementsByTagName potrebbero non dare i risultati che si aspetta, dal momento che XHTML è case-sensitive, al contrario di HTML, giusto per citare quelle più immediate.

Riassunto di tutta la sbrodolata di informazioni di cui sopra: si può usare XHTML, ma bisogna però tener presente che, quando scriviamo un documento con quel DOCTYPE, in realtà esso sarà letto come un comune documento HTML.

Ma allora, se nella maggior parte dei casi usare XHTML ha lo stesso valore che usare HTML, com’è possibile scegliere tra i due? E ancora, come mai si dovrebbe preferire il primo, quand’è chiaro che lo si utilizzerebbe in un modo per il quale non è stato progettato?

Personalmente ritengo che XHTML sia più chiaro e meno confusionario rispetto ad HTML, e aiuti lo sviluppatore a scrivere codice migliore, anche sotto un punto di vista di organizzazione dei contenuti, non solo dal punto di vista “estetico”.

Inoltre lo sviluppo che è in atto con XHTML2 mi sembra molto più sensato, rispetto al lavoro portato sinora avanti dal WHATWG.

Tuttavia, ed è qui che arrivano i veri dolori, il W3C dice che XHTML2 non dovrà essere inviato come text/html, ma solo come application/xhtml+xml. Se è vero che per arrivare a XHTML2, posto che effettivamente ci si arrivi, passeranno parecchi anni, è anche vero che se i browser non saranno pronti a gestire il tipo MIME application/xhtml+xml saremo di nuovo al punto di partenza: una tecnologia buona, ma scarsamente supportata favorirà l’utilizzo di un’altra, a mio modo di vedere inferiore, ma universalmente accettata.