L’elemento <video> ha lo scopo di semplificare decisamente l’inclusione di filmati all’interno delle proprie pagine web, rendendone l’inserimento facile come l’utilizzo di immagini attraverso il tag <img>.

In dettaglio, l’inserimento del video avviene utilizzando codice HTML di questo tipo:

<video controls="controls" src="URL filmato"></video>

L’elemento potrà inoltre contenenere altro codice HTML, come testo o immagini, che saranno visualizzati dai browser non compatibili, al posto del filmato.

In Firefox 3.1 l’unico formato supportato sarà Ogg Theora con audio Ogg Vorbis e per la decodifica non verrà utilizzato alcun tipo di plugin. All’interno dei sorgenti sono state infatti direttamente incluse le librerie sviluppate dalla fondazione Xiph.Org.

Presso il blog degli sviluppatori del browser Opera, è possibile trovare alcune pagine di esempio che utilizzano questo nuovo elemento HTML. Visitandole con la nuova versione alfa di Firefox, si potrà verificare direttamente quali risultati si possano ottenere:

Elemento <video> in Firefox 3.1 alfa 2

Rimane soltanto da fare un’ultima considerazione: la creazione di nuovi elementi come <audio> e <video> delinea una filosofia alla base dello sviluppo del nuovo standard HTML 5 che non ritengo completamente condivisibile. Per la visualizzazione di filmati o audio, escludendo il diffusissimo ricorso ad appositi player in Flash, era già disponibile l’elemento <object>, che ha il vantaggio di essere generico e quindi adatto a qualsiasi utilizzo non inizialmente previsto. Il rischio che si corre è infatti quello di abbandonare la strada intrapresa dal W3C che aveva portato alla differenziazione tra documenti HTML Transitional e documenti HTML Strict.

I nuovi elementi presentano comunque dei vantaggi, come ad esempio la disponibilità di un’API JavaScript studiata appositamente per la gestione di oggetti multimediali. Inoltre si potrebbe addirittura ottenere come effetto collaterale la diffusione e l’eventuale successo di un formato video standard e libero da royalty, se solo il working group di HTML 5 riuscisse a raggiungere un consenso al riguardo…

Vale sicuramente la pena di approfondire la questione per vedere se questo nuovo browser presentato possa portare innovazioni e miglioramenti oppure se non si tratti che di un ulteriore altro browser, in aggiunta a Internet Explorer, Firefox, Safari e Opera, e con il quale noi sviluppatori web dovremo fare i conti.

La prima considerazione da fare riguarda l’eventuale successo che potrà avere Chrome: sono piuttosto scettico sulla possibilità che possa guadagnarsi una discreta quota di mercato. Il caso di Safari 3 insegna, si tratta di un browser dalle ottime caratteristiche tecniche ma la sua diffusione è praticamente irrilevante.

Google non è Microsoft che distribuisce Windows con Internet Explorer pre-installato su quasi ogni nuovo computer venduto, sarà difficile superare questa inerzia e convincere gli utenti ad installare un programma nuovo. Firefox ha impiegato anni per ritagliarsi la propria nicchia di mercato ed ha potuto contare sul supporto dell’intera community open source ed importanti campagne pubblicitarie.

Difficile quindi che Google Chrome possa contastare lo strapotere di Internet Explorer.

Detto questo, passiamo alle sue caratteristiche tecniche.

Chorme adotta il motore di rending Webkit, si tratta di un’ottima scelta. Webkit è un ottimo progetto, dalle prestazioni eccellenti.

A mio parere la novità più importante consiste nell’utilizzo di un processo separato per ogni tab aperto nel browser. Si tratta di una soluzione definitiva e che avremmo dovuto vedere implementata in qualsiasi browser esistente, non bisogna infatti mai dimenticare la lezione di Eric Raymond sull’utilizzo dei thread al posto di processi separati. I crash dell’intero browser, con tutti i suoi tab e le sue finestre aperte, a causa di un semplice bug di un qualsiasi oggetto flash è un’esperienza purtroppo nota ad ogni utente. Riguardo ai thread, Raymond ricorda che: “… These are a recent import from elsewhere, … the idea of threads is native to operating systems with expensive process-spawning and weak IPC facilities. …”. Con elsewhere ci si riferiva molto probabilmente a Windows, ne deriva quindi un’ulteriore perplessità, oltre a quelle già esposte in altri blog, sulla scelta di rendere disponibile Google Chrome soltanto per questa piattaforma.

Infine una nota riguardante l’implementazione dell’interprete JavaScript. Non c’è alcun dubbio sul fatto che in futuro le applicazioni web renderanno necessarie prestazioni elevate anche nell’esecuzione di codice JavaScript. Google Chrome risponde a quest’esigenza con l’utilizzo della macchina virtuale V8. Viene definita la più rapida tra quelle in circolazione, ma in realtà il confronto vero dovrebbe avvenire con SquirrelFish di Safari e TraceMonkey per Firefox. Sarà interessante vedere come si evolverà la situazione.

Update: Wayne Pan e John Resig hanno pubblicato alcuni benchmark confrontando le prestazioni degli interpreti JavaScript esistenti. V8 di Chrome è il più performante nella maggior parte di questi test, il dato più importante mi sembra comunque il grande aumento di prestazioni portato dalla nuova generazione di interpeti.