Quando nei nostri corsi introduciamo i principi di base del design reattivo (o adattivo), spieghiamo che si tratta di un tipo di design con relativo sviluppo del codice, che consente di ridisporre gli elementi della struttura di pagina ed i rispettivi contenuti in funzione della viewport del dispositivo su cui il sito viene visualizzato (in parole più semplici e con una certa dose di imprecisione: in funzione dello spazio disponibile).

Questa affermazione costituisce una valida approssimazione di partenza ma è incompleta.

Innanzitutto occorre considerare che esistono due possibili approcci:

1. la tecnica Mobile-First: disegnare la struttura di pagina per i dispositivi mobili, poi svilupparla per le viewport di dimensioni maggiori;
2. la tecnica opposta, ovverosia disegnare per una viewport corrispondente ad uno schermo da tavolo, poi aggiungere le regole (media query) per i dispositivi mobili.

I sostenitori di 1) motivano la loro scelta con la diffusione capillare dei dispositivi mobili al punto che questi vengono usati più dei tradizionali PC da tavolo per navigare Internet.

Chi preferisce la soluzione 2), invece, si basa più che altro su un presupposto di tipo logico: fino a poco tempo fa non esistevano le media query quindi si creavano i layout a dimensione fissa o variabile ma comunque partendo da una certa risoluzione orizzontale “ottimale” dello schermo, per cui è normale partire comunque da tale riferimento e poi considerare le viewport minori (tablet e smartphone) introducendo un certo numero di breakpoint.

Occorre anche aggiungere che è possibile aggiornare i siti esistenti – purché non troppo vecchi – modificandone il DTD in HTML5 ed aggiungendo le media query in modo tale che divengano reattivi. In questo tipo di interventi si procede per forza di cose secondo la tecnica 2).

A prescindere dalla prassi individuale, è possibile integrare la definizione di partenza aggiungendo che: nel design reattivo, è possibile prevedere che alcuni contenuti di pagina vengano visualizzati o meno in funzione della viewport del dispositivo.

Non solo, quindi, riposizionare gli stessi elementi bensì mostrarne di aggiuntivi ovvero nasconderne alcuni in base allo spazio.

Una tecnica molto semplice che consente di ottenere questo risultato, è quella di impiegare la dichiarazione: display:none; all’elemento che si vuole nascondere in corrispondenza di una certa risoluzione video.

Come è noto, la proprietà display può avere diversi valori, per un elenco ed analisi completi si può vedere il sito W3C: www.w3schools.com/cssref/pr_class_display.asp

Uno di questi valori è appunto none che determina il risultato di non mostrare in alcun modo l’elemento a cui la proprietà è stata assegnata.

Facciamo un esempio piuttosto semplice. Ipotizziamo una pagina a 2 colonne con una certa quantità di contenuti ed il menu di navigazione collocato nella parte superiore della stessa.
Quando la pagina viene vista su uno smartphone, la seconda colonna scivola sotto alla prima e potrebbe essere necessario uno scrolling abbastanza lungo per arrivare in fondo.
Simmetricamente, tale scrolling sarebbe necessario anche per tornare al menu.
Questo problema non si palesa a risoluzioni video sufficientemente alte in cui lo scrolling è ridotto ed un secondo menu a fondo pagina costituirebbe una duplicazione.
E’ quindi ipotizzabile, tra le varie soluzioni possibili, replicare il menu di navigazione in fondo alla pagina mostrandolo solo quando questa viene visualizzata su un dispositivo avente una viewport ridotta.

Nel codice HTML avremo quindi, a fondo pagina:

…
<!– menu aggiuntivo a fondo pagina –>
<nav class=”menuFondo”>
<ul>
…
</ul>
</nav>
<!– /menu aggiuntivo a fondo pagina –>
…

e nel foglio di stile:

.menuFondo { display:none;} /* normalmente non viene mostrato */

poi tramite media query:

@media (max-width:480px) {

.menuFondo { display:block;}

}

L’obiezione fondamentale che viene mossa a questo tipo di tecnica è che il contenuto da mostrare/non mostrare si trova comunque nel codice per cui, anche quando non viene mostrato, potrebbe appesantire il caricamento della pagina. Questa obiezione può essere valida qualora il contenuto in questione richieda una quantità elevata di codice e/o venga ripetuta più volte nella stessa pagina, viceversa il suo impatto è trascurabile. Le tecniche alternative sono basate su javascript/jquery e sono pertanto più complesse.