HTML 5.1: belle novità per pagine ancora più dinamiche e responsive

Estensione del menù contestuale del browser, sommari, nuovi input per il tempo, immagini responsive con più sorgenti, validazione dei form più semplice tra le nuove feature che semplificheranno la vita degli sviluppatori. Ma è già prevista per quest’anno la versione 5.2

Due anni fa è uscito lo standard HTML 5 che ha riscosso un grande successo tra i webdeveloper. Si è trattato dell’aggiornamento più consistente dopo HTML 4.01. Ha permesso la scrittura di pagine web molto dinamiche e sta soppiantando gradualmente flash per la programmazione di videogiochi.

A due anni di distanza ecco un ulteriore aggiornamento.
Nel Novembre del 2016 è uscita la versione ufficiale di HTML 5.1 con altre novità molto interessanti che in questo articolo vedremo. La definizione di questo standard, va detto, non è stata semplice; infatti molte delle feature all’inizio previste sono state deprecate per una progettazione non ottimale che ha comportato un’insufficiente cross-compatibilità degli standard con i vari browser.

E non è finita. Il W3C sta già lavorando per la versione 5.2, la cui uscita è prevista già quest’anno, anche se in là.

Da qui in poi verranno illustrate le principali novità, alcune delle quali non sono ancora completamente cross-compatibili: qualcuna funziona su Chrome, altre su Firefox. Inutile dire che per testarle completamente è buona cosa avere i browser aggiornati all’ultima versione: dopo tutto lo standard in questione è uscito da un mese e mezzo appena.

Una stima di quanto il proprio browser supporti le features di HTML 5.1 la si può avere collegandosi al sito HTML5TEST. Tuttavia se una prova non ha successo con un browser è possibile utilizzarne un altro.

Sotto-menù da aggiungere al menù contestuale del browser

In alcune pagine web potrebbe essere necessario far apparire un nostro menù quando clicchiamo col tasto destro del mouse su un elemento specifico. Fino ad oggi, per fare questo, avremmo dovuto creare dei blocchi, i quali devono contenerne altri che facciano da sotto-menu, che a loro volta ne contengono altri ancora che facciano da voci. Successivamente avremmo dovuto forma al menù e ai sotto-elementi col CSS, in modo responsive, per poi impostare la funzione di comparsa e scomparsa del menù con Javascript, che può prevedere altre operazioni necessarie. Un gran lavorio, tenuto conto che la grafica e il funzionamento devono essere cross-browser, anche se in internet è possibile trovare dei framework adatti allo scopo.

HTML 5.1 ci semplifica il lavoro con la possibilità di creare dei sotto-menù che estendono il menù contestuale del browser al click del tasto destro su un determinato elemento.

I tag preposti sono <menu> e <menuitem> che, rispettivamente, creano un menù e le sue sottovoci. Quando il W3C inventò <menu> erano previsti 2 possibili type: context e toolbar. toolbar è stato poi deprecato ed è rimasto solo context.

Quindi, per impostare un menù, dovremo mettere almeno due attributi: type=”context” e l’id. L’id è fondamentale per collegare il menù alla premuta del tasto destro su un elemento, al quale aggiungeremo l’attributo contextmenu valorizzato con l’id del menù contestuale, a sua volta composto da uno o più <menuitem>, di tipo:

• checkbox, con una spunta da mettere o togliere sul singolo elemento;
• radio, selezionabile a scelta tra una serie di elementi radio, aventi lo stesso name
• command, utile a eseguire una funzione al click del mouse, associata con Javascript.

I <menuitem type=”checkbox”> e i <menuitem type=”radio”> funzionano esattamente come gli <input> dello stesso tipo dei form, quindi potremo usare checked per impostarli già selezionati e disabled per non permetterne la selezione. Con l’attributo label impostiamo una stringa diversa dal loro valore, ottenibile con Javascript mediante la proprietà innerHTML.

Si veda l’esempio qui sotto per comprendere meglio il funzionamento di <menu>.

Voci con approfondimento mediante <details> e <summary>

Poniamo l’esempio mostrato alla fine di questo capitolo.

Si tratta di una pagina che spiega la città di Milano fornendo diverse informazioni come Territorio, Clima, ecc… (qua per semplicità ne ho messe solo due, ma avrebbero potuto essere di più).
Di ogni voce viene mostrato solo il titolo e non il testo esteso che conferirebbe alla pagina un layout pesante e non utile a una ricerca mirata. Il visitatore ha quindi a disposizione tutti i capitoli e sceglie quale vuole approfondire, cliccandoci sopra per mostrare o nascondere il relativo contenuto.

Ogni capitolo è racchiuso in un <details>, il cui <summary> costituisce la parte sempre visibile e quella su interagire.

See the Pen esempio details and summary by Andrea Ronchetti (@andrearonchetti) on CodePen.

