Otto aspetti da curare per un sito mobile su Windows Phone 8

Sviluppare per il web mobile finora è stato come esplorare una piccola isola felice, certo con pericoli nascosti a causa della elevata frammentazione su Android, ma da quando i sistemi del robottino e della mela si sono prepotentemente imposti sul mercato, con i loro browser predefiniti basati su WebKit, abbiamo avuto un momento di respiro.

Micro$oft però non è rimasta a guardare, Windows Phone sta acquisendo maggiore visibilità, ed il vecchio nemico si è infine affacciato anche sui dispositivi mobili, ebbene si perché Windows Phone 8 significa Internet Explorer, mobile ma comunque basato sul motore proprietario Trident presente anche su IE10 desktop e sui tablets surface, ciò significa solo una cosa : bugs.

Se credi che il tuo sito ottimizzato per iPhone e Android si veda benissimo anche su un Lumia nuovo di zecca, questa è la lista di problemi che sicuramente dovrai affrontare.

Il Viewport deve essere specificato via CSS, il meta non funziona

La gestione del viewport su smartphone ha una storia travagliata, mentre il settore doveva ancora nascere il W3C aveva creato come linea guida la gestione attraverso media query, inquadrando il viewport come una propriet√† visuale. Tuttavia Apple nel 2007 aveva fretta e non poteva aspettare che in seno a webkit si stabilizzase la specifica CSS per cui opt√≤ come linea guida di sviluppo dei siti mobile per i loro nuovi fiammanti iPhone l’uso del tag meta.

Microsoft questa volta si è adattata alle specifiche W3C, è vero, ma ignorando completamente lo standard de facto del settore, per cui se Chrome su smartphone renderizza correttamente il viewport della pagina specificato sia tramite meta che tramite CSS, su Internet Explorer mobile funzionerà solo se specificato via CSS, della serie come la fai la sbagli. Ricorda quindi di inserire nel tuo CSS, possibilmente tra le primissime regole, le seguenti righe :

Una cosa da notare è che su Chrome desktop, in modalità emulazione smartphone, la compresenza delle due regole da luogo a degli strani comportamenti con testi randomicamente troppo grandi o troppo piccoli. Gli ultimi test che ho effettuato sia su Safari iOS 7 e Chrome KitKat non hanno dato luogo a queste stranezze ma per evitare spiacevoli sorprese è preferibile utilizzare il prefisso -ms-.

Se la larghezza del¬†Viewport √® equivalente alla larghezza del dispositivo l’evento JavaScript resize non funziona

Questa √® la cosa pi√Ļ strana, e grave, che ho constatato su Windows Phone 8.1 (build 8.10.12397.895) sul NOKIA¬†Lumia 630; impostando la larghezza del¬†viewport sui valori device-width o 100% si ottiene in entrambi i casi che ruotando il dispositivo l’evento resize non viene mai innescato, in questo modo nessuna delle funzioni registrate su tale evento viene eseguita.

Per essere sicuro che non fosse un problema di jQuery o della specifica versione che stavo utilizzando ho provato anche con il metodo vanilla addEventListener senza successo.

Anche se poco elegante, ho pensato di aggirare il problema facendo affidamento al metodo $.resize() proxando la funzione in modo da inserire al suo interno un setInterval che entrer√† in funzione solo su Windows Phone, il quale verificher√† periodicamente che la larghezza rilevata non sia cambiata ed in caso contrario esegue la callback che sarebbe stata eseguita dall’evento resize.

Puoi testare il comportamento dalla seguente pagina di test : http://test.simonerescio.it/wp81resize.html

Il colore di selezione degli elementi interattivi si può solo disabilitare a livello di pagina

Ricordi la propriet√†¬†-webkit-tap-highlight-color che ti permetteva di decidere a livello del singolo elemento se inibire l’effetto o modificarne il colore con valori RGBA?¬†√ą inutile che tenti con¬†-ms-tap-highlight-color o altri prefissi disperati, non funzioner√†.

L’unica cosa che Windows Phone permette di fare √® disabilitare l’effetto a livello di pagina, su tutti gli elementi con un meta proprietario :

Inoltre per funzionare il meta deve essere presente da subito nell’head della pagina HTML che viene inviata al client, aggiungendolo via JavaScript in runtime non funzioner√†.

Bisogner√† poi armarsi di pazienza e fornire una controparte :hover per dare un minimo di feedback all’utente.

Gli eventi touch devono essere mappati sul modello pointerEvent

Al fine di unificare la gestione degli eventi a prescindere dalla sorgente MicroSoft ha sottoposto al W3C il modello pointerEvent che¬†all’atto pratico richiede di mappare gli eventi registrati sul modello touch anche sul modello di MicroSoft, come illustrato sulla pagina ufficiale :

jQuery non supporta ancora questo modello di eventi, motivo per il quale bisogna usare addEventListener e l’adattamento potrebbe non essere indolore.

Le maschere di ritaglio CSS non sono supportate

Se come me hai usato¬†la propriet√†¬†mask-image per creare un loader sappi che IE non l’ha mai supportata, e ancora non la supporta, avrai bisogno di un fallback png trasparente :

Creare effetti sfumati con le font icon non è possibile

Per creare un effetto¬†visivo di rilievo con una font icon CSS il metodo che ho utilizzato fin ora¬†consiste nel duplicare il simbolo con uno pseudo elemento che si sovrappone all’originale, impostare il colore trasparente in modo da lasciare visbile solo il colore della propriet√† text-shadow a cui applico una sfumatura.

Ebbene su Explorer, a prescindere dalla versione, questo effetto non funziona perch√© qualora si imposta un valore di sfumatura per la propriet√† text-shadow l’opacit√† dell’elemento viene regolata dal valore alpha della propriet√† color, intuitivo eh?

1

I testi all’interno di elementi interattivi vengono selezionati troppo velocemente

Un comportamento abbastanza fastidioso √® il fatto che toccando un elemento a cui corrisponde un azione, se il tocco cade proprio sul testo al suo interno questo viene immediatamente evidenziato per l’operazione di copia. Si pu√≤ inibire usando¬†la propriet√† user-select.

Developer Tools, 404

q2C0GO7Se hai avuto lo stomaco forte di leggere fino a qui pensando che “ok, ci sono tanti problemi da risolvere ma ci saranno anche degli strumenti nativi per debbuggare“, devo deluderti, siamo tornati ai tempi di IE6 in cui il miglior strumento di debug √® il tasto F5.

Ad oggi non c’√® uno strumento nativo di MicroSoft per ispezionare il DOM di Explorer mobile¬†ne una REPL JavaScript per capire se qualcosa va storto, l’unico strumento valido attualmente √® weinre, recentemente reso compatibile anche per Windows Phone, con tutti i limiti del caso (no breakpoints, no supporto agli pseudo elementi CSS etc).

  •  
  •  
  •  
  •  
  •  

https://sresc.io/1aw

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *