HTML5 ed il futuro di internet

Dopo aver parlato di standard web e della contrapposizione tra W3C e WCAG Samurai, è indispensabile fare chiarezza anche sul futuro dell’HTML.

Da tempo è avviata una discussione sulla specifica migliore per internet, e la strada sembra dividersi su due possibilità: HTML5 e XHTML2.

Da un determinato punto di vista sembrerebbe più logico passare da XHTML 1.0 alla specifica 2.0, non è però detto che le cose seguano questa direzione, anzi. I produttori di browser sembrano preferire una nuova versione dell’HTML, e molte discussioni degli ultimi mesi indicano la stessa strada, tanto che il W3C è tornato sui suoi passi.

Per capire qualcosa di più sulla questione, consiglio a tutti gli interessati la lettura di un ottimo articolo di Maurizio Boscarol, commenti compresi. E’ una serie di domande e risposte che permette di comprendere meglio lo scenario futuro del web. Il post è stato creato a Maggio, ma viene aggiornato ogni tanto con nuovi elementi.

Stiamo parlando dello sviluppo di un linguaggio che occuperà molti dei prossimi anni, ma è fondamentale che si individui fin da ora la direzione giusta per non cadere in inutili perdite di tempo.

Se volete inoltrarvi nella disputa tra HTML5 e XHTML2, vi segnalo anche un articolo di HTML.it, traduzione di un ormai famoso intervento di David Andersson su Digital Web Magazine.

Vuoi far crescere il tuo progetto online?

Tommaso Baldovino

UX/UI Designer, professionista del web con più di 15 anni di esperienza su WordPress. Sono disponibile a seguire nuovi progetti dall'ideazione alla realizzazione finale. Scrivo ogni 2 settimane la mia newsletter.