Nuovi tipi di input per il tempo: week, month, datetime-local

Sono sempre di più i siti che permettono la prenotazione di una cena al ristorante, di una camera d’albergo o quant’altro. In questi casi sono necessari degli input nei quali inserire la data e, spesso, anche l’orario.
I nuovi tipi di input previsti da HTML 5.1 fanno al caso; type=”week” serve per impostare la settimana di un determinato anno, month il mese e datetime-local la data e l’ora col fuso orario della zona del device che ha richiesto la pagina.

Su Chrome funzionano ma non su Firefox e viene mostrato, per questi input, il classico calendario con il mese e i giorni.

Ma è molto più facile capire con l’esempio sottostante il suo funzionamento nel dettaglio. Impostando una settimana, un mese o una data con l’orario, nei rispettivi input, sarà possibile leggerne il valore nel formato in cui viene impostato.

Immagini responsive e differenti sorgenti in base al pixel ratio o al viewport

Con l’avvento dei dispositivi mobile la questione delle immagini e della loro ottimizzazione per ogni ampiezza di schermo è divenuta vitale: quanto codice css impiegato per la resa ottimale delle immagini!
Poi c’è la questione della pesantezza: se l’immagine è troppo grande il dispositivo ci impiega più tempo per scaricarla, mentre se è troppo piccola risulta sgranata per gli schermi più ampi o quando lo zoom aumenta per volontà dell’utente. Allo scopo di caricare un’immagine da differenti sorgenti poteva venir utile un <div> con un background-image differente nei vari breakpoint, ma le sue dimensioni non tenevano conto di quelle delle immagini, con conseguenti problemi di impaginazione.

HTML 5.1 risolve la questione con due attributi aggiuntivi per <img>, non supportati da Chrome per il momento: srcset e sizes.
scrset permette di impostare differenti sorgenti di immagine in base al pixel ratio o al breakpoint.

Il pixel ratio è il rapporto tra i pixel fisici utilizzati dallo schermo per visualizzare un elemento e i pixel css.
Poniamo che un’immagine sia larga 200px. Di default il browser la visualizzerà utilizzando 200px fisici dello schermo. Se faccio lo zoom su di essa e la ingrandisco, per esempio, del doppio, l’immagine sullo schermo la vedo grande 400px, pur essendo di default ampia 200. Quindi il pixel ratio è 2 perché il rapporto è 400/200.

Analizziamo questo <img>

<img src="1x.jpg" style="border:1px solid red" srcset="1x.jpg 1x, 2x.jpg 2x, 3x.jpg 3x" />

src è sempre impostato poiché se srcset non è supportato dal browser verrà caricato il file di src, nel nostro caso 1x.jpg.
Se srcset è supportato, e ovviamente impostato, src viene ignorato e il file caricato per la visualizzazione dell’immagine è scelto dal browser in base al pixel ratio (fattore x) con questo criterio:

• con pixel ratio <=1 viene caricato 1x.jpg;
• con pixel ratio >1 && <=2 viene caricato 2x.jpg;
• con pixel ratio >2 viene caricato 3x.jpg (oltre 3x non è impostato nulla).

In questo modo posso far si che venga caricata l’immagine meno definita di default, più leggera, mente quella più pesante e più definita verrà richiesta solo quando l’utente ingrandisce lo schermo e quindi vuole vederla più dettagliatamente.

Qui sotto è possibile vedere un esempio completo di srcset impostato in base al fattore x.
Se non è possibile visualizzare le immagini nell’esempio scaricare la demo, decomprimerla e caricarla col browser. Questo vale per tutti gli esempi contenenti immagini.

Ottimizziamo un’altra immagine, questa volta in base al breakpoint.

<img src="montagne1000.jpeg" srcset="montagne500.jpeg 500w, montagne1000.jpeg 1000w" sizes="(max-width:500px) 90vw, 30vw" />

w rappresenta la grandezza del viewport. Quindi con un viewport <=500px verrà caricata montagne500.jpg, mentre >500 montagne1000.jpg.

Attenzione a un particolare. Col ridimensionamento della finestra l’immagine si stringe o si allarga, tenendo conto del rapporto tra i pixel del viewport e quelli fisici dell’immagine, quindi, nel nostro esempio, a larghezza 500px della finestra l’immagine sarà larga quanto la sua dimensione originale, per rimpiccolirsi proporzionalmente al restringimento della finestra. Stessa cosa dopo i 500px con l’immagine larga 1000px. A 1000px di larghezza finestra corrisponderanno 1000px di larghezza immagine (fisicamente è larga 1000px), il cui ridimensionamento, all’allargamento o al restringimento della finestra, avverrà in proporzione.

