XHTML: semplicemente HTML un po' rotto nella maggior parte dei casi.
Tuesday, 17 April 07
Qualche tempo fa scrivevo in queste stesse pagine (seppur fatte di pixel...) che
dopo tutto valeva la pena di passare ad XHTML, quanto meno per il
vantaggio introdotto dalla validazione. Sintatticamente l'XML (il formato usato dall'XHTML) e' meno bisbetico del'HTML che ha molti corner case ed e' molto piu' complesso. Per il resto e' chiaro a tutti che dal punto di vista della accessibilita' non cambia assolutamente nulla.
Pero' ho qualche interessante novita' per voi, appresa durante la lettura di questo articolo che getta nuova luce su come le cose funzionano davvero.
Prima un po' di fatti
- l'HTML e' una versione piu' semplice dell'SGML, ma ancora molto complessa.
- l'XML e' stato ricavato anch'esso dall'SGML ma al contrario dell'HTML e' stata posta l'enfasi sulla semplicita' sintattica, di parsing, e sulla rigidita' delle regole. Un client XML non si sforza di leggere oltre se trova qualcosa di non valido in un documento, si blocca con un errore.
- Il doctype da solo non e' in grado di far interpretare l'XHTML come XML, il browser si fidera' di quello che dice il Content-Type dell'header HTTP.
E ora la doccia fredda
Si... avete capito bene, mentre leggete questa pagina valid xhtml strict i vostri browser stanno invece pensando che e' HTML formattato un po' male con dei strani tag che si chiudono <cosi' />...
- Se proprio volete forzare l'interpretazione corretta potete emettere un header tramite l'applicazione web o modificando la configurazione di Apache, ad esempio in PHP la cosa suona piu' o meno come header("Content-Type: application/xhtml+xml") ma dopo non funziona piu' niente con alcuni browser, e anche i migliori potrebbero avere difficolta' in molti contesti.
- l'HTML4 e l'XHTML sono semanticamente identici, hanno esattamente gli stessi tag, e la stessa capacita' di separazione tra contenuto e presentazione, anche il posizionamento e tutto il resto funziona allo stesso modo. In pratica ad oggi l'XHTML non offre alcun vantaggio reale.
Tanto e' vero che le nostre pagine vengono interpretate come HTML per la questione dell'header HTTP... dunque di fatto stiamo quasi tutti utilizzando l'HTML come accadeva un tempo
Come comportarsi nella pratica?
La mia idea e' la seguente: siccome di fatto evitando di emettere il giusto header tutto funziona alla perfezione perche' l'XHTML e' piu' o meno un subset valido dell'HTML se non fosse per la chiusura dei tag e il doctype, ma ha il grosso vantaggio di abituarci ad una sintassi piu' rigida e si presta ad essere corretto tramite strumenti automatici continuare ad usarlo puo' essere dopo tutto una buona idea, ma almeno ora coscienti del fatto che sappiamo come funzionano le cose (per chi non lo sapeva gia'... io no).Per alcuni la soluzione e' HTML5 se mai vedra' la luce, ce lo dira' il tempo, ma per ora forse e' meglio evitare di essere religiosi su queste questioni e cercare di pensare ai contenuti.
Per approfondire
Do you like this article?
Subscribe to the RSS feed of this blog or use the newsletter service in order to receive a notification every time there is something of new to read here.
Note: you'll not see this box again if you are a usual reader.
Subscribe to the RSS feed of this blog or use the newsletter service in order to receive a notification every time there is something of new to read here.
Note: you'll not see this box again if you are a usual reader.
Comments
17 Apr 07, 05:55:34
@timendum: gia', alla luce dei fatti l'unico motivo puo' essere il fatto di voler usare dei tool di validazione internamente, come controllo di qualita'. Ma dal punto di vista della qualita' del servizio offerto non cambia davvero nulla.
17 Apr 07, 07:13:50
Beh, se si considera la ratio del XHTML io non sarei tanto drastico.
Le pagine web sono lette da browser (per dispositivi mobili generici, cellulari, PC desktop... ), spider, aggregatori... Miriadi di programmi che hanno tutto l'interesse di trovare uno standard che sia il meno complicato possibile.
In questi termini è cosa buona. Non è un nuovo modo di scrivere HTML, ma è una procedurizzazione semplificata ed alternativa che non ha vantaggi immediati in sede di uso "tradizionale" dell'output.
Parlo in particolare del XHTML strict che ha il suo focus nella separazione fra parte contenutistica e layout di rappresentazione.
Se per accessibilità si intende il veder bene una pagina via browser tradizionale allora XHTML non da nessun vantaggio.
Se invece si intende la compatibilità della pagina a tutti i "possibili" dispositivi di lettura, la semplicità del linguaggio è un grosso vantaggio rispetto al HTML 4.01.
Infine, da cosa può dipendere la scelta? Dal target di utenza, ed in particolare da come il target considerato accede (o potrebbe decidere di accedere) ai servizi.
Le pagine web sono lette da browser (per dispositivi mobili generici, cellulari, PC desktop... ), spider, aggregatori... Miriadi di programmi che hanno tutto l'interesse di trovare uno standard che sia il meno complicato possibile.
In questi termini è cosa buona. Non è un nuovo modo di scrivere HTML, ma è una procedurizzazione semplificata ed alternativa che non ha vantaggi immediati in sede di uso "tradizionale" dell'output.
Parlo in particolare del XHTML strict che ha il suo focus nella separazione fra parte contenutistica e layout di rappresentazione.
Se per accessibilità si intende il veder bene una pagina via browser tradizionale allora XHTML non da nessun vantaggio.
Se invece si intende la compatibilità della pagina a tutti i "possibili" dispositivi di lettura, la semplicità del linguaggio è un grosso vantaggio rispetto al HTML 4.01.
Infine, da cosa può dipendere la scelta? Dal target di utenza, ed in particolare da come il target considerato accede (o potrebbe decidere di accedere) ai servizi.
17 Apr 07, 07:16:37
@davidonzo: in realta' XHTML strict non ha il suo focus nella separazione tra contenuto e layout di piu' di quanto non lo abbia l'HTML 4.01, sono identici rispetto a questo!
Il problema e' che i browser non stanno in alcun modo interpretando la maggior parte dell'XHTML come tale, ma come se fosse HTML 4.01. In pratica anche se li avesse allo stato attuale XHTML e' impossibilitato dalla tecnologia dei browser ad avere qualunque vantaggio perche' appunto che e' XHTML lo sa solo l'utente che legge sul footer la simpatica scritta, per il browser e' HTML puro e semplice, ma un po' rotto.
Il problema e' che i browser non stanno in alcun modo interpretando la maggior parte dell'XHTML come tale, ma come se fosse HTML 4.01. In pratica anche se li avesse allo stato attuale XHTML e' impossibilitato dalla tecnologia dei browser ad avere qualunque vantaggio perche' appunto che e' XHTML lo sa solo l'utente che legge sul footer la simpatica scritta, per il browser e' HTML puro e semplice, ma un po' rotto.
17 Apr 07, 16:55:20
"in realta' XHTML strict non ha il suo focus nella separazione tra contenuto e layout di piu' di quanto non lo abbia l'HTML 4.01, sono identici rispetto a questo"
Non credo, anzi, per quanto ne so. è esattamente questo il punto.
La specifica xhtml (vedere dal sito w3c) ci dice di prendere html4.01 e non considerare tag tipografici (u,i,b, ecc.), di non utilizzare attributi di presentazione (bgcolor, align), di non utilizzare attributi di navigazione (target).
In più introduce che i tag empty (br, hr e credo basta) utilizzono lo standard xml.
Non sono molte modifiche tecniche, le modifiche sono concettuali.
Per esempio è possibile realizzare un menù a tendina solo con i css (ie a parte) ma è sbagliato perché i css devono essere utilizzati per la presentazione, non per la navigazione.
In pratica, la specifica ci dice: dimenticate l'aspetto grafico e occupatevi dell'approccio semantico (pensate che la vostra pagina venga letta, non vista!), ricordatevi di veicolare in più modi i contenuti (le immagini) e semplificate la lettura del documento (summary).
Tramite i css dategli la presentazione eventualmente diversa in base ai media di riferimento.
Con Js implementate i gli effetti di navigazione, menù a tendina, popup, ecc.
Il vero, enorme buco lasciato da xhtml sta nel fatto che è stato pensato per documenti, non per delle applicazioni, cui avrebbe dovuto pensare xForm, progetto che non ha mai visto la luce per diversi problemi (per es.: i tag input non devono essere chiusi con /> perché non fanno parte della specifica!)
In conclusione credo sia un'ottima cosa utilizzare la sintassi xhtml, perché ci forza a ragionare in termini di contenuti e non di aspetto grafico, la equiparo a dichiarare le variabili o non usare le goto.
Non credo, anzi, per quanto ne so. è esattamente questo il punto.
La specifica xhtml (vedere dal sito w3c) ci dice di prendere html4.01 e non considerare tag tipografici (u,i,b, ecc.), di non utilizzare attributi di presentazione (bgcolor, align), di non utilizzare attributi di navigazione (target).
In più introduce che i tag empty (br, hr e credo basta) utilizzono lo standard xml.
Non sono molte modifiche tecniche, le modifiche sono concettuali.
Per esempio è possibile realizzare un menù a tendina solo con i css (ie a parte) ma è sbagliato perché i css devono essere utilizzati per la presentazione, non per la navigazione.
In pratica, la specifica ci dice: dimenticate l'aspetto grafico e occupatevi dell'approccio semantico (pensate che la vostra pagina venga letta, non vista!), ricordatevi di veicolare in più modi i contenuti (le immagini) e semplificate la lettura del documento (summary).
Tramite i css dategli la presentazione eventualmente diversa in base ai media di riferimento.
Con Js implementate i gli effetti di navigazione, menù a tendina, popup, ecc.
Il vero, enorme buco lasciato da xhtml sta nel fatto che è stato pensato per documenti, non per delle applicazioni, cui avrebbe dovuto pensare xForm, progetto che non ha mai visto la luce per diversi problemi (per es.: i tag input non devono essere chiusi con /> perché non fanno parte della specifica!)
In conclusione credo sia un'ottima cosa utilizzare la sintassi xhtml, perché ci forza a ragionare in termini di contenuti e non di aspetto grafico, la equiparo a dichiarare le variabili o non usare le goto.
17 Apr 07, 17:40:29
@Domenico: sono perfettamente d'accordo con te sulla svolta filosofica, ma si puo' attuare anche utilizzando HTML 4.01, cosi' come si puo' NON attuare utilizzando XHTML, perche' i tag supportati sono quasi identici.
Detto questo concordo che e' meglio stare su XHTML ma e' abbastanza bene ricordare che farne una guerra di religione non e' il caso, se tale guerra si riducesse a
XHTML vs HTML 4.01, mentre fare la guerra filosofica da te indicata nel commento e' una buona idea, ed e' la vera differenza.
Detto questo concordo che e' meglio stare su XHTML ma e' abbastanza bene ricordare che farne una guerra di religione non e' il caso, se tale guerra si riducesse a
XHTML vs HTML 4.01, mentre fare la guerra filosofica da te indicata nel commento e' una buona idea, ed e' la vera differenza.
18 Apr 07, 04:03:37
Rimane il fatto che scrivere codice in xhtml non è affatto più difficile che scriverlo in html. Soltanto che l'xhtml, come dice Domenico, ti costringe ad un approccio più elegante e meno "disordinato", per cui viva l'xhtml, anche se mi è dispiaciuto scoprire che per i browser in fondo è la stessa cosa.
Evidentemente gli sviluppatori di Firefox, Opera e IE puntano su altre funzionalità, magari più immediate ed importanti per l'utente medio, a cui (purroppo) non importa un fico secco di come sia scritto il codice.
Evidentemente gli sviluppatori di Firefox, Opera e IE puntano su altre funzionalità, magari più immediate ed importanti per l'utente medio, a cui (purroppo) non importa un fico secco di come sia scritto il codice.
18 Apr 07, 04:10:24
@Doxaliber: quoto in pieno, infatti che il browser lo capisca o meno continuero' a sviluppare i miei siti in questo modo. Alcui browser, in particolare Firefox, hanno un buon supporto SE viene emesso il giusto header HTTP, il problema e' che non possono estendere l'interpretazione dell'XHTML a tutto il resto perche' basta un errore minimo di markup che per la specifica di XHTML la pagina NON SI CARICA! Questa e' un'ottima idea di XHTML che non tollera nessun errore sintattico, ma romperebbe una quantita' di siti.
Sto pensando seriamente di iniziare ad emettere il giusto header per alcuni miei siti in cui cio' e' possibile, ad esempio per questo blog.
Sto pensando seriamente di iniziare ad emettere il giusto header per alcuni miei siti in cui cio' e' possibile, ad esempio per questo blog.
Perché scrivere codice valido xhtml se poi viene interpretato come html?
Finché i browser terranno i piedi in due scarpe, onestamente non penso vada la pena uccidersi per ottenere codice validabile