web 2.0 Archivi - Mario Spada

Nel futuro del web si profila una svolta simile a quella del 1999-2002.
All’epoca l’introduzione dell’XHTML 1.0 che applica le rigide regole dell’XML all’HTML 4.01, metteva a freno il dilagare di documenti web
compilati in maniera maldestra per non dire completamente errata. Il parsing dei documenti da parte del browser (allora non c’era molta scelta…) presentava comunque un documento leggibile,
perché la gestione degli errori da parte del browser era molto tollerante. L’evoluzione di internet e quindi l’utilizzo di differenti user agent che avevano comportamenti differenti nell’interpretazione delle pagine malformate, ha fatto si che si ponesse un freno tutto ciò. Oltre alla richiesta di correttezza formale dei documenti web, bisogna tenere in considerazione anche la spinta dovuta ad una maggiore sensibilità verso l’accessibilità che è fra i principi promotori dell’XHTML 1.0, l’introduzione del web semantico e degli altri aspetti del cosidetto Web 2.0 e l’esigenza di una migliore indicizzazione sui motori di ricerca (i crawler preferiscono documenti corretti).

Molti addetti ai lavori, particolamente gli sviluppatori web piuttosto che i grafici “fac-totum” del web, hanno aderito al progetto, sebbene ancora oggi a quasi 8 anni dalla nascita di XHTML si stima che il 95% delle pagine web non siano valide! Il problema è che finché i browser faranno il parsing di un documento come fosse una zuppa di tag (tag soup), gli autori dei minestroni saranno sempre tranquilli che gli utenti continueranno a cibarsene. Infatti, un documento ben formato e un minestrone di tag serviti al browser con un content-type di tipo “text-html” risulteranno agli occhi dell’utente, identici. D’altra parte, a tutt’oggi solo i browser più recenti sono in grado di effettuare il parsing di un documento XHTML servito come dovrebbe, cioè come “application/xhtml+xml”. Ad ogni modo chi ha scelto l’XHTML strict si è almeno messo sulla buona strada per non dover rifare tutto in futuro (oltre a stare in pace con la propria coscienza di professionista del web).

Cosa è e cosa si propone di fare l’X/HTML 5?

La definizione, dalle parole di Ian Hickson

“E’ una nuova versione di HTML che ambisce a rimpiazzare HTML4 e XHTML1”

per ora in fase di bozza lo sviluppo viene curato da WHATWG

in maniera totalmente aperto, chiunque può partecipare. Uno degli aspetti più interessanti di questo progetto è senza dubbio l’idea che si possa finalmente avere un comportamento omogeneo dei browser, in virtù del fatto che i maggiori produttori (Mozilla, Apple, Opera software) sono già coinvolti e sembra che anche la Microsoft sia interessata all’iniziativa. Se poi questi produttori ne terranno conto davvero o meno, questa è un’altra storia.

Vediamo ora alcune novità:

Ampio supporto alle applicazioni web
Correzione degli errori dell’HTML4
Semplificazione del web rispetto al futuro XHTML2
Fusione dei modelli di Web applications 1.0, Web forms 2.0, Web controls 1.0 proposti da Mozilla, Apple ed Opera software
Nuova e razionale gestione della struttura del documento mediante nuovi tag: article, nav, header, footer. Sezioni logiche del documento divise in: contenuto, menù di navigazione, intestazione, piede di pagina. Vantaggi per i browser per palmari che potranno visualizzare solo la sezione che interessa
Limitazione all’utilizzo di javascript per il controllo dei forms, che sarà integrato nell’HTML
Introduzione dell’elemento canvas per la costruzione di immagini bitmap (tipo Yahoo pipes)
Specifico supporto per applicazioni web tipo Google Gear: implementazione di un sistema di salvataggio dati sul proprio sistema, editing negli elementi dei documenti, supporto al drag’n’drop
Introduzione di tag video e audio
Introduzione dell’elemento progress (barra di avanzamento), datagrid (griglia per tabelle)
Introduzione all’elemento dialog (supporto a chat)