Tuttavia qui troviamo un altro attributo che è sizes, utile a stabilire la dimensione dell’immagine rispetto al viewport.
In questo caso è stato definito un breakpoint (come nel css) di 500px: se la grandezza della finestra è <=500px l’immagine sarà ampia 90vw, ossia il 90% del viewport, altrimenti il 30%.
Per viewport si intende la dimensione dell’immagine fisica, nello specifico.

Questi valori sono stati scelti poiché l’immagine sta in un articolo la cui ampiezza occupa il 90% del viewport: visualizzato negli smartphone sarà ampia tutta la larghezza del #container, che è 90%, mentre su tablet o su pc sarà ampia un terzo di #container, cioè il 30% rispetto al viewport.

Anche qui è visibile un esempio o una demo da decomprimere è scaricabile.

Il vantaggio di questa tecnica consiste nel non dover utilizzare il css per rendere responsive le immagini che spesso sono l’elemento più problematico da gestire in tal senso.

Con <picture> ulteriori possibilità di immagini ottimizzate per pixel ratio e breakpoint

Nell’esempio precedente abbiamo impostato delle immagini in base al pixel ratio o in base alla larghezza del viewport. Ora proviamo fare entrambe le cose, nel senso che per i dispositivi mobile utilizziamo un’immagine per un pixel ratio <=1, un’altra per un pixel ratio <=2 e l’altra per il >2.
La stessa cosa la facciamo per i desktop, ma utilizzando altre sorgenti, più pesanti ma più nitide per la visualizzazione su grandi schermi.

Ecco l’esempio (demo scaricabile)

In <picture> deve esserci sempre l’elemento <img> poiché <source> non è visibile ma definisce soltanto la sorgente da caricare secondo il breakpoint.
Il primo <source> è preso in considerazione se la larghezza della finestra è <=1024px, come nei dispositivi mobile.
Quindi se la larghezza della finestra è inferiore o uguale a 1024px, come nei dispositivi mobile, con un pixel ratio <=1 verrà caricata notte-stellata-mobile-1x.jpeg, con un pixel ratio <=2 notte-stellata-mobile-2x.jpeg e notte-stellata-mobile-3x.jpeg per un pixel ratio >2.
Il secondo <source> viene scelto se il viewport è > 1024px , come nei desktop.
In questo caso se l’immagine è ingrandita a 1x viene caricata notte-stellata-desktop-1x.jpeg, a 2x notte-stellata-desktop-2x.jpeg, oltre i 2x notte-stellata-desktop-3x.jpeg.

Volendo è possibile specificare sizes negli elementi <source> per avere immagini dimensionate in base alla larghezza del viewport, a patto di avere delle immagini in srcset impostate col breakpoint.

Validazione dei form con reportValidity()

HTML 5 aveva già introdotto nuovi tipi di input, con degli attributi utili a impostare delle restrizioni previste per i valori da inserire, insieme a dei metodi per controllare la validità dei valori e a visualizzare eventualmente un messaggio di errore. Questa fu già un’innovazione non da poco visto che permise di non usare molto codice Javascript per la validazione lato-client.

HTML 5.1 offre un’altra possibilità, ancora più comoda, che è .reportValidity().
Di default quanto in un input viene inserito un valore che non rispetta i vincoli impostati, per esempio, con min e max, il browser segnala la non validità di questo.
Con .reportValidity() possiamo fare la stessa operazione anche quando normalmente non è prevista.

Nell’esempio sottostante ci sono due input numerici, da compilare obbligatoriamente, di cui il primo accetta un valore compreso tra 1 e 10, il secondo un altro tra 11 e 20.
All’invio, se uno dei due campi ha un numero non rientrante nell’intervallo previsto, il browser evidenzia il campo o i campi in questione e stampa a video un messaggio di errore predefinito.
Ma questa cosa, per esempio, di default non viene fatta quando il mouse entra sul bottone di invio.

Nel nostro caso invece la validazione viene fatta anche in quella situazione se almeno un campo è stato compilato. In questo modo posso fermare l’utente prima che tenti di inviare i dati, a patto che ne abbia fornito almeno 1. Questa restrizione, nello specifico, mi serve poiché in assenza di questa, al ricaricamento della pagina, l’utente si trova col mouse sopra il tasto e quindi rivede i messaggi di errore, anche se l’invio è già stato fatto.

Conclusione

In questo articolo sono state trattate le principali novità di HTML 5.1. Tuttavia ve ne sarebbero delle altre non supportate oppure deprecate in fase di stesura del nuovo standard. Comunque sia queste novità renderanno ancora più semplice sviluppare pagine dinamiche e responsive risparmiando codice css e Javascript, rendendo il tutto più leggero e cross-browser, quando ogni feature sarà supportata.

Per approfondire quanto è stato detto o per conoscere ulteriori novità segnalo qui una serie di link utili:

• HTML 5.1 W3C Recommendation
• How to Build Responsive Images with srcset
• What’s New in HTML 5.1
• HTML5TEST
• Using the inert-attribute