20 commenti su “HTML5 ed il futuro di internet”

  1. Non possono cambiare le carte in tavola ogni 5 minuti. Ci stanno portando ad essere tutti stressati :-D

  2. Quoto Agriturismo…
    si diventa matti a stargli dietro
    ed era l’ora che il W3C sia tornato sui suoi passi…..
    troppe regole??

  3. Da quel poco che so e che leggo qui e là sono più incline al “vecchio” HTML.

    La validazione con XHTML, tanto per dirne una, è legata alle volte a cose talmente assurde che passa la voglia di dedicarcisi. Tanto che lo stesso google non è w3c-xhtml-valid

  4. @tom. Si mi ricordo il tuo intervento al proposito.

    Io però intendevo dire che sarei più favorevole a uno standard di codice per il web “flessibile”, come mi pare sia nelle intenzioni HTML5: una via di mezzo tra le esigenze di accessibilità e la flessibilità dello strumento web.

    Infatti a mio avviso il grande successo di HTML4 e precedenti, al di là dell’ovvio fatto che ha costituito l’unico standard per creare pagine su internet, è derivato anche dalla flessibilità d’uso. Le tabelle, che non erano nate con fine di layout, hanno finito per essere utilizzate a quel fine solo perché era più semplice e intuitivo per gli utenti.

    Con XHTML, specie dall’1.0 strict, si è entrati in un campo in cui chi voglia creare ex novo una pagina da pubblicare su internet non può più essere un “dilettante”.

    Vengono cioè richieste competenze tecniche via via sempre maggiori se si vuole operare a livello di codice.

    Secondo me sarebbe bene non ignorare completamente le esigenze di semplicità e flessibilità che possono avvicinare tanti nuovi webmaster al codice.

  5. @Runa: capisco quello che intendi, e dal punto di vista di chi si avvicina per la prima volta al web è legittimo pensare ad una via più facile e diretta per scrivere del codice e realizzare un sito. Il discorso non è facile, sono anni che si spendono parole a riguardo.

    La mia speranza, se la strada è quella dell’HTML 5, è che si riescano ad unire gli aspetti che hai citato anche tu: flessibilità, accessibilità, e correttezza del codice.

    Va tenuto presente comunque che in qualsiasi ambito c’è una bella differenza tra un professionista ed un principiante: il secondo è liberissimo di realizzare un sito con le tabelle ed un editor visuale, ma non si dovrà stupire se ci sono problemi di visualizzazione su browser diversi o se non viene indicizzato da Google come desiderato. La qualità nel lungo periodo si fa sempre preferire.

  6. Tom ho visto anche siti realizzati da professionisti che fanno acqua da tutte le parti.

    Ma secondo te perchè stanno cercando di rivoluzionare dinuovo tutto?

    xhtml sembrava avesse preso ormai al 100% tutto il web si stava direzionando verso di lui…

    e poi?

    ma chi crea queste mode/tendenze su internet?

  7. Il mercato non si puo fermare…
    i produttori di software sono costretti a rinnovarsi continuamente.

    Adesso uscirà html5, tra un anno html6 e così via, e i poveri webmaster devono continuamente aggiornarsi per seguire i potenti del web…

  8. @tom: secondo me accessibilità e posizionamento sono assolutamente indipendenti.

    Il fatto che nella maggior parte dei casi un sito ben costruito lo sia sotto entrambi i profili, e quindi abbia anche un buon risconto su google, potrebbe ingenerare questa confusione.

    Astrattamente un sito pessimamente costruito sotto il profilo dell’accessibilità (fatto con tabelle, codice HTML arcaico e “sporco”, tag male annidati e non chiusi, in cui compaiono gif animate e una valanga di annunci adsense potrebbe astrattamente piazzarsi meglio su keywords competitive di uno costruito rispettando tutti gli standard più avanzati.

    Quindi un nuovo standard che fosse da una parte flessibile e facile da scrivere e dall’altra rispondesse egualmente alle esigenze di accessibilità sarebbe il benvenuto.

    A me pare che l’XHTML risponda soltanto alla seconda esigenza e non alla prima.

    Se l’HTML5 ci mettesse tutti “a pari livello”, principianti e straesperti, forse sarebbe meglio.

  9. Dal mio punto di vista il buon posizionamento è una naturale conseguenza di un sito ben costruito secondo gli standard e le indicazioni del W3C, per questo non le vedo come due cose indipendenti.

    Certo, ci sono siti ben posizionati che hanno una pessima realizzazione, ma a parità di contenuti il codice valido (ed il resto, sto semplificando per non dilungarmi troppo) paga ovviamente di più.

  10. @Grazitaly: dipende dallo scopo del sito, in certi ambiti si può avere successo anche con un sito a tabelle ma posizionato bene per altri 100 motivi.

    Un sito ben realizzato ha un vantaggio fondamentale: richiede molti meno sforzi per avere ottimi risultati in ambito SEO.

  11. Per non parlare che quel sito sarà accessibile da tutti i dispositivi, con un conseguente maggiore numero di visitatori.

  12. la penso perfettamente come Grazitaly….
    L’imporante per un sito è avere visite quindi vendere…..
    Di quanto è ben fatto e sematico il codice è proprio in secondo piano….

  13. runa wrote: “Astrattamente un sito pessimamente costruito (…) codice arcaico e “sporco”, tag male annidati e non chiusi, in cui compaiono gif animate e una valanga di annunci adsense potrebbe astrattamente piazzarsi meglio su keywords competitive”

    scusa runa…non è che mi spiegheresti questo miracolo della scienza? se parliamo di un sito fatto nuovo ora questo risulta abbastanza impossibile. se parliamo di siti già online da anni, bè non puoi fare il paragone dato che gli standard sono “abbastanza” recenti e “abbastanza” recentemente recepiti.
    e se il sito è online da anni, per quanto sia ben posizionato, a occhio è croce è vecchio e brutto da vedere.

    sinceramente ti sfido a costruire OGGI un sito fatto male e a posizionarlo…in bocca al lupo! se la questione è vendere e non essere accessibili (se non ci interessa) conviene entrare nell’ottica che essendo accessibili si vende..e anche MOLTO più facilmente, e che il contrario è solamente lavoro più pesante.

    scusate se mi sono dilungata. se avete esempi di siti che riescono a fare quello che dite voi, bè..fateceli vedere per favore ;)

  14. Credo che al giorno d’oggi un sito ben fatto, almeno nel campo dell’e-commerce, possa avere maggiori possibilità di posizionarsi. Io ne ho uno fatto con osCommerce 2.2 e quindi con tabelle ed attendo con impazienza il rilascio dell v3.0 che dovrebbe essere ottimizzato per i motori di ricerca, per es. la testata si trova dopo il contenuto della pagina.