Risolto o, almeno, appreso come approcciare il problema della densità dei pixel… la fase di traduzione in codice della bozza d’un sito non può ignorare la compatibilità coi browser: le difficoltà, al solito, non riguardano tanto HTML. Molti designer cresciuti negli anni ’90 pensano che adottare HTML5 sia prematuro perché lo standard non è ancora completo, ma per la maggioranza dei progetti il markup non richiede le funzionalità avanzate del linguaggio e affinché ogni browser lo interpreti correttamente basta un semplice script.

Tutt’al più, è vero il contrario: alcuni engine aggiornati interpretano gli elementi di HTML5 accludendo delle caratteristiche assenti dagli altri. Per esempio, <desc> su Chrome e Safari genera automaticamente un paragrafo a comparsa che Firefox, Internet Explorer e Opera non prevedono. Il problema maggiore è provocato dai CSS che controllano la visualizzazione delle pagine web perché nonostante siano standard vengono interpretati in modo differente dai diversi engine. A prescindere da quanto il browser sia affidabile o recente.

Ho parlato di engine e qualcuno, giustamente, potrebbe essersi chiesto cosa siano. Siamo abituati a distinguere i browser col loro nome commerciale, però ciò che li differenzia davvero è il “motore” per la visualizzazione delle pagine web: i principali engine sono quattro.

  1. Gecko (Firefox)
  2. Presto (Opera)
  3. Trident (Internet Explorer)
  4. WebKit (Chrome, Safari)

Ognuno di essi interpreta i sorgenti dei siti in modo diverso e lo stesso engine potrebbe implementare una determinata funzionalità dei CSS in una versione e non in un’altra.

Quella delle versioni è una questione annosa che riguarda soprattutto Internet Explorer perché gli utenti di tutti gli altri browser sono più abituati a effettuare aggiornamenti frequenti. Ovviamente, la diffusione dei dispositivi mobili ha complicato la situazione: per esempio, la grave frammentazione di Android obbliga i designer a considerare diversi rilasci di WebKit a seconda della versione del sistema operativo. In genere, comunque, fino ai CSS2.1 l’unico problema davvero fastidioso è l’interpretazione dei margini con IE.

Un aspetto più sofisticato, sempre fino ai CSS2.1, concerne i web font perché Internet Explorer richiede un formato specifico che non è supportato dagli altri. A partire dai CSS3, però, il problema diventa quasi insormontabile: il W3C stabilisce degli attributi standard, ma i produttori intervengono con prefissi che potrebbero avere una sintassi diversa e sono riconosciuti soltanto dal singolo engine. WebKit è il progetto che innova di più, da questo punto di vista, ed è contemporaneamente quello che crea maggiori problematiche.

CSS3 aggiunge alle caratteristiche degli standard precedenti la possibilità di creare effetti tridimensionali, ombreggiature, animazioni e altri elementi tipici dei siti più accattivanti. Purtroppo, non siamo ancora arrivati a un’omogeneità nell’interpretazione: ciò che funziona su WebKit potrebbe non funzionare sugli altri engine. Esistono degli hack per assicurare il riconoscimento delle proprietà su tutti i browser, ma corrompono la validazione dei sorgenti e devono essere costantemente rivisti all’aggiornamento dell’engine.

Com’è possibile affrontare il problema e ottenere un risultato soddisfacente? Per fortuna, alcuni dei software indispensabili alle startup sono utilissimi per avere un riferimento aggiornato: HTML5 Boilerplate include Normalize.css che reimposta ogni engine, affinché interpreti il codice allo stesso modo. Inoltre, propone Modernizr che controlla quali proprietà sono supportate e genera gli accorgimenti necessari a sopperire le carenze dei browser più datati. Tuttavia, non aspettatevi che queste risorse diano risultati perfetti.

I quattro engine che ho citato sono soltanto la punta dell’iceberg. Ognuno di essi, infatti, può implementare delle soluzioni differenti per interpretare JavaScript o visualizzare i caratteri: concentriamoci su quest’ultimo aspetto. Gecko adotta su Windows un motore di rendering dei font diverso da quello implementato su Mac OS X o Linux. Presto, Trident e WebKit adottano soluzioni ancora differenti. Per esempio, lo stesso carattere alla stessa dimensione su Chrome e Safari è normalmente 1px più alto rispetto agli altri browser.

Né HTML5 Boilerplate, né jQuery o altre librerie possono risolvere questo problema perché non dipende dai CSS. Sono i framework integrati nei vari browser e compatibili coi diversi sistemi operativi a fare la differenza: se come me siete particolarmente pignoli… potreste passare invano delle notti insonni a cercare una soluzione inesistente. Se applicazioni e siti non sono ancora la stessa cosa è proprio perché adattare uno stile alle singole app “native” risulta più semplice che averne uno valido per tutti i browser esistenti.

Photo Credit: Phillie Casablanca via Photo Pin (CC)