Moduli HTML: i mattoni di base

Impara le basi dei moduli HTML. Crea moduli accessibili con la struttura giusta, i tipi di campo, la validazione e l'invio dei dati.

Bozza

Quando crei un modulo usi framework o creatori di moduli. Ma sotto il cofano usano tutti i moduli HTML. Se capisci come funzionano i moduli HTML, capisci tutto il resto. Non dipendi da nessuno strumento o framework. Conosci le basi.

In questo articolo vedi l'elemento form di HTML, i tipi di campo, le etichette, la validazione e come i moduli vengono davvero inviati. Niente framework. Niente librerie. Solo HTML e i principi su cui si regge tutto il resto.

L'elemento form di HTML

Un modulo è un elemento HTML che racchiude i campi e invia i loro dati da qualche parte. La struttura di base è:

<form action="/submit" method="POST">

<input type="text" name="email">

<button type="submit">Send</button>

</form>

Contano tre attributi. L'attributo action dice al modulo dove inviare i dati. "/submit" significa inviare con POST all'endpoint /submit del tuo server. Se action è vuoto, il modulo viene inviato alla pagina corrente. L'attributo method dice al modulo come viaggiano i dati. POST invia i dati nel corpo della richiesta (sicuro, nascosto nell'URL). GET aggiunge i dati all'URL (poco sicuro per i dati sensibili, utile per le ricerche). L'attributo enctype serve solo per il caricamento di file. Imposta enctype="multipart/form-data" quando il modulo ha un campo per caricare file.

Tutto ciò che sta dentro i tag form fa parte dell'invio. Quando l'utente clicca sul pulsante di invio, il browser raccoglie tutti i campi con un nome e li invia all'URL di action con il metodo indicato.

I tipi di campo e cosa fanno

text

<input type="text" name="first_name">

Un campo di testo a una riga. Il browser mostra una semplice casella di testo. Nessuna validazione. Ogni carattere è permesso.

email

<input type="email" name="email">

Un campo per gli indirizzi email. Sul computer sembra un campo di testo. Da mobile il browser mostra una tastiera per le email. All'invio il browser controlla che il valore somigli a un indirizzo email (contiene una @). Solo una validazione di base.

password

<input type="password" name="password">

Testo nascosto come puntini o asterischi mentre scrivi. Il valore viene comunque trasmesso in chiaro, quindi usa sempre HTTPS nei moduli con campi password.

number

<input type="number" name="age">

Sul computer, un campo di testo che accetta solo numeri. Da mobile il browser mostra una tastiera numerica. Il browser impedisce di inserire caratteri non numerici.

date

<input type="date" name="birth_date">

Un selettore di data. Nei browser e nei dispositivi che lo supportano, cliccando sul campo si apre un calendario. Il valore ha il formato AAAA-MM-GG.

checkbox

<input type="checkbox" name="agree" value="yes">

Una casella che si attiva e si disattiva. Se è spuntata, il valore del campo viene inviato. Se non è spuntata, il campo non viene inviato affatto.

radio

<input type="radio" name="plan" value="starter"> Starter

<input type="radio" name="plan" value="pro"> Pro

Più pulsanti di opzione con lo stesso nome formano un gruppo. Se ne può selezionare solo uno alla volta. Il valore di quello selezionato viene inviato.

select (menu a tendina)

<select name="country">

<option value="us">United States</option>

<option value="ca">Canada</option>

</select>

Un menu a tendina. Il valore dell'opzione selezionata viene inviato.

textarea

<textarea name="message"></textarea>

Un campo di testo a più righe. Gli utenti possono scrivere interi paragrafi. Il valore include gli a capo.

file

<input type="file" name="resume">

Un pulsante che apre la selezione file del dispositivo. Il file scelto viene inviato al server. Richiede enctype="multipart/form-data" sull'elemento form.

hidden

<input type="hidden" name="user_id" value="12345">

Un campo che non viene mostrato ma viene inviato. Utile per i dati di tracciamento che devono essere inclusi ma che l'utente non deve modificare.

Etichette e accessibilità

Abbina sempre i campi alle etichette.

<label for="email">Email address</label>

<input type="email" id="email" name="email">

L'attributo for dell'etichetta deve corrispondere all'id del campo. Se lo fai correttamente:

Gli screen reader leggono insieme etichetta e campo, cliccando sull'etichetta il campo si attiva e chi usa il telefono ha un'area di tocco più grande.

Non saltare mai le etichette. Se devi nasconderne una alla vista, nascondila con il CSS ma lasciala nell'HTML. Si chiama etichetta "nascosta visivamente".

Raggruppare i campi collegati

Per i campi collegati usa fieldset e legend.

<fieldset>

<legend>Shipping address</legend>

<input type="text" name="street">

<input type="text" name="city">

</fieldset>

L'elemento legend annuncia il gruppo agli screen reader. I fieldset aiutano a organizzare pulsanti di opzione e caselle di controllo, nell'aspetto e nel significato.

Invio del modulo e metodi HTTP

Quando l'utente clicca sul pulsante di invio, il browser raccoglie tutti i campi con un nome, codifica i dati (application/x-www-form-urlencoded per impostazione predefinita), invia una richiesta HTTP all'URL di action con il metodo (POST o GET) e aspetta una risposta.

