032.4 Lezione 1

Prima di vedere nel dettaglio il codice di markup specifico per i moduli, iniziamo con un semplice documento HTML vuoto, senza alcun contenuto del corpo:

Salva l’esempio di codice come file di testo semplice con estensione .html (come in form.html) e usa il tuo browser preferito per aprirlo. Dopo averlo modificato, premi il pulsante reload nel browser per mostrare le modifiche.

La struttura di base del modulo è data dal tag <form> stesso e dai suoi elementi interni:

I doppi apici non sono richiesti per gli attributi a parola singola come type, quindi type=text funziona bene come type="text". Lo sviluppatore può scegliere quale convenzione utilizzare.

Salva il nuovo contenuto e ricarica la pagina nel browser. Dovresti vedere il risultato mostrato in Figure 1.

Il tag <form> da solo non produce alcun risultato evidente sulla pagina. Gli elementi all’interno dei tag <form>…​</form> definiranno i campi e altri aiuti visivi mostrati al visitatore.

Il codice di esempio contiene entrambi i tag HTML generici (<h2> e <p>) e il tag <input>, che è un tag specifico del modulo. Mentre i tag generici possono apparire ovunque nel documento, i tag specifici del modulo dovrebbero essere usati solo all’interno dell’elemento <form>; cioè tra i tag di apertura <form> e di chiusura </form>.

Come mostrato nell’esempio, il tag paragrafo <p> può essere usato per descrivere il campo al visitatore. Tuttavia, non c’è un modo ovvio in cui il browser possa mettere in relazione la descrizione nel tag <p> con l’elemento di input corrispondente. Il tag <label> è più appropriato in questi casi (d’ora in poi, considera tutti gli esempi di codice come se fossero all’interno del corpo del documento HTML):

L’attributo for nel tag <label> contiene l' id del corrispondente elemento di input. Rende la pagina più accessibile, poiché gli screenreader saranno in grado di pronunciare il contenuto dell’elemento etichetta quando l’elemento di input è evidenziato. Inoltre, i visitatori possono cliccare sull’etichetta per mettere a fuoco il campo di input corrispondente.

L’attributo id funziona per gli elementi del modulo come per qualsiasi altro elemento nel documento. Fornisce un identificatore per l’elemento che è unico all’interno dell’intero documento. L’attributo name ha uno scopo simile, ma è usato per identificare l’elemento di input nel contesto del modulo. Il browser usa l’attributo name per identificare il campo di input quando invia i dati del modulo al server, quindi è importante usare attributi name significativi e unici all’interno del modulo.

L’attributo type è l’attributo principale dell’elemento input, perché controlla il tipo di dati che l’elemento accetta e la sua presentazione visiva al visitatore. Se l’attributo type non è fornito, per default l’input mostra una casella di testo. I seguenti tipi di input sono supportati dai browser moderni:

L’aspetto dei tipi di input password, search, tel, url e email non differiscono dal tipo standard text. Il loro scopo è quello di offrire suggerimenti al browser circa il contenuto previsto per quel campo di input, così il browser o lo script in esecuzione sul lato client possono intraprendere azioni personalizzate per uno specifico tipo di input. L’unica differenza tra il tipo di input testuale e il tipo di campo password, per esempio, è che il contenuto del campo password non viene visualizzato mentre il visitatore lo digita. Nei dispositivi touch screen, dove il testo viene digitato con una tastiera su schermo, il browser può far apparire solo la tastiera numerica quando un input di tipo tel ottiene il focus. Un’altra azione possibile è quella di suggerire una lista di indirizzi email conosciuti quando un input di tipo email viene mostrato.

Anche il tipo number appare come una semplice immissione di testo, ma con frecce di incremento/decremento al suo fianco. Il suo utilizzo farà sì che la tastiera numerica appaia nei dispositivi touchscreen quando ha il focus.

Gli altri elementi di input hanno il proprio aspetto e comportamento. Il tipo date, per esempio, è reso secondo le impostazioni locali del formato della data e viene visualizzato un calendario quando ottiene il focus:

Figure 2 mostra come la versione desktop di Firefox visualizza attualmente questo campo.

Questa è una caratteristica standard in tutti i browser moderni e non richiede opzioni extra o programmazione.

Indipendentemente dal tipo di input, il contenuto di un campo di input è chiamato il suo valore. Tutti i valori dei campi sono vuoti per impostazione predefinita, ma l’attributo value può essere usato per impostare un valore predefinito per il campo. Il valore per il tipo data deve usare il formato YYYY-MM-DD. Il valore predefinito nel seguente campo data è 6 agosto 2020:

I tipi di input specifici aiutano il visitatore a riempire i campi, ma non gli impediscono di aggirare le restrizioni e inserire valori arbitrari in qualsiasi campo. Ecco perché è importante che i valori dei campi siano convalidati quando arrivano al server.