Conclusioni:

l’X/HTML5 sarà molto probabilmente il futuro del web, gli sviluppatori troveranno uno strumento molto più potente di quelli che hanno avuto in passato, verranno corretti molti errori di forma e di sostanza sull’impronta della qualità dell’applicazione. l’XHTML2 d’altra parte ha troppi problemi di retrocompatibilità con i vecchi browser perché ha intrapreso una strada troppo rigida, peraltro inevitabile, per abbracciare in pieno la logica XML.
Ma l’X/HTML 5 rimarrà sostanzialmente un linguaggio markup strettamente legato ai browser, se un programmatore si vuole evolvere davvero, dovrebbe orientarsi verso piattaforme più ad alto livello, quali quelle che integrano XML, UML e paradigmi orientati agli oggetti

Riferimenti ed approfondimenti:

Prendo spunto da un interessante articolo apparso su Usabile.it per stigmatizzare alcuni importanti vantaggi delle applicazioni web rispetto a quelle desktop. Senza dubbio, l’avvento del Web 2.0 e soprattutto le nuove tecnologie che sono nate contestualmente, AJAX in primis, hanno contribuito enormemente all’espansione delle applicazioni web.
G-mail è l’esempio più tangibile. Sono dell’idea che, a parte i vantaggi che AJAX puň offrire in termini di funzionalità aggiuntive all’austera interfaccia HTML, sono molto più appetibili le caratteristiche intrinseche di un’applicazione che non necessita di una installazione client per client e, come viene sottolineato dall’articolo di Boscarol, l’approccio perpetual beta che permette un continuo affinamento dell’applicazione, in maniera molto poco intrusiva (forse anche troppo…).
Le applicazioni che esentano lo sviluppatore dal tedioso compito di fornire pacchetti autoinstallanti esenti da bugs e soprattutto intelligenti al punto di prevenire gli errori dovuti a differenti sistemi operativi o versioni di sistema operativo, di differenze nelle service pack installate, configurazioni errate e non ultimo, la presenza di virus, sono una gran bella cosa! Chi ha sviluppato per anni in Visual Basic o Delphi lo sa bene, anche gli sviluppatori JAVA hanno avuto i loro bravi guai con le differenti versioni di JVM.
Le applicazioni web, invece, necessitano solo di una installazione server, nel più dei casi gestibile da remoto, un buon RDBMS che funzionerà sicuramente meglio su di un server vero, presumibilmente in hosting, quindi con pochi problemi di gestione della sicurezza, di reliability e fault-tolerance, normalmente a carico del provider.
Certo esiste anche il rovescio della medaglia, ad esempio il maggior tempo necessario a sviluppare l’applicazione rispetto all’uso di ambienti RAD o la difficoltŕ maggiore nel gestire le stampe. Difficoltà che si vanno assottigliando con la sempre maggior diffusione di ambienti di sviluppo framework per gli script web server-side.
Non dimentichiamo, infine, il monito di Tim O’Reilly e Bill Higgins che, nel loro articolo “The Uncanny Valley of User Interface Design” lanciano un appello agli sviluppatori di applicazioni web per rimanere concentrati sul fatto che un’applicazione web deve essere “accordata” al suo ambiente. In sintesi, O’Reilly e Bill Higgins dicono che non bisogna lasciarsi prendere troppo la mano dal fatto che le nuove tecnologie permettono di trasformare uno strumento che ha il DNA per vivere nel web, in un animale dall’aspetto “desktop”. (La Uncanny Valley è un concetto della robotica che dice che esiste un punto nel quale il reiterato aumento di imitazione del comportamento umano da parte dei robot, li rende infine, meno simili agli umani).

Come evolve il web: l’X/HTML 5

Applicazioni Web contro applicazioni desktop