While playing with it, I was wondering, which is the coolest feature introduced in this new release? Well, if you are a user, it should be the full screen support for native HTML5 video. If you are a developer, it may be the new CSS enhancements. But, what if you are a Macbook user?

If you are a Macbook user, it will surely be the detection of the notebook orientation using its integrated accelerometer.

There are a bunch of demo showing this new functionality, they were so exciting I wanted to build one on my own. So, here it is a brand new orientation bookmarklet:

SteerMe

Simply drag and drop the SteerMe button into the bookmarks toolbar of Firefox, or copy its link and manually create a new bookmark. Then, go to a new web page, press the newly created bookmark and begin to rotate your Macbook.

You will see the page still vertical while you rotate the notebook on the left and on the right, you will see it stretched and tightened while you move the keyboard up and down. And you will see the page bounce when, ehm…, you drop your precious notebook!

Tablet-like visualization with Macbook rotated on the left

Stretched page with keyboard upside down

How does it work? This is the bookmarklet code with extra spaces:

1
2
3
4
5
6
7
8
9
10
11
12

window.addEventListener &&
window.addEventListener("MozOrientation", function(e) {
    var h = innerHeight,
        ox = scrollX + innerWidth / 2,
        oy = scrollY + h / 2,
        bs = document.body.style;
    bs.MozTransformOrigin = ox + "px " + oy + "px";
    bs.MozTransform = "rotate(" + (90 * e.x) + "deg) " +
                      "scaleY(" + (e.y + 1) + ") " +
                      "translateY(" + (-h * (e.z + 1)) + "px)";
}, true);
void(0);

As with every bookmarklet, its Javascript code must be as short as possible and tends to be quite obfuscated, but it is very simple. First of all, we will listen to the new MozOrientation event on the window object. Then we will apply a CSS transform to the body of the page using the event orientation data.

Statistiche dei click sui link in WordPress

Mi chiedevo infatti come facesse WordPress ad avere questo tipo di informazioni. Per le altre sezioni ottenere i risultati è relativamente facile, i link utilizzati per arrivare verso questo blog ed i termini utilizzati sui motori di ricerca si ottengono semplicemente analizzando il campo Referer HTTP. Ma quando si fa click su di un link, il browser effettua soltanto una connessione verso il server che ospita la nuova pagina, senza segnalare nulla a quella che si sta per lasciare.

La risposta a questo dubbio è data da quella piccolissima immagine a forma di smile, che si trova in fondo ad alcuni blog WordPress, compreso questo:

Immagine utilizzata per le statistiche sui click in uscita

Scendendo in dettagli tecnici, ogni volta che si visita una di queste pagine, viene caricato il file JavaScript w.js dal server delle statistiche di WordPress. Questo script definisce una serie di funzioni (scritte per la verità in modo un po’ criptico e con uno stile non del tutto chiaro ed uniforme) che costituiranno il meccanismo con cui segnalare i click in uscita.

Una di queste è linktracker_init(), eseguita al caricamento della pagina aggiunge un listener sul body in modo da intercettare ogni click effettuato all’interno di quanto visualizzato. Ad ogni click verrà così eseguita la funzione linktrack() che, dopo aver verificato che questo sia avvenuto su di un link diretto verso un indirizzo esterno al proprio blog, costruirà un URL destinato verso il server delle statistiche e contenente l’indirizzo del link che si sta per visitare, per poi eseguire queste istruzioni:

var x=new Image(1,1);
x.src = src;

Lo script quindi creerà una nuova immagine che corrisponde proprio allo smile visualizzato sopra, la cui richiesta di caricamento permetterà l’invio delle informazioni necessarie al server delle statistiche.

L’utilizzo di un’immagine come meccanismo per l’invio di informazioni ad un server può sembrare in apparenza una tecnica un po’ esotica, soprattutto se confrontata con le ben più comuni richieste AJAX. Purtroppo però la limitazione di same origin policy, che si applica alle richieste AJAX, non avrebbe permesso di contattare un server con un hostname differente da quello associato al proprio blog. Ecco perché probabilmente hanno scelto di caricare un’immagine.

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.