E se qualcuno dicesse che i tuoi documenti XHTML non sono altro che HTML non valido?
Se sei uno sviluppatore web, avrai sicuramente sentito parlare di XHTML, la “nuova” versione di HTML.
E avrai sicuramente assistito a questa corsa agli standard: i sintomi sono piccoli badges in fondo ai siti di tutte le fogge e le dimensioni, che recano scritte del tipo “XHTML VALID”, “I LOVE VALIDATOR”, “XHTML IS MY LIFE” insomma tutto un genere di frasi sdolcinate che si dovrebbero dedicare alla propria ragazza e non ad un linguaggio di markup!
E se qualcuno un giorno ti dicesse che tutti i tuoi documenti XHTML non sono altro che HTML non valido?
Tutta una questione di content type
Infatti sotto l’aspetto tecnico è proprio così. Per spiegare il motivo di questo “raggiro”, bisogna considerare in che modo i browser distinguono i vari tipi di file che prelevano dai siti web.
Ogni volta che un file viene scaricato, ad esso viene allegato una descrizione, detta “content type“, la quale specifica di che tipo di file si tratta: per una foto in formato “jpg” sarà "image/jpg", per un file in formato “css” sarà "text/css" e così via. Il content type per i documenti XHTML è "application/xhtml+xml", che viene assegnato ai file con estensione .xhtml, mentre per i file .html il content type è "text/html"
Dunque tutti i documenti scritti seguendo le specifiche XHTML, ma salvati con estensione .html vengono automaticamente interpretati dai server come file HTML e dunque visualizzati come tali.
La ragione principale per usare un content type diverso è che XHTML è un derivato di XML, e quindi è soggetto ad una gestione degli errori molto più rigida, garantendo una maggiore qualità dei documenti: è ragionevole allora indicare la differenza ai browser. Inoltre, XHTML presenta alcune differenze di sintassi con HTML, una su tutte il fatto che i tag vuoti come <br> devono essere obbligatoriamente chiusi aggiungendo uno slash alla fine <br/>.
Chi ha ucciso Mr. X?
Purtroppo molti browser (ad esempio Internet Explorer fino alla versione 8 ) non sono ancora in grado di rendere i file XHTML con il giusto content type, e dunque lo trasformano in “vecchio” HTML non valido perché contiene degli elementi che non fanno parte di questa specifica come abbiamo detto prima, ma dato che il parser HTML non è progettato per arrestarsi in presenza di un errore, rende la pagina come dovuto.
Il momento che attendevi: l’esempio!
Lasciamo stare per un attimo tutti questi paroloni che tanto piacciono ai tecnici: un esempio vale più di mille parole:
Nota: se non abbiamo installato Firefox 3 è il momento giusto per farlo.
- Creiamo un file con il nostro editor preferito e chiamiamolo
standard.html. - Duplichiamo questo file, rinominandolo
standard.xhtml. - Inseriamo in entrambi i file il codice seguente, in cui includiamo volontariamente un errore di distrazione che potrebbe capitare a chiunque, ovvero dimenticare di chiudere un tag, in questo caso abbiamo dimenticato di chiudure il tag html alla fine del documento.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="it" xml:lang="it"> <head> <title>Il mio documento standard</title> </head> <body> <h1>I LOVE XHTML</h1> <ul> <li>Un elemento della mia lista standard</li> <li>Idem come sopra</li> </ul> <p>Il mio paragrafo standard</p> </body> </html
Sei pronto? Visualizza entrambi i file in Firefox, ed osserva come si comporta il browser. Nel caso del file con estensione html la pagina verrà visualizzata in tutta la sua standard bellezza:
mentre nel caso dell’xhtml ti sarai trovato di fronte ad un messaggio d’errore non molto rassicurante:
HTML è morto…evviva HTML!
Gli autori che intendono rendere pubblico il loro lavoro dovrebbero continuare ad usare HTML 4.01 – Ian Hickson (membro del W3C ed editor per HTML5)
Dunque non ha nessun senso utilizzare XHTML e servirlo come text/html, perché il nostro codice, verrà trattato come HTML non valido. Molti sviluppatori hanno promosso tecniche (come la Content Negotiation) per servire il giusto content type ai browser che lo supportano, ma quest’ultime si basano su caratteristiche particolari dei browser che in futuro potrebbero cambiare, e quindi non è affatto il giusto approccio al problema.
In più, se anche fosse possibile utilizzare XHTML correttamente, sarebbe molto complicato, per un aspirante sviluppatore, accettare contenuto da parte degli utenti (ad esempio dei commenti in un blog), poichè ogni piccolo errore di sintassi rischierebbe di compromettere l’accessibilità dell’intero sito.
Quindi, dopo l’ondata di entusiasmo provocata da XHTML, molte voci autorevoli, stanno facendo un passo indietro, nell’attesa di un maggior supporto da parte dei browser, o del termine dello sviluppo della nuova versione di HTML.
In conclusione
- Se non si hanno delle buone motivazioni per servire le pagine in XHTML, ad esempio per documenti sviluppati in MathML (un linguaggio per formule matematiche) o SVG (un linguaggio per la gestione di immagini), sarebbe meglio utilizzare il Doctype 4.01 Strict per i propri documenti; sarebbe valido e non meno standard della sua versione XHTML:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> - Se si volesse comunque provare a servire il giusto content type ai browser che lo supportano, si potrebbe provare ad usare la Content Negotiation, ma questo implicherebbe l’uso di tecnologie lato server, o la modifica di alcune impostazioni del server, operazione non molto semplice, senza tuttavia apportare alcun beneficio di XML ai nostri siti.
- C’è una terza via, che sarebbe quella di utilizzare il doctype di HTML5, per cominciare a prendere confidenza con questo nuovo strumento. Faccio notare che questo dovrebbe essere fatto solo per siti personali o sperimentali, in quanto il supporto non è per nulla garantito dai vari browser. Approfondiremo il discorso in una serie di articoli dedicati proprio ad HTML5 ed alla ventata di novità che porterà con sè.
L'autore
Articoli correlati
Potresti essere interessato anche ai seguenti articoli:
15 commenti
Trackback e pingback
-
Conosci questi modi di utilizzo del selettori css? | Your Inspiration Web
[...] avrai notato se hai avuto modo di leggere i miei precedenti articoli, preferisco gli esempi pratici alla teoria, li ...
Grande articolo e complimenti ;)
Ciao Just, complimenti per l’articolo, era un argomento che ignoravo.
Se ho ben capito quindi tutti i siti anche se sono validati per xhtml vengono visualizzati dai browser in html? E che senso ha allora validarli per xhtml?
Hai ragione quando dici che i browser ma anche i server si comportano diversamente in funzione dell’estensione dei file e della content type, ma il fatto che una pagina abbia degli errori in relazione al suo tipo di doctype o content type non è irrilevante. Cioè…un documento xhtml valido sempre xhtml valido è…così come un documento xhtml non valido sempre xhtml “non valido” rimane. Che voglio dire cn questo? Chi scrive una pagina xhtml…non è interessato al modo in cui viene visualizzata o interpretata la pagina dai browser…ma è interessato al rispetto della sintassi nel codice (PUNTO), fondamentale per tutte quelle tecnologie “intelligenti” che la richiedono e la rispettano (come firefox 3)
Ad esempio uno spider potrebbe leggere il tuo file xhtml, php o html , controllare 1 meta tag e controlallare se il metatag ha la barra trasversale o meno prima della chiusura del tag. Se lo spider è intelligente aldilà che il tuo file abbia estensione xhtml o html, leggendo la content type e il doctype potrebbe imporre in relazione al formto xhtml di non accettare il meta tag solo perchè ad esempio manca la barra di scorrimento . Ma il fatto che lo spider è intelligente o meno, ..non ha niente a che vedere con la sintassi del documento!
@capobecchino,@daniele
Grazie per i complimenti :)
@daniele
È proprio questo il punto che si vuole evidenziare: il fatto che la maggior parte degli sviluppatori non utilizza le caratteristiche per cui è stato sviluppato XHTML e dunque potrebbe benissimo utilizzare il “semplice” HTML, senza rinunciare ad alcuna funzionalità
@Giancarlo
Quello che dici è giusto, ma io non sto mettendo in dubbio la buona fede dello sviluppatore, che si presuppone scriva xhtml valido.
Il fatto è che anche se tu scrivi xhtml valido, e poi lo servi come html, il documento viene gestito dal parser html, che è permissivo e quando incontra una sbarra trasversa la tratta come una svista dello sviluppatore e quindi rende la pagina come se nulla fosse, proprio come abbiamo visto nell’esempio.
Purtroppo il content type è uno solo, potresti indirizzare quello giusto per i browser che lo supportano e html semplice per gli altri, ma che senso avrebbe? Comunque, se utilizzassi caratteristiche di XML, ti ritroveresti con una buona fetta dei tuoi utenti tagliata fuori, e secondo me non è un’opzione valida, non trovi?
Stiamo dicendo la stessa cosa….con una sola differenza…entrambi stiamo traendo delle conclusioni diverse. La tua conclusione è che siccome certi browser leggono xhtml come html…tanto vale scrivere il codice direttamente in html. Io dico…siccome certi browser leggono xhtml come html…comunque scrivo in xhtml per quei browser che interpretano correttamente xhtml!!!…e mal che va…gli altri browser visualizzano la pagina in html.
Le premesse sono le stesse…le conclusioni diverse. Adesso ti descrivo le motivazioni della mia conclusione portandoti 2 esempi.
1) Perchè è stata fatta la legge stanca sui siti della Pubblica Amministrazione ? perchè il target della P.A. è tutta la cittadinanza anche quella disabile. In fondo la maggior parte dei naviganti è non disabile…seguendo il tuo ragionamento la P.A. dovrebbe eliminare la legge stanca e sacrificare la minoranza disabile per favorire la maggioranza abile. Il che corrisponde a dire…siccome firefox 3 tiene agli standard…ma la maggior parte degli altri browser no… tanto vale scrivere in html
2) Ci sono vari tipi di sviluppatori. C’è lo sviluppatore della pagina web, quelli dei browser , quelli dei server e quelli di altri software. L’errore non è certo dello sviluppatore della pagina web…ma degli altri sviluppatori. Ripeto….se io faccio un software che con una socket fa una richiesta GET del protocollo HTTP sulla porta 80 di un server e leggo 1 file….io potrei anche leggere 2 content-type diverse (ammesso che il server sia stupido e aggiunga automaticamente text/html)….quello restituito dal protocollo HTTP e quello presente nel meta-tag del file. A questo punto leggendo la doctype potrei anche capire…chi sta falsando…cioè se il server o chi ha scritto il codice.
Tutto sta sulla furbizia dello sviluppatore del software . Ma del software che legge il codice….Se chi ha prodotto quei software è imbecille non è certo colpa dello sviluppatore del codice html e aggiungo…lo sviluppatore del codice non deve buttarsi a mare se lo sviluppatore del sofware lo fa!
Purtroppo le cose non stanno così!
Il content type dei file è unico e dipende dal Mime Type che è associato al file.
Facciamo un esempio pratico. Questo sono gli header che vengono inviati al mio browser (Firefox 3.5 beta quindi massimo supporto agli standard) per la tua home page:
Date: Fri, 22 May 2009 18:12:05 GMT
Server: Apache/2.2
X-Powered-By: PHP/5.2.9
Cache-Control: max-age=86400
Expires: Sat, 23 May 2009 18:12:05 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 4019
Keep-Alive: timeout=15, max=200
Connection: Keep-Alive
Content-Type: text/html
200 OK
Come vedi il content type che viene inviato dal tuo server non è altro che text/html!! E questo nonostante tu abbia messo un meta tag che stabilisce il content type application/xhtml+xml, perchè il content type stabilito dal server sovrascrive quello specificato nel file!
La ragione è semplice: il content type associato ai file php è text/html, e non application/xhtml+xml, e quindi il tuo file è html.
In definitiva:
* Usare una dichiarazione doctype XHTML
* Inserire il prologo XML all’inizio del file
* Usare la sintassi XHTML
* Validare come XHTML
non implica che il tuo file sia XHTML. L’unica cosa che conta è il Mime Type, ed il Mime Type giusto è inviato solo per file xhtml.
Puoi cambiare le impostazioni nel server se ne hai la possibilità, oppure creare uno script php che effettui la content negotiation, fatto sta che se invii veramente file xhtml, tutti i browser IE non vedranno il tuo sito (che sia valido oppure no) e verrà mostrata una schermata di download del file. E questo possiamo permettercelo per i nostri siti personali, non certo per quelli che hanno bisogno del massimo bacino di utenza.
L’esempio della legge Stanca non calza, non ho detto di tralasciare nessuno, ho detto semplicemente di evitare di inviare documenti xhtml ad un parser html, che li visualizzerà, sicuro, ma ciò non toglie il fatto che siano “HTML invalid”!
Per quanto riguarda lo sviluppo del software, credo che esso dipenda dalle richieste dei suoi utilizzatori. Se le cose stanno andando così (sviluppo praticamente inesistente di XHTML 2.0, creazione del Working Group di HTML5) una ragione ci sarà ;)
Ciao Giancarlo, benvenuto su YIW.
Intanto mi complimento con entrambi per l’educazione e il rispetto dimostrato negli interventi nonostante i vostri pareri contrari, ecco, questo è il tipo di confronto e la condivisione che desideravo leggere in una community.
Ritornando all’argomento dell’articolo, quella che leggo nei vostri interventi è esattamente la diatriba che ne è scaturita in rete, gli sviluppatori si sono suddivisi in due fazioni, chi porta avanti le conclusioni di Giustino affermando che è inutile sviluppare documenti in xhtml se poi questi vengono serviti in html, e chi invece, come Giancarlo, ne incoraggia ancora l’utilizzo sostenendo che finché il codice è validato lo sviluppatore non deve curarsi del content type che uno stupido browser può assegnare al suo documento.
Quali delle due fazioni abbia ragione non si sa, io ho l’impressione che abbiano allo stesso tempo ragione e torto entrambi i due schieramenti, ma questo è solo un mio parere.
Comunque è anche vero che le tendenze del prossimo futuro lasciano prevedere un utilizzo di html5 piuttosto che xhtml2 di cui si sente sempre meno parlare, esattamente come ha fatto notare Giustino nel suo ultimo intervento.
Giancarlo, tu cosa ne pensi a tal proposito?
@nando, @Giustino : Io invece penso che in futuro avremo sia html 5 sia xhtml 2, così come attualmente abbiamo html 4 e xhtml 1. Perchè sono 2 linguaggi con obiettivi diversi. Uno è orientato ai browser e alla retrocompatibilità, l’altro è basato sulla rigidità sintattica dell’xml. Putroppo il protocollo usato sul world wide web per ragioni storiche si chiama HTTP (HyperText Transfer Protocol) e non XTP (xml transfer protocol). Così come AJAX si chiama AJAX perchè storicamente è nato con l’idea di fare chiamate asincrone che restituiscono XML anche se poi nella realtà si possono fare anche chiamate asincrone che restituiscono testo generico non formattato sintatticamente e ottenere lo stesso risultato (cioè velocizzare il caricamento delle pagine). Anche in questo caso…il termine storico lancia e lascia nella comunità l’idea sbagliata che ajax si debba interpretare solo come javascript asincrono+xml
Inoltre qui ci sono errori sia da parte del server sia da parte del browser. Il server sovrascrive l’header erroneamente…ma vorrei ricordare che la sintassi php è indipendente dal fatto che sul server siano configurati i file php con estensione .php piuttosto che con .pincopallino …Quindi l’errore è del server. Sarà per ragioni storiche? sarà per parsimonia dell’amministratore del server che non configura correttamente i content-type così come potrebbe configurare erroneamente i file .pincopallino? cavoli suoi!
E l’errore sta anche nel browser, perchè il browser seleziona il parser da usare solo in base al content-type dell’header HTTP…anche se il browser potrebbe prima di selezionare il parser giusto…creare un parser per leggere il file…e dopo aver letto la doctype e magari il meta tag content-type prendere la decisione.
Se tu fai wget –save-headers http://www.yourinspirationweb.com (purtroppo non posso farlo nel mio sito…dato che oggi il server ilbello.com è in black out…..inoltre ho tolto i minori e maggiori dai tag per evitare che il testo venga intrepretato come html da wordpress)
ottieni 3 informazioni riguardanti la tipologia del file :
HTTP/1.1 200 OK
Date: Sat, 23 May 2009 08:43:24 GMT
Server: Apache/2.2.8 (Unix) mod_ssl/2.2.8 OpenSSL/0.9.7a mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Last-Modified: Sat, 23 May 2009 07:39:21 GMT
ETag: “1c38a4c-125e8-46a8f79ab9c40″
Accept-Ranges: bytes
Content-Length: 75240
Cache-Control: max-age=300, must-revalidate
Expires: Sat, 23 May 2009 08:48:24 GMT
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”
html xmlns=”http://www.w3.org/1999/xhtml” dir=”ltr” lang=”it-IT”
head profile=”http://gmpg.org/xfn/11″
meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ /
bla bla bla …..
/html
Un browser serio capirebbe che c’è qualcosa che non va : 2 Content-Type text/html (uno nell’header http e l’altro nel metatag) e una doctype xhtml transitional !!!! L’errore qui sarebbe anche dello sviluppatore di wordpress per esempio…o di chi ne ha fatto le modifiche…perchè non si può scrivere Doctype xhtml e subito dopo contraddirsi mettendo un meta tag content-type impostato su text/html.
Dai tuoi interventi si vede che sei una persona con una vasta preparazione tecnica; purtroppo bisogna anche tenere conto dell’ambiente in cui si opera, non per quello ideale in cui si vorrebbe lavorare.
Ad esempio, io sto a Napoli. Vorrei davvero poter lasciare la mia bici dove capita e ritrovarla al mio ritorno, ma non lo faccio, perchè so che ne ritroverei “due”.
Tutti vorremmo dei browser intelligenti, ma non li abbiamo. Tutti vorremmo la perfezione del codice, ma a volte bisogna scendere a compromessi. Purtroppo in passato sono state fatte delle scelte che ci hanno portato a questa situazione di “non equilibrio” a cui si sta cercando di trovare una soluzione.
Noi abbiamo una grande responsabilità: l’HTML (o il suo sostituto) sarà il mezzo di comunicazione che i nostri posteri utilizzeranno per comunicare, quindi credo che la questione sia molto più di un “esercizio tecnico”. Dobbiamo riflettere e trovare una soluzione pensando al futuro, non per risolvere i problemi del presente.
In ogni caso, nessuno può sapere cosa accadrà. Non ho scritto l’articolo per cercare di convincere le persone “a darmi ragione”. L’ho scritto con l’intento di far ragionare sul problema, e prendere una posizione. E sono contento che tu ne abbia una, anche se diversa dalla mia!
Fino a quando non avremo una risposta: pace! E spero di ritrovarti ancora su queste pagine per le prossime volte ;)
Figurati…neanche io voglio “prendermi la ragione”….anch’io come te…ho espresso le mie posizioni….e credo che questo modo di confrontarsi sia utile, per ragionare sui problemi. Ci ritroveremo sicuramente in queste pagine…. :-)
dovrò imparare ancora molto per capire i vostri commenti XD
ciao!
millecomplimenti per questo posto, è tutto veramente interessante e se fossi capitata qui prima probabilmente mi sarei scervellata meno sul mio blogwp!
naturalmente non sono un’esperta…quanto di più lontano!
leggendo questo articolo ho provato a ricontrollare le mie pagine (il tema è tutto mio, siate clementi), quando ho creato il blog il codice era valido ma adesso mi accorgo che non è più così e mi sembra che gli errori siano quasi tutti dati dai badge (flickr per esempio) inseriti in un secondo momento, può essere?
consigli?
grazie!
Ciao pandora,
e benvenuta su YIW.
Innanzitutto mi scuso per il grande ritardo con cui ti rispondo
Per rispondere alla tua domanda, purtroppo in questo (come in molti altri campi) a volte è necessario scendere a compromessi e “sopportare” qualche piccolo errore di validazione causato da plugin di terze parti, se il guadagno che se ne trae dall’utilizzo ne vale. Ovvero: se puoi fare a meno del plugin e/o badge tanto meglio, ma se la sua funzionalità ti è utile, un piccolo errore di validazione non è poi la fine del mondo.
L’importante è non prenderla come scusa per scrivere codice non validato, però ;)
A presto,
Just
ciao Just e grazie per la risposta,
se devo essere sincera proprio non so come comportarmi…ero piuttosto fiera di aver realizzato un tema partendo da zero e aver ottenuto il risultato di codice validato!
e anche vero però che il badge di flickr mi piace e vorrei tenerlo…forse però dovrei scegliere dei semplici link testuali e cercare di risolvere così il problema…