Bye bye XHTML
Martedì 21 Aprile 2009 - 08:55
di Cesare Lamanna
Si stupisce Dave Shea, si stupisce di come un piccolo messaggio su Twitter possa scatenare tante reazioni. E cosa aveva detto il buon Dave di tanto clamoroso? Che da un po’ di tempo i siti per i suoi clienti li fa in HTML 4.01 Strict, semantico e valido, avendo così mollato XHTML.
Perché? Il ragionamento mi pare non faccia una grinza. Quando tutti abbracciarono XHTML c’era davanti una prospettiva, quella di vivere un giorno in ambiente web fondato su XML. Grande, fantastico, peccato che nel frattempo, continua Shea, questa prospettiva sia praticamente morta. La strada verso XHTML2 non porta da nessuna parte, è un cul-de-sac senza uscita. Non c’è supporto nei browser, non c’è interesse nel settore, e mai ci saranno. Il futuro si chiama HTML5. E XHTML?
Dal momento che ho perso la fiducia in XHTML, non ha molto senso continuare a diffonderlo.
Amen.
Categoria: Web Standards | Permalink
Commenti
1
a parte i tempi biblici che occorreranno per x/html5 o xhtml2 (non ho fatto errori di battitura), suggerisco:
http://xhtml.com/en/future/x-h.....s-xhtml-2/Se uno ha la pazienza di leggere e aggiornarsi con le iniziative w3c,scoprirà che tendono a fiorire iniziative, e conseguentemente a favorire l’XML.
Ogni sviluppatore è libero di utilizzare la dtd che ritiene più opportuna, di certo è ridicolo abbandonare xhtml perchè si ha difficoltà a gestire la componente “well-formed” (tag che devono essere chiusi, corrispondenze, etc) dell’xhtml.Personalmente manterrò dtd xhtml1.0 strict,ma segnalo ancora di notare il prodigioso funzionamento dei feed rss: xml puro, facilmente parsabile, una manna per i motori.
Io direi che la direzione è quella….
Optatare per lo switch per una questione di compatibilità di alcuni browser con alcune funzionalità html5, a fronte di una totale mancanza di supporto per xhtml2, è prematuro, a mio avviso. I tempi di rilascio, come già detto, sia di X/HTML5 che di XHTML2 sono biblici, e decidere ora se scegliere l’uno o l’altro significa mettere le basi sicure per un’altro inseguimento dei browser, e delle loro funzionalità.
2
Io continuo a ribadire a destra e a manca che da anni abbiamo velocissimi e “bugless” motori XML ed XSLT che hanno 1/10 dei problemi perfino in Internet Explorer e sono supportati praticamente da tutti i browsers …
3
non è un pò troppo presto per parlarne?
in fondo, non più di qualche mese fa, proprio su html.it si parlava che html5 dovrebbe uscire per il 2020. mi sbaglio? cmq, io sono favorevole all’html5 visto che mi sto già muovendo in quella direzione per i primi tag nuovi, poi, come è già stato detto, ognuno è libero di fare quello che vuole.# - postato da sonounostrinato - 21 Aprile 2009 - 10:33
4
Credo non sia conveniente per nessuno a livello professionale abbandonare una tecnologia per il fatto che probabilmente tra qualche anno non servirà più. Gli sforzi sono stati tanti negli ultimi anni per migliorare il markup e le tecnologie si sono evolute notevolmente, penso che prendere una decisione di questo tipo sia controproducente. Posso capire chi cerca di diffondere nuove tecnologie e non vede riscontri nell’immediato può rimanerne deluso ma in assoluto credo sia controproducente. Ancora oggi esistono siti fatti con le tabelle ma non per questo è il modo migliore per fare un sito web.
# - postato da Mauro Accornero - 21 Aprile 2009 - 11:19
5
Sono anche io dell’idea che l’xhtml non dovrebbe essere abbandonato, anzi debba essere sempre più incentivato.
Non mi sento nemmeno di dar torto a Dave Shea in quanto, come ho già avuto modo di scrivere tempo fa qui su Edit, un content-type “text/html” in una pagina con DTD transitional o strict, viene parsata dal browser come una normalissima pagina html.
Mettendo il giusto content-type con estensione .xhtml, IE (manco a dirlo) esegue il download della stessa.
A che pro scrivere in cima “…DTD/xhtml1-strict.dtd”? Mi pare una ennesima medaglia appesa al petto, giusto per dimostrare quanto siamo bravi con l’html?
Fino a che uso CMS con DTD preimpostate, non posso farci nulla. Quando realizzo templates css + html, uso HTML 4.01 Strict.
6
Più che per fare il figo utilizzo l’XHTML perché altrimenti sarebbe quasi impossibile far funzionare correttamente tutte le applicazioni JavaScript che creo.
7
@Mattia … e quale sarebbe il problema con JavaScript su HTML piuttosto che XHTML? No perche’ JS lo usiamo da prima del W3, non e’ un linguaggio nuovo eh …
8
L’XHTML è stata una grande rivoluzione e sicuramente è lui che potrà dirigerci verso il futuro che si chiama web 3.0 e web semantico.
Manteniamo l’XHTML!
9
@andr3a:
d’accordo al 100% con il tuo intervento# - postato da Pino - 21 Aprile 2009 - 20:07
10
Molte operazioni riguardanti il DOM funzionano meglio con l’XHTML che con l’HTML (nodi padri, figli, ecc…).
11
ma che ci sta a fare il W3C se dopo tanti anni di gestazione ci troviamo ancora di fronte a 2 proposte di standard concorrenti, incompatibili fra loro, poco retrocompatibili, non scalabili, e sempre più pieni di tag inutili
???# - postato da Mik - 21 Aprile 2009 - 22:46
12
Faccio io la voce fuori dal coro questa volta.
Mi spiagate a cosa serve una tale complessità in una pagina web… dove per definizione la cosa più importante dovrebbe essere la leggerezza e la semplicità?
Non potremmo invece eliminare tutta la porcheria presente nelle pagine web e fare tutte queste operazioni lato server?
Io vorrei vedere eliminato non solo l’xhtml e l’html5 ma anche la maggior parte degli oggetti DOM esistenti oggi (oltre che il flash et similia) che servono solo a dare una scusa agli sviluppatori per inserire decine di inutili, sì inutili, framework javascript sulle pagine rendendo la navigazione un vero tormento.
13
Perché sarebbero inutili i framework JavaScript?
14
@Mattia
Perché sarebbero utili?
Cosa fanno che proprio non si può fare a meno?
Quale immenso vantaggio presentano?
15
forse qui è OT, ma mi piacerebbe proprio leggere le reciproche controrisposte tra Mattia e lordmax…
eheheh
una cosa tipo un post di discussione 13 VS 14…
16
@Mattia
Un HTML ben scritto non crea problemi, rispetto l’XHTML, con le operazioni sul DOM.# - postato da Gianluca - 22 Aprile 2009 - 11:29
17
Ammetto che la discussione fra me e Mattia scadrebbe ovviamente nella filosofia più che nella programmazione però visto che sembra perfettamente in grado di parlare e discutere senza scatenare flames potrebbe essere veramente un argomento interessante, se preso come filosofia e non come crociata. ^__^
Che dici Cesare, un bel post filosofico?
^___^
18
Penso che il vantaggio principale sia quello che molte funzioni, che potremmo ripetere mille volte o a cui ci servirebbe molto più di una sola riga di codice, siano già pronte. Se il problema è il peso, basta includere i moduli che interessano quando scarico il framework.
19
@mattia
No, appunto, quello che intendevo io era più alivello filosofico.
In che modo tutte queste opzioni sono fondamentali?
E’ palese che più cose carichi nella pagina e più questa sarà pesante.
E’ altrettanto ovvio che un professionista starà attento a non abusarne.
E fin qui tutto ok.
Ma la domanda che mi pongo è: non sarebbe meglio limitarci un poco e tornare a delle pagine che forniscono informazione e non solo immagine?
Se compongo la pagina totalmente lato server (magari tramite ajax per alcune parti) non posso dare la possibilità al mio utente di usare più mezzi di lettura (il browser recente ma anche quello meno recente, il palmare, il cellulare, e via dicendo)?
20
Hai ragione per le pagine che forniscono contenuti ma non per quanto riguarda le web application (che comunque dovrebbero essere più compatibili possibili).
21
@mattia
Perché non per le web application?
Non è polemica è proprio una domanda, non mi è chiara la differenza che intendi. ^__^
22
Perché per le web application bisogna usare qualcosa tra JavaScript, Java, Flash, Silverlight, ecc…
23
@Mattia, @lordmax, siete due casi estremi …
@lordmax, è evidente che non hai in mente concetti come usabilità, user-friendly, e semplificazione naturale di procedure altrimenti macchinose
@Mattia, i framework sono utili se non conosci affatto il JavaScript … altrimenti ti giuro che puoi farne a meno con risultati migliori, ottimizzando in oggetti o funzioni solo quello di cui hai bisogno, o aggiungendo altro a frameworks che non possono trattare tutto il panorama per logistica dei casi
Il bello sta nel mezzo, capire quando JS, o non JS, serve o è un requisito, o è indispensabile, (x)HTML o meno … imho
24
A me sembra di conoscere JavaScript ma per fare alcune web application al lavoro senza usare framework ci metterei moltissimo tempo in più.
Infatti prima ho scritto che in alcuni casi (come le web application) JavaScript o chi per esso è indispensabile.
Poi dipende cosa si intende per web application…
25
@andr3a
è evidente che hai letto ben male quello che io e Mattia abbiamo scritto.
Conosco perfettamente (quasi) usability, user friendly e semplificazione e posso garantirti (anche perché è il mio lavoro) che si possono ottenere senza alcun framework e con un uso limitato di javascript. E sicuramente l’usabilità non la ottieni con flash o silverlight@Mattia.
Ottimo.
E’ proprio quello che intendevo, mi sembra che la tendenza attuale sia quella di caricare una decina di framework e poi usare due funzioni se va bene, e magari anche le meno utili.
Quello che intendevo era proprio che tutti questi framework magari semplificano la vita dello sviluppatore ma complicano (ed appesantiscono) quella dell’utente.
Diciamo che ho nostalgia di quelle belle pagine html+javascript scarne scarne con tutto il lavoro fatto lato server.
26
Io sono favorevolissimo ai framework js (gestire tutto lato server? quale follia), grazie al mio preferito sono in grado di fare cose semplici in poco tempo, testandole su un unico browser. Se dovessi scrivermi a mano tutte le funzioni dovrei come minimo testarle su tutti i browser (e voi sapete già il perché).
Per quanto mi riguarda mi sapete dire la differenza tra html ben strutturato ed xhtml? A me sembra che ci stiamo sparando le così dette “seghe mentali”.
27
@Mattia, si scusami, e’ che quel commento sulla differenza JavaScript tra xHTML e HTML deve avermi creato qualche pregiudizio …
@lordmax, se per te una form senza suggerimenti o aiuti runtime, datepickers inclusi, magari bello corposo da scrollare per ogni submit sbagliato e’ usabile … e se per te il drag’n drop non e’ friendly beh hai ragione, javascript non serve a niente. Comunque sia, non ho mai parlato di silverlight o flash, sebbene quest ultimo sia la via piu’ semplice per uploads multipli … quindi ribadisco, quando serve, va benissimo … essere contrari a priori o favorevoli a priori e’ sbagliato in ogni caso, imho
28
@andr3a
Evidentemente c’è un problema di comunicazione.
Io scrivo: “si possono ottenere senza alcun framework e con un uso limitato di javascript”
Tu rispondi: “essere contrari a priori o favorevoli a priori e’ sbagliato in ogni caso, imho”
Quale parte di “uso limitato di javascript” non è chiaro?
^___^NOn ho mai detto che javascript è inutile sto solo continuando a dire che l’uso smodato che se ne fa ultimamente è deleterio.
Prova un po ad usare i tuoi dannati datapicker, gli aiuti in popup e tutta quella roba con un palmare od un cellulare e poi mi parlerai dell’accessibilità e dello user friendly.
29
Shea rientra in quella categoria di persone che non conosce a fondo gli standard ma si limita ad usarli. Il suo è un punto di vista molto cinico, a mio avviso, che denota anche scarsa conoscenza di XHTML e HTML 5 che possono essere serviti sia come text/html che come application/xhtml+xml. Consiglio ai lettori di Html.it di approfondire con gli articoli su www.xml.com e di seguire il blog di Ian Hickson (un fine conoscitore degli standard: http://ln.hixie.ch).
# - postato da Gabriele Romanato - 24 Aprile 2009 - 13:21