La crisi di identità del pixel

Il pixel hardware#section1

Il concetto di pixel hardware ci è perlopiù familiare: si tratta del più piccolo punto che uno schermo può fisicamente mostrare ed è solitamente composto da dei sotto-pixel rossi, verdi e blu. La luce di questi tre sotto-pixel viene combinata insieme per creare i colori che vediamo. Dal momento che il pixel hardware è collegato ad un elemento fisico sullo schermo, non lo si può allargare, distorcere o suddividere. Queste proprietà rendono il pixel hardware simile all’atomo: l’unità del design su cui costruiamo tutto.

L’atomo di riferimento e la divisione degli atomi#section2

Le cose stanno cambiando per il pixel. Il W3C attualmente definisce il pixel di riferimento come lo standard per tutte le misure basate su pixel. Ora, piuttosto che basare ogni misurazione in base pixel sul pixel hardware, la si basa sull’unità di riferimento ottica, che può essere due volte più grande del pixel hardware. Questo nuovo pixel dovrebbe apparire uguale in tutte le situazioni in cui lo si visualizzi. Il bello dell’usare un pixel di riferimento è che prende in considerazione la vicinanza allo schermo: quando usate un telefono che tenete in mano vicino a voi, il pixel di riferimento sarà più piccolo sullo schermo piuttosto che su una proiezione che guardate da lontano. Se la persona che guarda lo schermo tiene il telefono in maniera tale che sia accanto alla proiezione, le dimensioni dei pixel dovrebbero apparire identiche, indipendentemente dalla risoluzione o dalla densità di pixel o dalla distanza da cui si guarda.

I pixel di riferimento sono stupendi, ma adesso ci troviamo con due definizioni contrastanti. I dispositivi Android hanno una nuova unità, chiamata “pixel indipendente dalla densità” o “dip” che gli sviluppatori possono usare per trovare su quanti pixel ottici si espande un oggetto. Questo permette agli sviluppatori di usare i pixel hardware per grafica e pattern usando px o la nuova definizione relativa di un pixel per la dimensione del testo e il dip per avere proporzioni consistenti tra tutti i device. Separare la definizione di un pixel in due unità va bene per Android ma il web ha a che fare con anni di design basati sul pixel per tutti i tipi di dispositivi. Sarebbe stato bello se i web developer avessero avuto anche queste unità, ma senza cambiare completamente la definizione di pixel, il web basato sul pixel andrebbe in pezzi. Immaginate cosa succederebbe se un iPhone 4 dicesse a un sito web di essere effettivamente 640px: il testo apparirebbe dimezzato, talmente piccolo che senza lo zoom quel sito web sarebbe quasi impossibile da leggere. Sarebbe impossibile usare tutti quei siti mobile che disabilitano lo zoom.

Fig. 1: Le dimensioni del pixel standard sul Galaxy Tab e sul Kindle Fire.

Inoltre, non possiamo sapere a priori la definizione di pixel usata da ciascun dispositivo e questo è un problema. Ad esempio, il Galaxy Tab originale ed il Kindle Fire hanno la stessa dimensione di schermo e la stessa risoluzione, ma i pixel sul Tab, che si aggiustano con il pixel di riferimento, misurano 1,5 volte quello del Fire, che usa il pixel hardware. Uno sviluppatore dovrebbe cercare le informazioni su questi due dispositivi e pensare che se gli schermi sono identici e utilizzano entrambe il rendering engine Webkit, allora il proprio sito apparirà uguale. Purtroppo però non è così: per quel che riguarda i siti, il Galaxy Tab è 400px x 683px e il Kindle Fire è 600px x 1024px.

Identificare i punti di rottura e andare avanti#section3

Di sicuro possiamo dire che c’è un problema con i pixel. Però possiamo usare le media query per identificare le inconsistenze e comportarci di conseguenza. Possiamo usare la media query device-pixel-ratio per identificare i dispositivi con i pixel scalati. Possiamo combinare questa informazione con le dimensioni per identificare i tipi di dispositivi con un certo grado di accuratezza. L’iPhone 4 ha una device-pixel-ratio di 2, pertanto misura il pixel come due volte più grande rispetto al pixel hardware. Molti dispositivi Android hanno una device-pixel-ratio di 1.5, quindi le cose sono scalate di un ordine e mezzo più grandi rispetto al pixel hardware. Attualmente, servono i prefissi, ma potete usare questa media query per cominciare ad identificare i dispositivi scalati.