Il server riceve la richiesta e può elaborare i dati. I dati arrivano come coppie chiave-valore. Se il metodo del modulo è POST e action è "/submit", la richiesta appare così. POST /submit HTTP/1.1 con Content-Type impostato su application/x-www-form-urlencoded, poi i dati appaiono come email=user@example.com&name=John.

Il server interpreta questi dati e risponde. Se la risposta è una pagina, il browser la carica. Se la risposta è un reindirizzamento, il browser va al nuovo URL.

Validazione lato client

HTML ha attributi di validazione già incorporati. Il browser li controlla prima di inviare il modulo.

required

<input type="text" name="email" required>

Il campo deve avere un valore. Se resta vuoto, il modulo non viene inviato e il browser mostra un errore.

minlength e maxlength

<input type="password" name="password" minlength="8" maxlength="128">

Il valore deve avere un numero di caratteri compreso tra quelli indicati.

min e max

<input type="number" name="age" min="18" max="120">

Nei campi numerici il valore deve stare dentro l'intervallo.

pattern

<input type="text" name="zip_code" pattern="[0-9]{5}">

Un'espressione regolare a cui il valore deve corrispondere. Un CAP di cinque cifre corrisponde a [0-9]{5}.

La validazione lato client è una comodità per gli utenti. Evita che inviino dati non validi e vedano un errore dal server. Ma non affidarti mai alla validazione lato client per la sicurezza. Valida sempre anche sul server.

La differenza tra type="submit" e type="button"

<button type="submit">Send</button>

<button type="button">Save</button>

Un pulsante con type="submit" invia il modulo quando viene cliccato. Un pulsante con type="button" per impostazione predefinita non fa nulla. Usa type="button" quando vuoi collegare dei gestori di eventi JavaScript.

Molti sviluppatori usano <button> senza specificare il tipo. Il valore predefinito è type="submit", che di solito è quello che vuoi. Ma sii esplicito per evitare sorprese.

Perché conviene capire i moduli HTML

Se usi React, Vue o Angular, stai costruendo sopra i moduli HTML. I framework nascondono i dettagli, ma i principi di fondo sono gli stessi. Un modulo viene comunque inviato a un endpoint. La validazione va comunque fatta. Il server deve comunque gestire i dati.

Quando qualcosa si rompe nella gestione del tuo modulo, conoscere HTML ti aiuta a trovare l'errore. Sai da dove arrivano i dati, come vengono codificati e cosa dovrebbe ricevere il server. È la base.

La maggior parte delle app web moderne non usa più l'invio tradizionale dei moduli. Usa JavaScript per intercettare il modulo, validarlo e inviare i dati con _blocked_ o axios. Ma conoscere prima il modo HTML dà un senso a questi schemi.

Come il creatore di moduli di WEMASY usa questi principi

Sotto il cofano, il creatore di moduli di WEMASY genera moduli HTML accessibili con questi stessi elementi. Le etichette sono abbinate ai campi. La validazione avviene sia lato client sia lato server. I dati del modulo vengono inviati in modo sicuro. Se esporti o personalizzi un modulo WEMASY, lavori con moduli HTML costruiti su queste basi.

Vedi la pagina dei prezzi di WEMASY per i dettagli sulle funzioni dei moduli e sulle opzioni di personalizzazione.

Domande frequenti

Devo usare GET o POST per l'invio del mio modulo?
Usa POST per qualsiasi modulo che modifica dati, invia informazioni sensibili o carica file. Usa GET solo per i moduli di ricerca in cui la query può essere visibile nell'URL. GET è meno sicuro e ha limiti di lunghezza dell'URL. POST è la scelta sicura per la maggior parte dei moduli. Con il creatore di siti di WEMASY puoi impostarlo direttamente sul tuo sito.
La validazione lato client basta o serve anche quella lato server?
Valida sempre sul server. La validazione lato client serve per l'esperienza d'uso. Qualcuno può disattivare JavaScript o aggirare i controlli del browser. La vera sicurezza sta nella validazione lato server. Fai entrambe.
Come invio un modulo con JavaScript invece che con l'invio predefinito?
Ascolta l'evento submit con addEventListener, chiama event.preventDefault(), poi usa _blocked_ o axios per inviare i dati. Così puoi validare, trasformare o aggiungere altri dati prima dell'invio.
Che differenza c'è tra i dati di un modulo e JSON?
Per impostazione predefinita i moduli inviano i dati come application/x-www-form-urlencoded (coppie chiave-valore). JSON è un formato diverso. Quando intercetti un modulo con JavaScript e usi _blocked_ per inviare JSON, cambi il tipo di contenuto. Il server deve sapere quale formato aspettarsi.
Perché usare gli elementi label invece di mettere solo del testo accanto ai campi?
Le etichette migliorano l'accessibilità per gli screen reader e la navigazione da tastiera. Creano anche un'area di clic più grande da mobile. Se devi nasconderne una alla vista, nascondila con il CSS ma lasciala nell'HTML, così le tecnologie assistive la trovano ancora.
Devo preoccuparmi della protezione CSRF nei moduli?
Sì. Se il tuo modulo modifica dati (crea, aggiorna o elimina), usa un token CSRF per evitare il cross-site request forgery. Inserisci un campo nascosto con un token unico generato dal server. Verifica il token quando il modulo viene inviato.

Mettilo in pratica
sul tuo sito web.

Inizia gratis con WEMASY e crea il tuo sito in pochi minuti.