Come già affrontato in altri numerosi post, adottare una logica di sviluppo basata sull’MVC può aiutare notevolmente lo sviluppatore a raggiungere tale obiettivo.

Un altro metodo molto utile per mantenere il codice scalabile e mantenibile, oltre che aumentare le performance dell’applicazione, consiste nell’utilizzo di sistemi di Javascript templating in stretta relazione con le view, che si occupano della rappresentazione visiva dei vari componenti dell’interfaccia.

I sistemi di templating Javascript consentono infatti di generare il markup dinamico di una determinata view (leggi questo articolo che ho scritto per YourInspirationWeb  per sapere come utilizzare una view con backbone.js) in base ai dati che gli vengono passati al momento della compilazione.

Prima di entrare più nel dettaglio, vediamo quali sono solitamente le alternative adottate per la generazione di markup in una Mobile App sviluppata in HTML5, CSS3 e Javascript.

Come creare #MobileApp in #HTML5: il sistema di #javascript templating
Click To Tweet

Creare Mobile App in HTML: come viene generato solitamente il markup

Siccome in una HTML5 Mobile App tutta la generazione del markup e degli elementi DOM dell’interfaccia avviene tramite linguaggio lato-client, e quindi tramite javascript, generalmente si tende a seguire 3 strade principali per inserire il codice HTML di ogni schermata (o view) all’interno del progetto:

1 – Effettuare chiamate ajax che restituiscono dati HTML da un server remoto.

Rappresenta secondo me il tipo di approccio più sbagliato.

Stiamo parlando di applicazioni mobile e ciò comporterebbe il trasferimento di una grande quantità di dati e tempi di attesa più lunghi, soprattutto se l’utente sta usando l’applicazione in una zona fisica in cui il traffico è limitato o quasi assente.

Senza contare il fatto che il codice restituito (stringa formata dall’HTML generato dal server) risulta difficile da interpretare per l’applicazione JavaScript, e solitamente necessita di un’adeguata formattazione prima dell’immissione all’interno del documento.

La comunicazione in remoto dovrebbe essere pertanto utilizzata solo al fine di reperire o inviare dati “puri” (come per esempio un oggetto JSON).

2 – Inserire l’HTML di tutte le schermate nel documento

Per creare una Mobile App in HTML si utilizza un file principale index.html. 

Secondo questo metodo all’interno di quel file viene inserito tutto il markup necessario per far funzionare l’applicazione, relativo a alle varie view che la compongono.

Può andar bene per progetti formati al massimo da 4/5 schermate, dopo di ché diventa facile smarrirsi nei meandri del codice HTML come un bambino di 3 anni in un bosco.

Se poi consideriamo il fatto che in quelle view possiamo avere la necessità di inserire dati dinamici, per aggiungerli al DOM dovremmo comunque servirci di codice Javascript, utilizzando così non uno, ma due tipi di approcci diversi per lo stesso scopo (1 – html statico, 2 – generazione di markup via javascript).

Inoltre, inserire tutti i nodi DOM all’interno del documento riduce notevolmente le prestazioni di rendering, a causa del numero di elementi HTML per i quali la CPU è costretta a ricalcolare gli stili nel momento in cui si verifica qualsiasi modifica CSS, oppure ogni volta che un elemento si sposta nello schermo (quando ciò questo accade vengono coinvolti nello spostamento anche altri nodi del documento).

3. Generare codice tramite javascript con una concatenazione di stringhe

E’ provato che creare grandi blocchi di codice HTML tramite una concatenazione di stringhe riduce drasticamente la velocità per le prestazioni di esecuzione, in quanto la variabile in-memory utilizzata per svolgere tale operazione va ad occupare parte della CPU.

Coloro che adottano questa tecnica inoltre, si perdono spesso in cicli nidificati in cui non si capisce quale tag chiude l’altro, e dove non si riesce a distinguere dati puri dall’HTML.

Ecco un possibile esempio di questa tecnica:

var markup = "<div class=\"main-wrapper\">"+
				"<header class=\"page-header\" role=\"header\"><h1 class=\"\"></h1></header>"+
				"<section class=\"page-section\"></section>"+
				"<ul class=\"contacts-list\">";

			for(var i=0;i<contacts.length;i++){
				markup+="<li class=\"contact-list-item\">"+contacts[i].name+" "+contacts[i].surname+"</li>";
			}

			markup+="</ul></div>";

$(".content").append(markup);

E’ preferibile invece lasciare libera la memoria del dispositivo per le operazioni di rendering, che influiscono sulla user-experience del prodotto finale, così come è preferibile lasciare separati codice HTML da codice Javascript, in modo da aumentare la mantenibilità e la scalabilità del progetto e poter facilmente riutilizzare uno stesso template in diverse parti.

Creare Mobile App in HTML: il funzionamento dei sistemi di templating

Gli sviluppatori javascript hanno a disposizione diversi framework di templating per generare via client il markup HTML delle view che compongono le loro applicazioni (come per esempio Handlebars.js, Mustache, o il sistema interno al framework underscore.js).

