Addio XHTML
Venerdì 3 Luglio 2009 - 07:50
di Cesare Lamanna
Titolo forte? Ma che espressione usereste per qualcosa che non ha futuro? Con tanto di timbro del W3C. In un documento sotto forma di FAQ apparso ieri sul sito, il Consorzio ha sancito di fatto la fine di XHTML come famiglia di specifiche. Significa che il Working Group XHTML 2 sarà smantellato a fine anno e che non ci sarà mai una specifica XHTML 2. Rimarranno in essere e mantenute le specifiche XHTML 1.1, XHTML 1.1 Basic e XHTML Print.
XHTML continuerà però ad esistere, come idea, come concetto, se mi perdonate la semplificazione. La specifica HTML 5, infatti, prevederà esplicitamente la possibilità “di una serializzazione XML del linguaggio HTML”, ma ciò avverrà nel contesto della specifica stessa.
Categoria: Web Standards | Permalink
sponsor
Commenti
1
Avrei preferito che si andasse avanti con XHTML 2 piuttosto che con HTML 5.
2
Più che altro sono rimasto deluso leggendo questo http://rss.slashdot.org/~r/Sla.....-5-Codecs, sembrava la cosa più innovativa inserita nell’html5..
3
xHTML è nato come tentativo di rendere ogni pagina web una sorta di database accessibile di documentazione.
Questo è ovviamente possibile solo se al sorgente della pagina di fornisse una documentazione dell’API della pagina stessa per spiegare COSA cercare nella pagina e DOVE trovarlo.
Inutile dire che questo risultato non si è MAI raggiunto nemmeno in termini molto vaghi.
C’è però un secondo aspetto della faccenda che coinvolge un’economia di scala e che, sopratutto, coinvolge da vicino noi “tecnici” dell settore: Google & friends!
Il motore di ricerca ha di fatto definito delle API di lettura della pagina cui noi tecnici cerchiamo di far fronte per ottenere risultati migliori: meglio è fatta una pagina, in termini di contenuto, migliore è il risultato del motore di ricerca.
Attualmente il vantaggio di una pagina welll-formed è minimo ma io sono convinto che sarà sempre più valutato.
Ad oggi Goole è sotto inchiesta per l’impatto ambientale ed esistono studi che mirano a calcolare la produzione di Co2 della singola ricerca nel motore.
In questo senso una pagina “well-formed” è più semplice da interpretare rispetto ad una schifezza in HTML 4.0 Trans! (magari fatta da un povero “web master” anni ‘90 con front page!!!)
In definitiva xHTML mira a massimizzare l’importanza del contenuto e del suo significante espresso mediante dei tag… ed è proprio ciò che vuole anche Google…
La domanda è: il W3C ha voce in capitolo rispetto a Google?
# - postato da Marco Pegoraro - 03 Luglio 2009 - 09:29
4
Se Cesare ha scritto questo post… vuol dire che, effettivamente, prima o poi si doveva arrivare ad una scelta: preferire html 5 all’xhtml.
Secondo me, e non so quali interessi possano esserci dietro questa preferenza, si rischierebbe di fare molti passi indietro con la scrittura delle pagine e, quindi, con la realizzazione di siti web.
Che “XHTML continuerà però ad esistere, come idea, come concetto” non penso possa farci felici, a me no.
E’ come avere una ferrari in garage e non poterla usare (a cosa mi serve l’idea di avere un’auto?) Se l’ho comprata… dovrei usarla. Sono molto dispiaciuto per questa piega che sta prendendo il web, ma questo è quanto.
5
Condoglianze ai parenti dell’ XHTML, e come abbiamo fatto sempre siamo noi a decidere se usare o no i “nuovi” standard.
Faccio un esempio:
Blue-Ray vs HD-DVD, ha “vinto” ufficialmente il formato della Sony (BR) a suon di dollari alle case produttrici cinematografiche, ma in realtà l’HD-DVD morto e abbandonato da circa due anni negli States (mercato + grande del mondo per il format war) ha fatto registrare nell’anno 2008 una netta supremazia del formato della toshiba (HD-DVD) nonostante sia stato abbandonato.Tornando a noi, se l’html5 porterà delle innovazioni interessanti prima per noi sviluppatori del web e poi per gli utenti ben venga e fanculo all’XHTML, ma se questo non avverrà, nessuno può vietarci di continuare ad usare XHTML.
Il mercato e gli standard (almeno in parte) siamo noi a deciderli!
6
Scusate ma qualcuno di voi mi sa spiegare perché ritiene che HTML5 è il male?
“Una ferrari nel garage e non poterla usare..” I siti che usano tutte le potenzialità di XHTML si contano sulle dita delle mani, quindi non vedo dove sia il problema di utilizzare una specifica (aperta) come HTML5. Inoltre permette anche la serializzazione XML e quindi tutti i presunti (perchè inutilizzati) vantaggi di XHTML non vengono persi.
Qual è il problema di HTML5??
7
se l’html5 dovesse portare (come spero) un miglioramento sul fronte dell’esperienza utente della pagina, strizzando l’occhio alle RIA, ben venga l’html5. E lo dico come sostenitore di xhtml: a me personalmente basta che la tecnologia sia tale da rendere possibile qualcosa di analogo a DOM, e che non si torni indietro a forme di markup più veloci e snelle ma più problematiche in termini di elaborazione/estrazione. In fondo xml(xhtml) ha già assolto al suo compito, cioè modificare la maniera in cui più o meno tutti (non solo i fissati) guardano alle pagine web, considerandole anche da un punto di vista strutturale e semantico.
Io francamente penso a mxml di flex e mi chiedo: si riuscirà ad andare su una strada del genere, e magari a farlo con un markup più essenziale? perchè se così fosse, allora davvero avremmo una rivoluzione! :-)
8
Bah… una notizia del genere mi causa enorme sconforto. Le spechifiche XHTML2 erano di gran lunga migliori rispetto ad Html5. Più rigide, più semantica, più logica.
Andare verso Html5 è come fare dei passi indietro. Se diventerà lo standard ufficiale penso seriamente che cambierò mestiere.
# - postato da Matteo - 03 Luglio 2009 - 11:29
9
Se non altro, una cosa che fa piacere è leggere:
Role and Access modules.
The HTML Working Group is the most likely destination.L’attributo role era una delle cose che mi piaceva di più di XHTML 2.0 assieme al modulo access per l’accessibilità, fortunatamente stanno pensando di inglobarli nelle attuali specifiche HTML 5. Il dubbio che sorge ora è: come condire il tutto coi nuovi elementi pseudo-semantici che hanno voluto introdurre in questa nuova versione del linguaggio?
Insomma, uso <nav> o <div role=”navigation”>? O magari persino <nav role=”navigation”>? Immagino che ora dovranno fare un po’ di pulizia.
# - postato da Simone Economo - 03 Luglio 2009 - 11:30
10
Mah, era solo questione di tempo.
XHTML (e la sua versione 2), come la maggior parte degli standard e delle specifiche, è bello finchè è sulla carta. Perchè nella realtà non è mai stato utilizzato davvero. Qualche motivo:
Nessun browser trattava l’XHTML come tale. Il mime-type richiesto da XHTML è text/xhtml, ma se aprite tutte le pagine (anche quelle che si fregiano di essere “validate XHTML”) ed andate a leggervi il mime-type troverete sempre e solo text/html. Utilizzando text/xhtml, IE ad esempio ti chiede (o chiedeva, è un po’ che non provo) se volevi scaricare il file. :/
XHTML partiva dal presupposto di poter scrivere pagine validabili sempre, al 100%. Questo nella realtà non è mai stato possibile e mai lo sarà. Ce lo vedete un utente che apre un sito e il browser con una pernacchia gli risponde che siccome non è attinente agli standard allora non può visualizzarlo? Magari.Per come la vedo io XHTML è uno standard nato morto, che ha avuto come unico risultato (questo si) quello di rendere internet un po’ più aderente agli standard.Niente di cui stupirsi dunque.
# - postato da Francesco Camarlinghi - 03 Luglio 2009 - 14:16
11
@Francesco Camarlinghi
Se quello che dici è vero io devo vivere in una realtà parallela ;)
Per fornire pagine che sono realmente xhtml basta usare i giusti header:$xhtmlSupport = (
isset($_SERVER[’HTTP_ACCEPT’]) &&
strpos(strtolower($_SERVER[’HTTP_ACCEPT’]), ‘application/xhtml+xml’) !== false
);if($xhtmlSupport) header(’Content-Type: application/xhtml+xml; charset=UTF-8′);
else header(’Content-Type: text/html; charset=UTF-8′);Questo è come lo faccio in php: xhtml per i browser e html per IE.
Per quanto riguarda i messaggi di errore sono una benedizione, finalmente si torna a programmare veramente e ci si allontana dalla nomea di smanettoni che gli sviluppatori web hanno nell’ambiente e fuori di esso. Tra l’altro i vantaggi di velocità di visualizzazione che si hanno con un parsing xml (che non prevede le mille inconsistenze del tag soup) sono notevoli, IMO.# - postato da Riot - 03 Luglio 2009 - 19:16
12
@Riot
Che senso ha fare la content negotiation? Alla fine, se vuoi permettere agli utenti che utilizzano IE di fruire il tuo sito, non puoi mettere elementi che sfruttino la potenza di XHTML, dato che a quest’ultimi tu invii HTML. Se è un esercizio di stile, va bene, ma quanto a utilità siamo ben lontani dall’obiettivo.
Per quanto riguarda i messaggi d’errore: come la mettiamo con il contenuto generato dagli utenti? Qualunque cosa dovrebbe essere inviata a un “parser”, verificata, e in caso di non “well-formedness” rispedita all’utente e così via..
13
@Riot
Beh il tuo esempio alla fine dimostra quello che dicevo io. :)
Non tutti i browser supportano XHTML come content type quindi il suo uso è abbastanza limitato come ha fatto notare anche JustB.
Per quanto riguarda la rapidità del parsing non sono d’accordo. Soltanto il fatto di dover controllare che il documento XML sia ben formato e valido è sicuramente un’operazione in più, non necessaria nel parsing HTML. Basta pensare anche a quanto dichiarato recentemente da Google per cui non chiudendo i tag html e body aumenta la velocità di parsing della pagina…
# - postato da Francesco Camarlinghi - 03 Luglio 2009 - 20:05
14
[…] Guarda Originale: Addio XHTML | Edit – Il blog di HTML.it Articoli correlati: Addio OracleClient | Edit – Il blog di HTML.it […]
# - postato da Addio XHTML | Edit – Il blog di HTML.it - 04 Luglio 2009 - 09:42
15
Ho sempre trovato strano il fatto che il W3C avesse portato avanti sia HTML che XHTML; dovendo scegliere ho abbandonato HTML.
A proposito di HTML 5 non ne so nulla (a parte il fatto che esiste/esisterà).
Domanda:
Quindi ora che si fa? Da oggi si passa ad HTML?
Possibile che non esista uno standard degno di tale nome?
16
premetto che non conosco in maniera approfondita le novità introdotte o di futura introduzione di xhtml2 e html5, e forse mi sfugge anche la filosofia di base di entrambi; quindi vi prego di correggermi se dico qualche inesattezza.
Impostata in questa maniera (”addio xhtml”), la notizia suona sicuramente come sconfortante… è come rendersi conto di aver creduto e difeso un concetto che oggi risulta perdente.
Ma forse la lettura giusta è un’altra. Non è che ad un certo punto al W3C si son resi conto che era inefficacie e/o inefficiente sviluppare due standard differenti (e implicitamente concorrenti, altrimenti perchè farne 2?) e che conveniva sceglierne uno (magari il meno problematico ad essere accettato dall’industria/mercato) ed inglobare i pregi dell’uno nell’altro?
Ed HTML da questo punto di vista è sicuramente più adatto a guidare una solida evoluzione rispetto ad una improbabile rivoluzione.Quindi la domanda per capire se questa è una buona o una cattiva notizia diventa: c’è qualcosa che html5 non permette/permetterà rispetto all’xhtml?
Se la risposta è no, allora forse questa è una buona notizia e tutto dipenderà, come spesso accade, dall’uso che noi sviluppatori faremo del linguaggio.Le mie son domande di cui non voglio imporre/proporre una risposta, chiedo a voi se un ragionamento del genere fila e a Cesare se era questo il senso di fondo dell’articolo.
# - postato da Daniele - 07 Luglio 2009 - 10:51
17
ho sempre sviluppato in xhtml e m’è piaciuto in quanto rigoroso ma se al w3c hanno deciso solo per html5 allora ho fiducia, sicuramente loro a pregi e vantaggi di uno rispetto all’altro c’hanno ragionato più di me.
mi aggiornerò come faccio quotidianamente sulle novità del web e passerò a html5, non cambierò lavoro, anzi mi piace proprio passare da un ligguaggio a un altro e tutte le volte, studiare, aggiornarmi e trovare soluzioni nuove he magari prima non erano possibili :-)
18
@JustB
E’ quello che faccio sui miei siti stile CMS. Invio l’input dell’utente al w3c validator tramite l’opzione fragment, e se è valido lo salvo nel datastore, altrimenti restituisco all’utente un errore di formattazione errata. Questo ovviamente accompagnato da un buon rich-editor xhtml compliant (tinymce). Il tutto è velocissimo ed estremamente efficente.
# - postato da Matteo - 08 Luglio 2009 - 10:34
19
@Matteo
Sicuramente è un’opzione, ma comunque si aggiunge un livello di complessità all’applicazione/sito web, e non so se ne vale la pena. Mi farebbe molto piacere vederne uno in atto, puoi postare un link?
20
Ho un’implementazione di questo nel backoffice management di http://infinitopub.com
Non posso darti l’accesso all’area backoffice ma puoi vedere tu stesso: gli eventi in homepage e l’intera bacheca (guestbook) sono gestiti tramite moduli che implementano questo sistema. Il sito è xhtml valido, e non consente l’inserimento di dati non xhtml validi.
Ho semplicemente creato un metodo di supporto a cui passo una stringa e mi restituisce true/false, e lo chiamo prima di salvare sul DB i dati, veramente molto semplice.
# - postato da Matteo - 08 Luglio 2009 - 13:39
21
Si, ho visto.
La questione era sul fatto che tutti i documenti i quel sito, che sono validi secondo le specifiche XHTML, vengono gestiti dal parser HTML (infatti il content/type della home page è proprio text/html). È questa la contraddizione che non riesco a spiegarmi: se viene usato come HTML perché utilizzare XHTML?
22
Hai perfettamente ragione. Di fatto solitamente utilizzo uno script di content-negotiation per servire le pagine come application/xhtml+xml verso i browser che lo supportano.
Qui purtroppo non ho potuto farlo in quanto quel determinato content-type mi causa dei problemi con alcuni moduli di jquery. E’ ovvio che preferirei la codifica xml con il parsing ecc ma a volte bisogna scendere a compromessi.
Questo non significa rinunciare al formato xhtml. E’ di gran lunga più semantico e logico dell’html 4 quindi non vedo proprio per quale motivo non dovrei usarlo, anche se non posso fornire il content-type consigliato.
# - postato da Matteo - 08 Luglio 2009 - 14:42
23
Questo è un altro sito fatto da me tempo addietro (e che sto per rifare a giorni) e qui il content-type è corretto. Inoltre ho usato la specifica xhtml 1.1
In questo sito non è presente la validazione dello user-input perciò alcune pagine potrebbero risultare non valide. Nella prossima versione del sito questo problema sarà rimosso.
Fammi sapere cosa ne pensi.
# - postato da Matteo - 08 Luglio 2009 - 14:44
24
Beh innanzitutto complimenti per il lavoro svolto, ti sono ampiamente dovuti :)
Voglio premettere che io non sono a favore di HTML o XHTML, voglio solo capire il perché di alcune cose che si sentono in giro, come per esempio la frase che hai detto tu:Questo non significa rinunciare al formato xhtml. E’ di gran lunga più semantico e logico dell’html 4
Forse c’è qualcosa che non conosco o non capisco. Quali sono gli elementi che mi rendono XHTML più “semantico”? Cioè io posso scrivere, ad esempio:
elemento menu
elemento menu
elemento menuQuesto elenco è valido sia per HTML che per XHTML. Allora cosa fa di XHTML migliore? Il fatto che non mi permette di chiudere i tag? Ma uno sviluppatore accorto può benissimo farlo anche in HTML. Quindi si ridurrebbe a una questione di velocità del parser e un minor sovraccarico per il browser. Ma ancora, questo vale solo per quei browser che supportano il giusto content-type. Non lo so. La questione della content-negotiation mi sembra più un (egregio) esercizio di stile, piuttosto che un vantaggio pratico.
Naturalmente non voglio convincere nessuno, voglio solo chiarirmi le idee su questo punto :)
25
Possiamo proseguire la conversazione, che trovo molto interessante, via mail. Trovi il mio indirizzo mail in footer al sito wayofsilence.com
Posso accennarti che studio la materia da 10 anni circa, e sono sempre interessato a nuovi punti di vista e pareri.
Ci sentiamo.
# - postato da Matteo - 08 Luglio 2009 - 15:26