La specificità è fondamentale quando si tratta di identificare le classi di dispositivi, ma dovete prestare attenzione: non siate mai così tanto specifici da individuare un singolo dispositivo e cercare di gestire solo quello nel caso ci siano altri dispositivi che hanno lo stesso problema. Dando un’occhiata al Galaxy Tab e ai dispositivi simili a questo, una device-pixel-ratio di 1,5 ci dà solo una parte di informazione. La maggior parte dei telefoni Android al momento ha questa stessa device-pixel-ratio e i conflitti qui possono portare ad altri problemi. Facendo una query sulla device-width per entrambe gli orientamenti ci verrà detto che questo è più largo di un telefono, ma non così largo come altri tablet che potrebbero uscire in futuro. Possiamo utilizzare device-width per identificare lo schermo, a differenza di width e height, che fanno query solo sulla viewport. Utilizzando le dimensioni del dispositivo, possiamo ottenere molte più informazioni sull’hardware in uso:

@media screen and (device-pixel-ratio: 1.5)
    and (device-width: 683px)
    and (orientation: landscape),
  screen and (device-pixel-ratio: 1.5)
    and (device-width: 400px)
    and (orientation: portrait)

Notate come device-pixel-ratio abbia bisogno del vendor prefix per funzionare, quindi aggiungendo -webkit- e -o- funzionerà nei browser Webkit e Opera.

Diamo adesso un’occhiata ai device come il Kindle Fire, che ha la stessa identica risoluzione hardware del Tab e usa i pixel basati sull’hardware. Avere a che fare con questi dispositivi è più difficile per è più probabile entrino in conflitto con i netbook e con altri schermi più grandi con una simile risoluzione così come con l’iPad. Usanto le media query orientation e max-device-height verranno individuati i device che ci servono. I dispositivi di solito danno come altezza un valore minore della loro effettiva device-height per fare in modo che i tablet 1024 x 768 non si identifichino con quelli sotto i 600px. Adesso stiamo guardando i tablet che hanno risoluzioni e dimensioni abbastanza consistenti:

@media screen and (device-pixel-ratio: 1)
    and (device-width: 1024px)
    and (max-device-height: 600px)
    and (orientation: landscape),
  screen and (device-pixel-ratio: 1)
    and (device-width: 600px)
    and (max-device-height: 1024px)
    and (orientation: portrait)

Fig. 2: Pixel normalizzati sul Galaxy Tab e sul Kindle Fire.

Utilizzare gli em al posto dei pixel vi darà molto controllo su come si scalerà il vostro sito, non solo sui caratteri, ma su tutto quello che prima aveva un valore basato sui pixel. Ora, tutto quello che dovete fare è cambiare il valore di font-size dell’elemento html. Far apparire il Kindle Fire come il Galaxy Tab è semplicemente una moltiplicazione della dimensione di base di 3/2 (1,5) nella media query del Kindle Fire. Se volete usare i pixel basati sull’hardware nel Galaxy Tab, moltiplicate la sua dimensione base per 2/3 (,666667). Dal momento che tutto è basato sugli em, il vostro sito scalerà in maniera relativa al font-size di base. L’esempio completo è in questo Gist. Cambiarlo a seconda del contesto può migliorare la consistenza tra le piattaforme.

Gestire le molteplici definizioni di pixel può essere complicato. Il pixel è l’unità base e questo spostamento verso il pixel ottico causerà delle stranezze. I produttori di device stanno facendo un lavoro abbastanza buono nell’identificare questi problemi e nel risolverli così da non doverlo fare noi stessi, ma qualcosa passerà sempre tra le crepe o conterrà delle inconsistenze. Fortunatamente, abbiamo gli strumenti per identificare e superare questi ostacoli fintanto che saremo coscienti di questo cambiamento.

Nota dell’editore: a questo articolo sono state aggiunte le informazioni riguardanti i vendor prefix in post produzione, per coprire i browser basati su Webkit e Opera.

Illustrazioni: {carlok}