Per conoscere anche altri sistemi di javascript templating, ti consiglio di leggere questo mio precedente articolo:

• I sistemi di javascript templating e le migliori librerie

I template possono essere savat in variabili in-memory, in file HTML indipendenti o all’interno del documento, solitamente racchiusi in tag <script> con un attributo “type” personalizzato (per esempio “text/template”:  “<script type=“text/template”> <!– markup del template —> </script>”).

[Tweet “Come creare #MobileApp in #HTML5: il sistema di #javascript templating
Click To Tweet

Ogni template ha accesso a delle variabili, a seconda dei dati che gli vengono passati.

Utilizzare le variabili è molto semplice e generalmente è possibile farlo all’interno di appositi delimitatori, il cui funzionamento non è molto diverso da quello della generazione del markup HTML dinamico tramite i più diffusi linguaggi lato-server (ASP, PHP, C# ecc.).

Il lavoro è reso ancora più facile per il fatto che la maggior parte di questi sistemi accetta dati in formato JSON (formato in cui può essere convertito facilmente qualsiasi tipo di dati).

I delimitatori delle variabili possono differire a seconda del framework utilizzato, ma il funzionamento logico rimane pressoché sempre lo stesso.

Due sono le categorie principali in cui si suddividono i vari tipi di sistemi di templating:

• embedded javascript, comprende i frameworks che permettono l’utilizzo di codice javascript all’interno dei propri template
• logic less, comprende quelli che non permettono l’utilizzo di javascript al loro interno, ma limitano l’uso di logiche come cicli e condizioni a sintassi personalizzate

Vediamo il funzionamento del sistema di templating di underscore.js, che appartiene alla prima categoria, e che può essere utilizzato per creare mobile app in html con il framework MVC Backbone.js.

Più concretamente, vediamo l’esempio di un ciclo che genera in maniera dinamica l’HTML necessario per mostrare una lista di individui.

Consideriamo di dover generare il markup della lista servendoci dei seguenti dati in formato JSON:

{
	'employees': [
		{‘name': ‘Giacomo Freddi’, occupation: ‘Web Designer / Front-End Developer’},
		{‘name': ‘Mario Rossi’, occupation: ‘CEO’},
		{‘name': ‘Franco Mancini’, occupation: ‘Web Marketer’},
		...
	]
}

Ecco come potrebbe presentarsi il template secondo il sistema di templating di underscore.js

<ul>
   <%for(var i=0;i<employees.length;i++){%>
   <li><%=employees[i].name%> - <%=employees[i].occupation%></li> 
   <%}%>
</ul>

In tal caso il risultato del markup generato sarebbe:

<ul>
   <li>Giacomo Freddi - Web Designer / Front-End Developer</li>
   <li>Mario Rossi - CEO</li>
   <li>Franco Mancini - Web Marketer</li>
   …
</ul>

Con i javascript templating lo sviluppatore ha sicuramente una cosa in meno a cui pensare, in quanto la maggior parte del lavoro di generazione del markup viene svolto dal sistema stesso.

Creare mobile app in HTML: i benefici del sistema di templating

Ciò porta ad un gran numero di benefici nel creare mobile app in HTML o qulasiasi single page application, in particolare se si decide di salvare i template di ogni view all’esterno del documento principale dell’applicazione (index.html), inserendo ognuno di essi in un apposito file (es.: nome-della-view.html).

Il contenuto del file viene poi caricato dinamicamente, solamente se e quando abbiamo bisogno di effettuare il render di quella view all’interno dell’interfaccia.

Quello appena esposto è il metodo che preferisco, in quanto permette di separare completamente all’interno del progetto il concetto di templating da tutto il resto (sinonimo di mantenibilità e scalabilità) e, nel senso più “fisico” del termine, ogni view dall’altra.

Così facendo è possibile mantenere la struttura dei file dell’applicazione ancora più organizzata.

Bisogna comunque  fare attenzione al fatto che i template non rappresentano di per sé delle view, bensì lo strumento grazie al quale esse possono effettuare il render del markup HTML che le rappresenterà all’interno del documento. Molti sviluppatori spesso confondono il concetto di view con quello di template, ma non sono assolutamente la stessa cosa.

Una view è un oggetto che che osserva un modello dati (in MVC i cosiddetti model) e mantiene la propria rappresentazione visiva aggiornata in base ad esso. Una view è definita da codice Javascript.

Il template potrebbe essere lo strumento di cui si serve la view per generare parte del proprio markup necessario alla visualizzazione, o di tutto il markup necessario.

Come creare #mobileapp in #HTML5 – i benefici del #javascript #templating
Click To Tweet

Conclusioni

Oltre che per creare mobile app in HTML o qualsiasi altro tipo di web app sviluppata in HTML, CSS3 e Javascript, i sistemi di templating sono molto utilizzati anche per la realizzazione di siti web che forniscono una user-experience di qualità molto elevata.

Solitamente gli sviluppatori front-end più affermati si servono di sistemi di javascript templating per generare markup da template salvati in file .html esterni, o dichiarati all’interno della pagina in appositi script personalizzati.

E tu hai mai utilizzato i sistemi di javascript templating? Ne hai privato qualcuno da suggerire? Scrivilo nei commenti e sarò felice di risponderti!

In altri articoli ho discusso l’importanza delle performance per quanto riguarda lo sviluppo di HTML mobile app tramite CSS3 e Javascript.

Durante la realizzazione di un’applicazione destinata a dispositivi mobile è importante sviluppare ogni effetto e animazione tenendo conto delle performance, fattore che su smartphone o tablet con sistemi operativi iOS, Android e Windows Phone diventa un vero e proprio must, se si vuole fornire all’utente un’interfaccia piacevole, fluida e reattiva.

In questo post voglio proporti il “modo performante” di realizzare una progress bar CSS3 con HTML5 e Javascript che risulti leggera ai fini del processo di rendering e piacevole all’occhio dell’utente, mentre egli interagisce con l’interfaccia.

Per capire meglio quali sono i punti chiave del codice CSS3, ma soprattutto la differenza visiva, ci soffermeremo su come scrivere la stessa animazione anche in modo poco performante.

Due progress bar CSS3 a confronto

Il mio principale intento con questo articolo, oltre quello di mostrarti diverse strade per realizzare lo stesso effetto, è sottolineare la differenza che si può avere agendo con due tecniche separate:

1. quella che sfrutta la composizione dei layer grafici (alta performance e fluidità)
2. quella che costringe il browser a ripetere l’intero processo di rendering per ogni keyframe dell’animazione (bassa performance e movimenti scattosi)

Al fine di comprendere meglio i concetti di processo di rendering e dei layer grafici ti consiglio di leggere rispettivamente questi due post (credimi, se sei un front-end developer ne vale proprio la pena):

1. Come ottimizzare le animazioni per i dispositivi mobile
2. Scrivere HTML Mobile App fluide con i layer grafici e l’accelerazione hardware

In questo esperimento realizzeremo quindi due progress bar CSS3, la versione fluida, e quella con scarse prestazioni.

Il markup HTML

Vediamo il (semplice) markup HTML delle due progress bar:

<!--
Progress bar fluida e performante
-->

<div class="progress-box fast">
	<div class="progress-inner"></div>
	<i class="fa fa-check"></i>
</div>

<!--
Progress bar scattosa e poco performante
-->

<div class="progress-box low">
	<div class="progress-inner"></div>
	<i class="fa fa-check"></i>
</div>

In particolare usiamo la div con classe .progress-box come contenitore principale, il quale presenta al suo interno la barra che sarà animata (classe .progress-inner) e l’icona che mostreremo alla fine dell’animazione, per comunicare all’utente che l’operazione (qualunque essa sia) è andata a buon fine.

Come puoi vedere dal codice l’unica differenza tra le due progress bar sono le classi “fast” o “low” applicate al contenitore principale progress-box; è grazie ad esse che assegneremo ai due elementi DOM degli stili diversi per realizzare lo stesso tipo di effetto.

Gli stili CSS3

Impostiamo gli stili per il contenitore (progress-box), per la barra da animare (progress-inner) e per l’icona di completamento dell’operazione: alla prima attribuiamo la proprietà position:relative, mentre alla seconda e alla terza position:absolute, in modo da poterle muovere all’interno del contenitore con più facilità (utilizzando gli attributi “top“, “left” ):

.progress-box {
	position: relative;
	background: #3BB563;
	height:30px;
	width:300px;
	margin:20px auto;
}

/*progress bar*/
.progress-box .progress-inner {
	position: absolute;
	top: 0;
	left: 0;
	height: 100%;		
	background: #0e7138;
}

/*icona dello stato completo della'animazione*/	
.progress-box i{
	position: absolute;
	top:7px;
	right:7px;
	color:#FFF;

	/*
		animazione molto leggera, sfrutta la creazione dei layers
		tramite le prop. opacity e transform, da caricare poi nella GPU;

		allo stato iniziale "nascondiamo" l'icona con l'opacity: 0
		e la trasliamo "indietro" di 30px
	*/

	opacity:0;		

	-webkit-transform: translateX(-30px);
	   -moz-transform: translateX(-30px);
	    -ms-transform: translateX(-30px);
	     -o-transform: translateX(-30px);
	        transform: translateX(-30px);

}

Allo stato iniziale l’icona, che non deve essere visibile fino al completamento dell’operazione, è stata impostata non visibile tramite la trasparenza (opacity:0) e traslata “indietro” di 30px tramite la proprietà CSS3 transform: traslateX(-30px) (con tutti i relativi prefissi del caso per la compatibilità).

Vediamo ora come animare la progressabar con classe low “alla vecchia maniera”, tramite codice poco perforemante:

.progress-box.low .progress-inner {

	/*
	la larghezza iniziale allo 0%;
	sarà poi modificata tramite Javascript e portata al 100%
	*/

	width: 0;

	/*
	animazione pesante, sfrutta la proprietà width: il browser deve ripercorrere tutto il 
	processo di rendering per ogni keyframe dell'animazione
	*/

	-webkit-transition: width 3s;
	   -moz-transition: width 3s;
	    -ms-transition: width 3s;
	     -o-transition: width 3s;
	        transition: width 3s;
}

Abbiamo agito sulla proprietà “width“, che fa parte del primo step del processo di rendering e che quindi costringe il browser a ripetere tale processo (eseguendo tutti gli step che lo compongono) ad ogni keyframe dell’applicazione, provocando un effetto di “sfarfallio”.

Passiamo ora invece a degli stili decisamente più performanti, quelli della progress bar con classe fast:

.progress-box.fast .progress-inner {

	/*
	la larghezza iniziale è gia al 100%;
	ma la prop. transform:scaleX è a 0; sarà poinportata tramite javascript 
	al 100% della sua larghezza impostando il valore 1
	*/

	width:100%;

   /*
	   impostiamo l'origine della trasformazione, 
	   che di defualt sarebbe al 50%, ma noi vogliamo che
	   inizi da sinistra (appunto 0)
   */	

   -webkit-transform-origin-x: 0;
   	  -moz-transform-origin-x: 0;
   	   -ms-transform-origin-x: 0;
   	    -o-transform-origin-x: 0;
   		   transform-origin-x: 0;

   -webkit-transform: scaleX(0);
      -moz-transform: scaleX(0);
       -ms-transform: scaleX(0);
        -o-transform: scaleX(0);
           transform: scaleX(0);

	/*
	animazione fluida e perfomante, sfrutta la proprietà transform, 
	che fa parte dell'ultimo step del processo di rendering del browser, 
	quello della creazione dei layer. Lo stile transform viene eseguito sulla 
	memoria grafica (la GPU) separatamente
	*/

	-webkit-transition: -webkit-transform 3s;
	      -moz-transition: -moz-transform 3s;
	        -ms-transition: -ms-transform 3s;
	          -o-transition: -o-transform 3s;
	                transition: transform 3s;
}

Qui realizziamo l’animazione impostando la proprietà transition in modo da agire sul transform, per forzare la creazione dei layer grafici, i quali fanno parte del terzo step del processo di rendering. Così facendo la creazione dei relativi effetti viene delegata alla memoria grafica (la GPU).

Il codice Javascript

Passiamo ora al semplice codice javascript per gestire gli eventi di azione sui pulsanti che avviano e resettano l’operazione (“#start” e “#reset“):

$("#start").on("click", function(){

	var fastProgressScale = "scaleX(1)";

	/*
	progress bar performante: 
	lavoriamo sulla prop. "transform" che fa parte del 3° step 
	del processo di rendering, e forza la creazione di un layer 
	da delegare alla GPU (alleggerisce il carico di lavoro)
	*/
	if(!$(".progress-box.fast").hasClass("complete"))		    	
    	$(".progress-box.fast .progress-inner")
    	.css({
	    	"-webkit-transform": fastProgressScale,
	    	"-moz-transform":    fastProgressScale,
	    	"-ms-transform":     fastProgressScale,
	    	"-o-transform":      fastProgressScale,
	    	"transform":          fastProgressScale
    	})		    	
    	.one(transitionEventName, function(){
	    	$(".progress-box.fast").addClass("complete");
    	});	

	/*
	progress bar poco performante: 
	lavoriamo sulla prop. "width" che fa parte del 1° step 
	del processo di rendering 
	*/
	if(!$(".progress-box.low").hasClass("complete"))
    	$(".progress-box.low .progress-inner")
    	.css("width", "100%").one(transitionEventName, function(){
	    	$(".progress-box.low").addClass("complete");
    	});		    	

});

$("#reset").on("click", function(){		    	

	//rimettiamo i due stati a 0

	var fastProgressScale = "scaleX(0)";
	$(".progress-box.fast").removeClass("complete")
	.find(".progress-inner").css({
    	"-webkit-transform": fastProgressScale,
    	"-moz-transform":    fastProgressScale,
    	"-ms-transform":     fastProgressScale,
    	"-o-transform":      fastProgressScale,
    	"transform":          fastProgressScale
	});

	$(".progress-box.low").removeClass("complete")
	.find(".progress-inner").css("width", "0"); 

});

Al click del pulsante #start impostiamo semplicemente la proprietà width al 100% per la progress lenta, e la proprietà “transform:scaleX” ad 1 (che equivale al 100% ) per la progress fluida.

Al click del pulsante “#reset” riportiamo le due progress bar ai valori iniziali, avendo come risultato un’animazione con effetto contrario.

Conclusioni e considerazioni

Con la demo è possibile visualizzare la grande differenza tra la progress bar scritta in modo performante e quella scritta in modo poco performante: la prima risulta fluida e piacevole visivamente, mentre la seconda è scattante e presenta un notevole sfarfallio (ti consiglio di visualizzare l’esempio in un dispositivo mobile).

In un’eventuale HTML mobile app (ma anche in qualsiasi web app che sfrutta le funzionalità dei CSS3), impiegare più effetti con scarse performance, oltre ad una user-experience sgradevole, può provocare crash continui dell’applicazione, e incidere notevolmente sul giudizio che gli utenti attribuiscono al nostro prodotto (con conseguente impatto negativo sulla community).

Dall’altro lato invece, se scriviamo le nostre animazioni CSS3 in modo da sfruttare correttamente il lavoro della GPU, avremo come risultato un’applicazione piacevole, fluida e performante, e la differenza con quelle native sarà pressoché inesistente.

Come sicuramente avrai capito leggendo i miei post, ho un vero e proprio debole per le mobile web app e per l’impiego dei CSS3 al fine di rendere più piacevole la user-experience delle mie interfacce.

Con il miglioramento costante delle caratteristiche hardware dei dispositivi mobili è possibile avvicinarsi sempre di più alle prestazioni di applicazioni native, realizzando effetti come animazioni e transizioni puramente in CSS3.

Inserire nelle web app elementi come touch sliders, slide menu, pull-to-refresh scroll, e molti altri componenti che siamo ormai abituati a vedere nelle applicazioni native, diventa quindi meno complicato.

L’impiego nei siti web

Effetti del genere ovviamente non sono limitati soltanto a smartphone o tablet, ma si possono implementare anche nei “classici” dispositivi desktop. Numerosi web designer e developer li inseriscono per esempio nei propri progetti per renderli più piacevoli e per stupire in modo originale il visitatore.

In questo articolo ti voglio parlare proprio di come realizzare un CSS3 slide panel menu, effetto che ho trovato ultimamente in molti siti web, e che può essere utilizzato in tutti i dispositivi.

Quello che realizzeremo in questo tutorial è quindi un menu CSS3 slide panel, che appare o scompare al click su uno specifico pulsante.

Squarespace usa la tecnica dello slide menu nel proprio sito

Uno degli aspetti fondamentali che caratterizzerà il risultato finale è l’introduzione, se pur a livello base, di un concetto molto importante nell’ambito della compatibilità: il miglioramento progressivo tramite CSS3 (o CSS3 Progressive Enhancement).

Il Progressive enhancement è una strategia impiegata nel web design che utilizza le tecnologie web a più livelli, per permettere a chiunque di accedere a contenuti e funzionalità di base del sito (o della web app) indipendentemente dal browser o dalla connessione utilizzata, fornendo anche una versione migliorata della pagina per coloro che dispongono di un browser più avanzato o maggiore larghezza di banda.

Fonte: Wikipedia

Per quanto riguarda il nostro esperimento, la tecnica di base consisterà nel basare l’animazione dello sliding panel sulla proprietà left per i browser che non supportano le css transform, mentre sulla proprietà translate3d per quelli che la supportano.

Così facendo potremo guadagnare in termini di fluidità e le prestazioni (per capire quali sono gli attributi sui quali agire per migliorare fluidità e prestazioni ti consiglio di leggere: Performance CSS3: consigli per ottimizzare le animazioni).

Ma veniamo al punto.

Il markup HTML

<!-- Menu -->
<nav class="menu">

	<!-- Menu Wrapper -->
	<div class="menu-wrap">
		<span id="menu-close">x</span>
		<a href="index.html">Home</a>
		<a href="services.html">Services</a>
		<a href="portfolio.html">Portfolio</a>
		<a href="about.html">About</a>
		<a href="#contact">Contact</a>
	</div>

	<!-- Menu button -->
	<button id="toggle" title="Menu Toggle">Toggle</button>
</nav>

<!-- contenuto pagina -->

<div class="main-wrapper">			
	<!-- contenuto della pagina -->	
</div>

Gli stili CSS

Vediamo gli stili per il wrapper principale del menu:

/* 
	stili del menu
	impostiamo la position a fixed con un right di -200px (il menu "a riposo" 
	esce dalla pagina a destra per un numero di pixel pari alla sua larghezza)
*/
.menu {
    position: fixed;
    right: -200px;
    width: 260px;
    height: 100%;
    top: 0;
    z-index: 10;
    text-align: left
}
/*
	serve per far muovere anche il body nel caso in cui il browser non supporta le CSS transform
*/
body {
    overflow-x: hidden;
    position: relative;
    left: 0;
}

Ora impostiamo gli stili del menu-wrapper che è contenuto all’interno del panel menu principale, quelli del pulsante di chiusura (id=”menu-close”), e quelli del pulsante “toggle”:

/* 
	impostiamo gli stili dell'elemento wrapper che contiene il menu 
*/
.menu-wrap {
    position: absolute;
    top: 0;
    /* impostiamo un left di 60px per dare 'spazio' al pulsante '#toggle' */
    left: 60px;
    background: #1a1a1a;
    width: 200px;
    height: 100%;
    padding-top: 20px;
    -moz-box-sizing: border-box;
    box-sizing: border-box;
}

/*
	impostiamo gli stili dei link del menu	
*/
.menu a {
    margin-left: 20px;
    color: gray;
    display: block;
    font-size: 12px;
    font-weight: 700;
    line-height: 40px;
    letter-spacing: .1em;
    text-transform: uppercase;
}
.menu a:hover {
    color: #fff
}
.menu a:active {
    color: #fff
}
.menu a>i {
    float: left;
    display: inline-block;
    vertical-align: middle;
    text-align: left;
    width: 25px;
    font-size: 14px;
    line-height: 40px;
    margin: 25px 2px
}

/*
	impostiamo gli stili e posizioniamo il pulsante di chiusura che si trova all'interno del paneò
*/

#menu-close {
    cursor: pointer;
    display: block;
    position: absolute;
    font-size: 18px;
    font-weight: bold;
    color: gray;
    width: 40px;
    height: 40px;
    line-height: 40px;
    top: 18px;
    right: 5px;
    -webkit-transition: all .1s ease-in-out;
    -moz-transition: all .1s ease-in-out;
    -ms-transition: all .1s ease-in-out;
    -o-transition: all .1s ease-in-out;
    transition: all .1s ease-in-out
}
#menu-close:hover {
    color: #fff;
}

/*
     posizioniamo il pulsante toggle
*/
#toggle{
    position: absolute;	
    top: 25px;
    right: 265px;
    display: block;
    min-width: 110px;
    text-align: right;
    z-index: 11;
    font-size: 18px;
    font-weight: 700;
    color: #FFF;
    text-transform: uppercase;

    padding:0;
    background: none;
    margin:0;
    border:0;
}

Ora impostiamo gli stili del contenuto principale della pagina:

/* stili del contenuto della pagina */

.main-wrapper {
    background: url(../img/header-bg1.jpg) no-repeat center top;
    margin-top: 0px;
    padding-top: 130px;
    text-align: center;
    background-attachment: relative;
    background-position: center center;
    height: 100%;
    width: 100%;
    -webkit-background-size: 100%;
    -moz-background-size: 100%;
    -o-background-size: 100%;
    background-size: 100%;
    -webkit-background-size: cover;
    -moz-background-size: cover;
    -o-background-size: cover;
    background-size: cover    
    -moz-box-sizing: border-box;
    box-sizing: border-box;
}

Infine, ecco il punto focale del nostro esperimento, dove avviene “la magia”, ovvero il momento in cui scegliamo quale proprietà modificare oper effettuare l’animazione in base alla compatibilità del browser:

/*
	in questa situazione, quindi quando il browser NON supporta le CSS3 transform, 
	muoviamo la reale posizione del menu da fuori dallo schermo al suo interno, agendo sulla 
	proprietà "left"
*/
body:not(.with-translate).open {
    left: -200px;
}

/*
	in questa situazione, quindi quando il browser supporta le CSS3 transform, 
	lasciamo la reale posizione del menu fuori dallo schermo, mentre la trasliamo 
	al suo interno di 200px;
*/
body.with-translate.open {
    left: 0;    
    -webkit-transform: translate3d(-200px , 0 , 0);
    -moz-transform: translate3d(-200px,0,0);
    -ms-transform: translate3d(-200px,0,0);
    -o-transform: translate3d(-200px,0,0);    
    transform: translate3d(-200px,0,0);    
}

/* 
	impostiamo infine la transition ad all	per comprendere sia quella sulla proprietà "translate3d" che sulla proprietà "right"
*/

/* 
	se il browser non supporta le CSS3 transform, utilizziamo 
	la proprietà "right" per creare il nostro effetto 
        sull'elemento del menu
*/
body:not(.with-translate) .menu.open {
    right: 0
}

/* 
	altrimenti la proprietà right dovrà avere lo stesso valore negativo 
	in quanto useremo la proprietà translate per l'animazione 
*/

body.with-translate .menu.open{
	right:-200px;
}

/*
	nel caso in cui si tratta di ie10 attribuiamo la translate anche al menu, 
	che in questa versione non si sposta insieme al body (maledetto IE!)
*/
body.ie10.with-translate .menu.open {
    -webkit-transform: translate3d(-200px , 0 , 0);
    -moz-transform: translate3d(-200px,0,0);
    -ms-transform: translate3d(-200px,0,0);
    -o-transform: translate3d(-200px,0,0);    
    transform: translate3d(-200px,0,0);    
}

/*
       impostiamo la durata delle animazioni per il menu ed il body con 'all'
       in modo da agire sia sulla proprietà 'transform' che sulla proprietà 'right'
*/
.menu, body{
    -webkit-transition: all .3s ease;
    -moz-transition: all .3s ease;
    -ms-transition: all .3s ease;
    -o-transition: all .3s ease;
    transition: all .3s ease
}

Qui vengono definite le due differenti tecniche di animazione distinte in base alla classe del body: se esso ha la classe “with-translate” (significa che il browser supporta la proprietà CSS transform), allora animeremo body e menu traslandoli con la l’attributo “transform: translate3D“, altrimenti lo faremo agendo sulla proprietà “right”.

Il file Javascript

Infine qualche riga di codice per aggiungere o togliere la classe “open” dal body e dal menu, all’evento “click” dei pulsanti desiderati. Controlliamo inoltre, sfruttando modernirz ( che ho incluso nel documento, puoi verificarlo scaricando il codice sorgente), se il browser supporta le CSS transform oppure no (in caso positivo aggiungiamo la classe “with-translate” al body).

$(function(){

	/* 
		grazie a modernizr, controllando le classi del tag HTML 
		possiamo sapere se il browser supporta la transition3d		
	*/
	var supportCssTransforms = $("html").hasClass("csstransforms3d");

    /*
	    se la supporta aggiungiamo la classe 'with-translate' al body, 
	    in modo da poter differenziare la modalità d'effetto tramite CSS
    */
	if(supportCssTransforms){
    	$("body").addClass("with-translate");
	}

        /*
		se si tratta di IE 10 aggiungiamo la classe per il workaround 
		(la condizione di controllo può essere migliorata)		
	*/
	if(navigator.userAgent.indexOf("MSIE 10.")!=-1){
		$("body").addClass("ie10");
	}

	/*
		impostiamo sugli elementi desiderati l'evento click in modo da 
		aprire o chiudere il menu aggiungendo o togliendo la classe "open"	
		al body e al menu stesso	
	*/
	$("#toggle, #menu-close").on("click", function(){
		$("body, .menu").toggleClass("open");		
	});

});

Ecco fatto: ora possiamo visualizzare un vero e proprio CSS3 slide panel menu con tanto di Progressive Enhancement per i dispositivi che non supportano le funzionalità CSS3 più recenti!

Se ti è piaciuto l’articolo, perché non lo condividi?

Da sempre il web designer/developer deve sostenere la famosa dura lotta della compatibilità browser, con un occhio di riguardo soprattutto per Internet Explorer, ed in particolar modo per l’utilizzo delle numerose funzionalità CSS3, che contribuiscono ad incrementare la qualità e la user experience di ogni interfaccia.

Negli ultimi tempi l’interpretazione di animazioni, transizioni e altre proprietà CSS3 su tutti i browser sembra una meta sempre meno lontana, per cui molti front-end developer, compreso il sottoscritto, cercano di impiegarli il più possibile all’interno dei loro progetti.

Tuttavia nell’utilizzare funzionalità del genere bisogna fare attenzione alle performance CSS3 del dispositivo/browser su cui dovranno “girare”, in particolare se si tratta di quelli mobili, molto meno potenti rispetto ai desktop.

Un esperienza a riguardo

Recentemente ho sviluppato e pubblicato nell’App Store Tint, un’applicazione realizzata interamente con markup HTML5, animazioni CSS3 e l’ausilio di Backbone (che approfondirò in un articolo futuro), riscuotendo anche un notevole successo in fatto di download.

Ma perché ho introdotto Tint?

In questo articolo ti voglio parlare di una lezione importante nell’ottimizzare performance CSS3 di animazioni, transizioni ed effetti applicati ad elementi DOM, che ho personalmente imparato durante la mia esperienza nello sviluppo di Tint, la quale ha contribuito ad incrementarne notevolmente le prestazioni.

Nonostante sia da molto tempo che mi occupo di interfacce web, questa è stata la prima volta che ho avuto l’esigenza di ottimizzare al massimo le prestazioni in dispositivi che, per caratteristiche hardware, riescono difficilmente a supportare certi tipi di animazioni e transizioni.

Ho dovuto pertanto cambiare il modo di realizzare alcuni effetti che su smartphone si arrestavano o mostravano uno sfarfallio (quanto lo odio!), mentre per desktop non davano nessun problema.

Punto focale: il rendering

Quando parliamo di prestazioni su un browser, dobbiamo pensare in particolare al rendering e su come esso rappresenti la ragione principale per le scarse prestazioni derivanti dai nostri stili CSS3.

Mi spiego meglio:

i vari step che compongono il processo in base al quale il browser passa dalla “lettura” del DOM al “disegno” sullo schermo, si possono riassumere in 3 fasi principali, nell’ordine:

1. Calcolo dei stili: in questa prima parte vengono calcolate e definite tutte quelle proprietà che definiscono la morfologia dell’elemento, come width, height, margin, padding, font-size, top, left ecc.
2. Disegno dell’elemento: è il momento in cui l’elemento viene “arricchito” con proprietà come ombra, background, outline, border ecc..
3. Creazione dei layers: qui vengono creati i layer dei “disegni” appena creati, che si differenziano in due categorie: quelli per il render, i quali definiscono la struttura ad albero di elementi e sotto-elementi, e quelli grafici, che vengono creati ogni volta che la GPU viene chiamata in causa. Possiamo dire quindi che quest’ultimo processo interessa proprietà CSS3 come translate, transform, scale, rotate ecc..

La cosa più importante su cui soffermarsi è il fatto che queste tre operazioni vengono eseguite dal browser in coda. Per cui se ad un elemento DOM già disegnato sullo schermo, andiamo a modificare proprietà classificate nel primo punto, poi dovranno essere rieseguiti anche gli altri due step.

Se invece modifichiamo attributi appartenenti al secondo step, il browser si preoccuperà di eseguire anche il terzo step.

Infine, modificando proprietà classificate nell’ultimo step, il lavoro del browser sarà alleggerito notevolmente perché non dovrà rieseguire gli step precedenti.

Questo discorso vale in linea generale per tutti i tipi di browser, a parte il nostro solito amico/nemico Internet Explorer, del quale non abbiamo molte informazioni sul processo di rendering (confidiamo nelle future release).

Tutto questo per dire cosa?

Beh, se ho esposto bene il funzionamento di rendering, sarà facile darsi una risposta:

al fine ottimizzare al massimo le prestazioni di un’animazione bisogna fare in modo che il browser prenda la strada più corta per realizzarla.

Faccio un esempio banale.

Se dobbiamo spostare una div dalla parte superiore del documento a quella inferiore in modo animato, invece di applicare l’animazione all’attributo top o bottom, che costringerebbe il browser a ripetere tutte e 3 le fasi del processo per ogni singolo frame dell’animazione, la applicheremo alla proprietà transform: translate ( o transform: translate3d) le quali interesseranno solo l’ultimo dei 3 step.

In questo modo aumenteremo in modo considerevole la fluidità degli effetti dei nostri progetti.

Dall’esempio possiamo vedere due modi diversi di realizzare la stessa animazione, con performance CSS3 completamente differenti.

Di seguito elenco le proprietà per ognuno dei tre (macro) step.

Step 1: calcolo degli stili

Step 2: disegno dell’elemento

Step 3: creazione dei layers

Conclusioni

Una volta preso in considerazione questo importante discorso, la fluidità delle animazioni e transizioni applicate ai vari elementi della mia app Tint è aumentata in modo considerevole, avvicinandosi sempre di più a quella di applicazioni native (se vuoi vedere il risultato l’app è scaricabile nell’app store).

Spero quindi che anche tu applicherai questo importantissimo concetto nel tuo prossimo lavoro.

Buon divertimento!

Nello sviluppo di un’interfaccia, sia essa progettata per una web app o per un sito web, le animazioni CSS3 stanno diventando uno degli ingredienti fondamentali. Grazie ad esse è possibile creare una user experience più gradevole e inevitabilmente un risultato finale di maggiore qualità (es.: la web page della mia nuova applicazione per iOS7: Tint).

Tuttavia usare stili CSS per creare delle animazioni non è sempre facile, soprattuto se si parla di importanti fattori come performance e compatibilità tra browser.

Combinare animation e transition (accompagnati dai relativi prefissi per i vari browser come -webkit-, -moz-, -ms- , -o-) con degli attributi sbagliati (affronteremo anche questo argomento in uno dei prossimi articoli) può infatti portare a problemi di sfarfallio, scatti e, soprattuto nel caso di dispositivi mobili o di effetti che prevedono lo spostamento ed il rendering di numerosi elementi DOM, ad un crash della nostra applicazione/sito web.

Dall’altro lato, l’operazione di scrittura di fogli per animazioni ed effetti in modo corretto può portare via diverse ore del nostro prezioso tempo.

In questo post voglio parlarti di animate.css, un’interessante raccolta di animazioni CSS3 cross-browser (ovviamente per browser ci si riferisce a quelli moderni), molto utile se si vuole realizzare effetti di svariato genere.

La libreria, un progetto di Daniel Eden, è stata creata al fine di far risparmiare del tempo a coloro che (come me) usano costantemente gli stessi tipi di animazioni, evitando l’inutile spreco di quel tempo che altrimenti sarebbe impiegato per organizzare i keyframes degli effetti di cui abbiamo bisogno.

Servendoci di animate.css avremo a disposizione tutti i tipi di animazioni più comuni come shake, bounce, swing, rotate e molti altri combinati tra loro, molto utili per implementare nei nostri lavori oggetti come modal, alerts, transizioni tra pagine ecc..

Dal sito web è possibile sia scaricare l’intero pacchetto che crearne uno personalizzato in base alle nostre esigenze, solo con gli effetti che vogliamo includere nel documento.

Ogni animazione è stata scritta in modo tale da poter essere eseguita su tutti i browser moderni come safari, mozilla, opera ed IE 10+ (per maggiori dettagli consulta questa tabella sulla compatibilità delle animazioni CSS3).

Ora potrai concentrati più su quali effetti scegliere per la tua interfaccia che sulla loro stessa creazione, buon divertimento!