Gli elementi del modulo i cui valori devono essere digitati dal visitatore possono avere attributi speciali che aiutano a riempirli. L’attributo placeholder inserisce un valore di esempio nell’elemento di input:

Il suggerimento appare all’interno dell’elemento di input, come mostrato in Figure 3.

Una volta che il visitatore inizia a digitare nel campo, il testo suggerito scompare. Il testo suggerito non viene inviato come valore del campo se il visitatore lascia il campo vuoto.

L’attributo required richiede che il visitatore compili un valore per il campo corrispondente prima di inviare il modulo:

L’attributo required è un attributo booleano, quindi può essere messo da solo (senza il segno uguale). È importante contrassegnare i campi che sono richiesti, altrimenti il visitatore non sarà in grado di dire quali campi mancano e impediscono l’invio del modulo.

L’attributo autocomplete indica se il valore dell’elemento di input può essere completato automaticamente dal browser. Se impostato su autocomplete="off", allora il browser non suggerisce valori precedenti per riempire il campo. Gli elementi di input per informazioni sensibili, come i numeri delle carte di credito, dovrebbero avere l’attributo autocomplete sempre impostato su off.

A differenza del campo di testo, dove si può inserire solo una riga di testo, l’elemento textarea permette al visitatore di inserire più di una riga di testo. La textarea è un elemento separato, ma non si basa sull’elemento input:

L’aspetto tipico di una textarea è Figure 4.

Un’altra differenza rispetto all’elemento input è che l’elemento textarea ha un tag di chiusura (</textarea>), quindi il suo contenuto (cioè il suo valore) va in mezzo. Gli attributi rows e cols non limitano la quantità di testo; sono usati solo per definire il layout. La textarea ha anche una maniglia nell’angolo in basso a destra, che permette al visitatore di ridimensionarla.

Si possono usare diversi tipi di controlli di modulo per presentare una lista di opzioni al visitatore: l’elemento <select> e i tipi di input radio e checkbox.

L’elemento <select> è un controllo a discesa con un elenco di voci predefinite:

Il tag <option> rappresenta una singola voce nel corrispondente controllo <select>. L’intero elenco viene visualizzato quando il visitatore tocca o fa clic sul controllo, come mostrato in Figure 5.

La prima voce della lista è selezionata per default. Per cambiare questo comportamento, puoi aggiungere l’attributo selected a un’altra voce in modo che sia selezionata al caricamento della pagina.

Il tipo di input radio è simile al controllo <select>, ma invece di un elenco a discesa, mostra tutte le voci in modo che il visitatore possa contrassegnarne una. I risultati del seguente codice sono mostrati in Figure 6.

Nota che tutti i tipi di input radio nello stesso gruppo hanno lo stesso attributo name. Ognuno di essi è esclusivo, quindi l’attributo value corrispondente per la voce scelta sarà quello associato all’attributo name condiviso. L’attributo checked funziona come l’attributo selected del controllo <select>. Contrassegna la voce corrispondente quando la pagina viene caricata per la prima volta. Il tag <label> è particolarmente utile per le voci radio, perché permette al visitatore di controllare una voce cliccando o toccando il testo corrispondente oltre al controllo stesso.

Mentre i controlli radio sono destinati a selezionare solo una singola voce di una lista, il tipo di input checkbox permette al visitatore di selezionare più voci:

Anche le caselle checkbox possono usare l’attributo checked per rendere le voci selezionate per default. Invece dei controlli rotondi dell’input radio, i checkbox sono resi come controlli quadrati, come mostrato in Figure 7.

Se viene selezionata più di una voce, il browser le invierà con lo stesso nome, richiedendo allo sviluppatore di backend di scrivere codice specifico per leggere correttamente i dati del modulo che contiene checkbox.

Per migliorare l’usabilità, i campi di input possono essere raggruppati in un tag <fieldset>:

Il tag <legend> contiene il testo che viene posizionato in cima alla cornice che il tag <fieldset> disegna intorno ai controlli (Figure 8).

Il tag <fieldset> non cambia il modo in cui i valori dei campi sono inviati al server, ma permette allo sviluppatore frontend di controllare più facilmente i controlli annidati. Per esempio, impostando l’attributo disabled in un attributo <fieldset> si rendono tutti i suoi elementi interni non disponibili al visitatore.

Ci sono situazioni in cui lo sviluppatore vuole includere informazioni nel modulo che non possono essere manipolate dal visitatore. Per inviare un valore scelto dallo sviluppatore senza presentare un campo del modulo in cui il visitatore può digitare o cambiare il valore, lo sviluppatore potrebbe voler, per esempio, includere un token di identificazione per quel particolare modulo che non deve essere visto dal visitatore. Un elemento di modulo nascosto è codificato come nell’esempio seguente:

Il valore di un campo di input nascosto viene solitamente aggiunto al documento sul lato server, quando si restituisce al client il documento. Gli input nascosti sono trattati come campi ordinari quando il browser li invia al server.

Oltre ai dati testuali, digitati o selezionati da una lista, i moduli HTML possono anche inviare file al server. Il tipo di input file permette al visitatore di scegliere un file dal file system locale e inviarlo direttamente dalla pagina web:

Invece di un campo del modulo in cui scrivere o da cui selezionare un valore, il tipo di input file mostra un pulsante browse che aprirà una finestra di dialogo del file. Qualsiasi tipo file è accettato dal tipo di input file, ma lo sviluppatore del backend probabilmente limiterà i tipi di file consentiti e la loro dimensione massima. La verifica del tipo di file può essere eseguita anche nel frontend aggiungendo l’attributo accept. Per accettare solo immagini JPEG e PNG, per esempio, l’attributo accept dovrebbe essere: accept="image/jpeg, image/png".

Per impostazione predefinita, il modulo viene inviato quando il visitatore preme il tasto Enter in qualsiasi campo di input. Per rendere le cose più intuitive, si dovrebbe aggiungere un pulsante di invio con il tipo di input submit:

Il testo nell’attributo value viene visualizzato sul pulsante, come mostrato in Figure 9.

Un altro pulsante utile da includere nei moduli complessi è il pulsante reset, che cancella il modulo e lo riporta al suo stato originale:

Come il pulsante di invio, il testo nell’attributo value è usato per etichettare il pulsante. In alternativa, il tag <button> può essere usato per aggiungere pulsanti ai moduli o in qualsiasi altro punto della pagina. A differenza dei pulsanti realizzati con il tag <input>, l’elemento button ha un tag di chiusura e l’etichetta è il suo contenuto interno:

All’interno di un modulo, l’azione predefinita per l’elemento button è di inviare il modulo. Come per i pulsanti di input, l’attributo type del pulsante può essere cambiato in reset.

L’ultimo passo nella scrittura di un modulo HTML è definire come e dove i dati devono essere inviati. Questi aspetti dipendono da dettagli sia nel client sia nel server.

Lato server, l’approccio più comune è quello di avere un file di script che analizza, convalida ed elabora i dati del modulo secondo lo scopo dell’applicazione. Per esempio, lo sviluppatore di backend potrebbe scrivere uno script chiamato receive_form.php per ricevere i dati inviati dal modulo. Sul lato client, lo script è indicato nell’attributo action del tag del modulo:

L’attributo action segue le stesse convenzioni di tutti gli indirizzi HTTP. Se lo script si trova nello stesso livello gerarchico della pagina che contiene il modulo, può essere scritto senza il suo percorso. Altrimenti, il percorso assoluto o relativo deve essere fornito. Lo script dovrebbe anche generare la risposta per servire come pagina di destinazione, caricata dal browser dopo che il visitatore ha inviato il modulo.

HTTP fornisce metodi distinti per inviare i dati di un modulo attraverso una connessione con il server. I metodi più comuni sono get e post, che dovrebbero essere indicati nell’attributo method del tag form:

Oppure:

Nel metodo get, i dati del modulo sono codificati direttamente nell’URL della richiesta. Quando il visitatore invia il modulo, il browser caricherà l’URL definito nell’attributo action con i campi del modulo aggiunti.

Il metodo get è preferito per piccole quantità di dati, come i semplici moduli di contatto. Tuttavia, l’URL non può superare alcune migliaia di caratteri, quindi il metodo post dovrebbe essere usato quando i moduli contengono campi grandi o non testuali, come le immagini.

Il metodo post fa sì che il browser invii i dati del modulo nella sezione del corpo della richiesta HTTP. Sebbene sia necessario per i dati binari che superano il limite di dimensione di un URL, il metodo post aggiunge un inutile sovraccarico alla connessione quando viene usato in moduli testuali più semplici, quindi il metodo get è preferito in questi casi.

Il metodo scelto non influenza il modo in cui il visitatore interagisce con il modulo. I metodi get e post sono processati diversamente dallo script lato server che riceve il modulo.

Quando si usa il metodo post, è anche possibile cambiare il tipo MIME del contenuto del modulo con l’attributo del modulo enctype. Questo influisce su come i campi e i valori del modulo saranno impilati insieme nella comunicazione HTTP con il server. Il valore predefinito per enctype è application/x-www-form-urlencoded, che è simile al formato usato nel metodo get. Se il modulo contiene campi di input di tipo file, dovrebbe invece essere usato l’enctype multipart/form-data.