Come si comportano le API e i nuovi tag proposti dall'HTML5 nel mondo reale? Come dobbiamo comportarci se vogliamo beneficiarne? In quest'ultima lezione risponderemo a questa importantissima domanda esaminando alcune best-practice per una implementazione che possa arricchire le nostre applicazioni e portali web senza causare grattacapi e disagi.
Una pioggia di tag
Possiamo usare <article>, <section> o <footer> su browser come Internet Explorer 6? La risposta è sì, a patto di premunirsi di alcuni semplici e comodi strumenti capaci di far recepire questi nuovi elementi HTML5 anche a user-agent non più giovanissimi. Uno di questi tool, specificatamente progettato per i browser di casa Microsoft, prende il nome di html5shim e può essere incluso nelle proprie applicazioni molto facilmente:
<!--[if lt IE 9]>
<script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->Questo strumento fa sì che Internet Explorer possa applicare gli stili ai nuovi tag introdotti dall'HTML5. Ma ancora non basta. La maggior parte dei browser di non ultima generazione, infatti, non conoscendo direttamente i nuovi elementi, applica a loro un foglio di stile di base errato, assegnando ad esempio display:inline a tag come <article> o <section>.
Per risolvere questa fastidiosa incombenza la soluzione migliore è utilizzare un foglio di stile capace di resettare le proprietà di questi e altri elementi attivando il comportamento atteso. HTML5 reset stylesheet si presta in modo ottimale a questo obiettivo; l'unico passo da compiere è includerlo all'interno del proprio sito prima degli altri documenti .css.
Feature detection vs. browser detection
La corsa all'HTML5 intrapresa dai vari browser nell'ultimo periodo si può descrivere come una incrementale implementazione delle feature proposte dal W3C; il criterio con cui viene stabilita la priorità nella 'scaletta delle API da aggiungere' è influenzato da moltissimi fattori e differisce da prodotto a prodotto. Allo stato attuale delle cose non ha quindi particolarmente senso determinare il comportamento della propria applicazione sulla base dello user-agent che la sta eseguendo, quanto più cercare di intercettare la presenza o meno di una specifica feature.
L'attività, potenzialmente noiosa di per sé, viene facilitata in modo estremo dalla presenza sul mercato di un utilissimo tool: Modernizr.js. Facciamo un esempio, sinceriamoci del supporto per il localStorage:
if(Modernizr.localstorage) {
alert("Rilevato il supporto per il localStorage");
} else {
alert("Oh oh, nessun supporto per il localStorage");
}Semplice, elegante e molto comodo. L'installazione di questa libreria si risolve con una semplice inclusione e una speciale classe da applicare al tag <html>:
<html class="no-js">
<head>
<script src="/modernizr-1.6.min.js"></script>
<script>
// Ora puoi utilizzare Modernizr!
</script>
</head>Fallback e alternative
Abbiamo scoperto che il nostro utente non supporta una certa funzionalità... e ora? Niente panico: nella maggior parte dei casi esistono valide alternative, o quantomeno interessanti opzioni di fallback. Vediamole nel dettaglio.
Audio e Video
In questo caso l'alternativa migliore rimane la collaudata tecnologia Flash. Esistono parecchie librerie sulla rete capaci di determinare autonomamente il supporto o meno al tag <video> e agire di conseguenza. Noi abbiamo scelto video.js per la sua maturità e per l'ottimo supporto di skin con le quali personalizzare il proprio player. L'utilizzo è semplicissimo e ben illustrato nella pagina di Getting Started.
Canvas
Abbiamo due soluzioni da segnalare come alternativa all'assenza canvas: la prima si chiama explorercanvas, una libreria Javascript sviluppata da Google per simulare il comportamento del <canvas> all'interno di Internet Explorer. Per attivarla è sufficiente richiamare lo script excanvas.js all'interno del proprio tag <head>:
<!--[if IE]><script src="excanvas.js"></script><![endif]-->Da qui in poi è possibile utilizzare all'interno della pagina il tag <canvas> ed invocare su questo la maggior parte dei metodi previsti dalle specifiche W3C.
L'altra tecnica di fallback prende invece il nome di FlashCanvas ed emula il comportamento delle API HTML5 attraverso il sapiente utilizzo della tecnologia Flash. La versione 1.5, supera più del 70% dei test proposti da Philip Taylor, piazzandosi in questo modo sul primo gradino del podio delle alternative disponibili. Anche in questo caso per beneficiare di questa libreria è necessario solamente richiamare l'apposito file javascript:
<!--[if lt IE 9]>
<script type="text/javascript" src="path/to/flashcanvas.js"></script>
<![endif]-->Geolocation
Come simulare le API di geolocazione quando non sono supportate? Prima di disperare è importante ricordare che seppur non tutti browser implementano queste specifiche è comunque possibile alle volte accedere ad informazioni geospaziali utilizzando API proprietarie messe a disposizione da particolari device o plug-in esterni, come ad esempio Google Gears. geo-location-javascript è una libreria che identifica le varie estensioni disponibili sul portatile (o smartphone) dell'utente e ne uniforma e centralizza le API permettendo di accedere ad informazioni come latitudine e longitudine usando gli stessi metodi proposti dal W3C. Ecco un esempio. Per prima cosa è necessario includere i necessari file javascript:
<script src="http://code.google.com/apis/gears/gears_init.js" type="text/javascript"></script>
<script src="geo.js" type="text/javascript" ></script>Quindi è necessario inizializzare la libreria con il comando:
if (!geo_position_js.init()) {
// funzionalità di geolocazione non presenti (ne HTML5 ne attraverso estensioni
// proprietarie...)
}A questo punto è possibile invocare i classici metodi come da specifiche W3C, stando attendi a preporre l'oggetto geo_position_js:
geo_position_js.getCurrentPosition(funzione_se_successo,funzione_se_errore);Drag and Drop
In questo caso ci sono due tematiche da affrontare: la prima è di carattere 'workaround' e si focalizza sull'identificare soluzioni alternative che preservino lo stesso meccanismo di interazione del Drag and Drop HTML5. Per questo tipo di eventualità esistono potentissime librerie capaci di offrire esattamente questo tipo di comportamento: le più famose sono ovviamente JQueryUI, ma anche Scriptaculous e il nuovo Scripty2. Tutto questa interazione di fallback, invece, viene meno nel caso le API previste dal W3C siano utilizzate espressamente per la loro funzione di input, quindi, ad esempio, per trascinare file all'interno della pagina web. In questo caso si può pensare di mantenere la funzionalità riducendo il potere dell'interfaccia e dell'interazione, realisticamente con l'utilizzo di normalissime form e di campi <input type=file>.
WebSocket
Appurata l'assenza del supporto WebSocket l'alternativa migliore rimane ripiegare su una tra le tecniche per soppiantare le quali sono nate proprio queste API HTML5: stiamo parlando di Comet e di websocket in Flash. Proprio a proposito di quest'ultima opzione merita un cenno l'ottimo, anche se poco documentato, web-socket-js capace di replicare il comportamento delle specifiche W3C utilizzando però un piccolo componente Flash iniettato dinamicamente all'interno della pagina. A questo indirizzo un esempio di utilizzo.
WebWorkers
Non esistono, al momento, soluzioni di ripiego per riparare l'assenza del supporto di questa parte delle specifiche HTML5 senza ricorrere ad estensioni di terze parti come le ottime WorkerPool API di Google Gears. L'unico workaround possibile è scrivere una versione del codice eseguito dal worker capace di funzionare all'interno del contesto della pagina ed eseguire quella nel caso in cui venga verificata l'assenza della feature (chiaramente perdendo il vantaggio dell'esecuzione asincrona). Nel caso invece si stia trattando si SharedWebWorkers il discorso si complica ulteriormente; è in linea teorica possibile emulare artigianalmente un comportamento di questo tipo utilizzando un area di storage comune (es: localStorage) per lo scambio di messaggi convenzionati tra le pagine dello stesso dominio.
WebStorage e IndexedDB
Come per i WebWorkers, anche qui la soluzione di fallback più completa in termini di funzionalità passa attraverso Google Gears: stiamo parlando delle Database API. E' però importante sottolineare che, mentre WebStorage e IndexedDB basano la loro filosofia di funzionamento su array associativi, Google Gears si appoggia ad una istanza di SQLite, un database relazionale che opera tramite classiche istruzioni SQL, In questo caso quindi offrire una soluzione alternativa all'assenza di questi componenti HTML5 potrebbe rivelarsi decisamente costoso.
Offline Web Application
Google Gears anche in questo caso. Le API si chiamano LocalServer e presentano funzionalità simili a quelle offerte dalle implementazioni delle specifiche W3C.
Shim e Polyfill a profusione
Abbiamo dato solo un piccolo assaggio della quantità di librerie alternative disponibili per sopperire alle più svariate API HTML5. In realtà il numero di questi software di fallback è decisamente sostanzioso ed è bene introdurre alcune differenze di massima tra le varie tipologie di librerie disponibili.
Definiamo come Shim una libreria che sopperisce ad una funzione mancante emulandone il comportamento ma richiedendo allo sviluppatore uno sforzo aggiuntivo in quando le API che mette a disposizione differiscono da quelle native in HTML5. Con Polyfill indichiamo invece uno Shim che però fornisce allo sviluppatore le medesime API offerte dalla controparte HTML5 rendendo così necessaria una singola implementazione.
Quindi, ove possibile è meglio preferire un Polyfill ad uno Shim. Già, ma come trovarli? Si può consultare la lista dei migliori polyfill redatta dagli sviluppatori di Modernizr.
Un ultimo appunto: se il numero di file javascript dovesse diventare troppo sostanzioso ricordiamoci che è sempre possibile ricorrere ad un loader condizionale, come yepnope.js.
Conclusioni
Siamo alla fine, con queste ultime righe si conclude la guida HTML5 di html.it, in circa 50 lezioni abbiamo sorvolato un pianeta ricco di nuove ed interessanti opportunità, capaci di far evolvere le nostre creazioni web fino a dove pochi anni fa non ritenevamo possibile. In questa lezione abbiamo scoperto come le specifiche si intreccino con il mondo reale e quali sono i potenziali comportamenti di fallback da implementare nel caso di assenza di qualche particolare feature. In particolare ci siamo accorti che per tematiche di basso livello (WebStorage, IndexedDB e Offline Web Application) non esistono soluzioni alternative, se si esclude Google Gears, che però necessita di una installazione manuale da parte dell'utente finale.
Un ultimo punto importante prima di concludere: non tutte le funzionalità proposte dall'HTML5 sono da considerarsi pronte per un uso in fase di produzione, alcune di esse infatti sono ancora in uno stadio di implementazione poco stabile, oppure subiranno a breve importanti cambiamenti nelle loro API; per avere un elenco aggiornato di cosa è considerato utilizzabile in produzione e cosa no potete consultare la tabella di compatibilità posta in appendice a questa guida.
