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.

25 CommentiDi' la tua

Il tuo indirizzo email non sarà mostrato pubblicamente. I campi obbligatori sono contrassegnati da *

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.

Matteo
Matteo

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 menu Questo 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 :)

JustB
JustB

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. http://www.wayofsilence.com/ Fammi sapere cosa ne pensi.

Matteo
Matteo

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.

Matteo
Matteo

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?

JustB
JustB

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.

Matteo
Matteo

@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?

JustB
JustB

@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.

Matteo
Matteo

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 :-)

Michele
Michele

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.

Daniele
Daniele