Catégories
Astuces et Design

Un guide des formulaires HTML et CSS (pas de piratage!)

Historiquement, les formulaires HTML ont été assez délicats – d'une part, parce qu'au moins un peu de JavaScript était nécessaire, et d'autre part, parce qu'aucune quantité de CSS ne pourrait jamais les faire se comporter.

Cependant, ce n'est pas nécessairement vrai dans le cas du Web moderne, alors apprenons à baliser des formulaires en utilisant uniquement HTML et CSS.

Former la structure de base

Une entrée de formulaire avec une valeur pré-remplie

Commencez par le

élément.

Rien d'extraordinaire ici. Couvrant juste la structure de base.

<form>
    ...
form>

Si vous envoyez les données du formulaire naturellement (c'est-à-dire sans JavaScript), vous devrez inclure le action attribut, où la valeur est l'URL à laquelle vous enverrez les données du formulaire. le method devrait être GET ou POST en fonction de ce que vous essayez d'accomplir (n'envoyez pas de données sensibles avec GET).

De plus, il y a aussi le moins utilisé enctype attribut qui définit le type de codage des données envoyées. Également target L'attribut, bien que n'étant pas nécessairement un attribut unique aux formulaires, peut être utilisé pour afficher la sortie dans un nouvel onglet.

Les formulaires JavaScript n'ont pas nécessairement besoin de ces attributs.

<form method="POST" action="/subscribe" enctype="application/x-www-form-urlencoded" target="_blank">
    ...
form>

Les formulaires sont constitués d'entrées, qui attendent des valeurs de données.

<form>
    <input type="text">
    <input type="text" value="Prefilled value">
form>

Voir le stylo
Formulaire 1 par SitePoint (@SitePoint)
sur CodePen.

Y compris des étiquettes pour une meilleure convivialité et accessibilité

Chaque entrée a besoin d'une étiquette.

Une étiquette est un descripteur de texte qui décrit à quoi sert une entrée. Il existe trois façons de déclarer une étiquette, mais l'une d'elles est supérieure aux deux autres. Allons-y maintenant.

Étiquettes adjacentes

Les étiquettes adjacentes nécessitent le plus de code, car nous devons déclarer explicitement l'entrée décrite par l'étiquette. Pour la plupart, cela est contre-intuitif car nous pouvons à la place envelopper les entrées dans des étiquettes pour obtenir le même effet avec moins de code.

Cela étant dit, la méthode adjacente peut être nécessaire dans des circonstances atténuantes, alors voici à quoi cela ressemblerait:

<label for="firstName">First namelabel>
<input id="firstName">

Comme vous pouvez le voir dans l'exemple ci-dessus, le for attribut du doit correspond à id attribut de l'entrée, et ce que cela fait est d'expliquer aux périphériques d'entrée quel descripteur de texte appartient à quelle entrée. Le périphérique d'entrée le transmettra ensuite aux utilisateurs (les lecteurs d'écran, par exemple, le dicteront via la parole).

Étiquettes ARIA

Alors que le HTML sémantique est meilleur, les étiquettes ARIA (Accessible Rich Internet Applications) peuvent compenser leur absence. Dans ce cas, voici à quoi pourrait ressembler une étiquette en l'absence d'un HTML réel :

<input aria-label="First name">

Malheureusement, l'inconvénient de cette approche est l'absence d'étiquette visuelle. Cependant, cela peut convenir à certaines balises (par exemple, un formulaire à entrée unique avec un en-tête et un espace réservé):

<h1>Subscribeh1>
<form>
    <input aria-label="Email address" placeholder="bruce@wayneenterpris.es">
form>

(Je vais vous expliquer à quoi servent les espaces réservés dans un instant.)

Étiquettes d'emballage

Emballer les entrées dans des étiquettes est l'approche la plus propre. Aussi, grâce aux CSS :focus-within, nous pouvons même styliser les étiquettes pendant que leurs entrées enfants reçoivent le focus, mais nous en discuterons plus tard.

<label>
    First name<input>
label>

Espaces réservés vs étiquettes

Deux entrées avec texte d'espace réservé visible

Une brève comparaison:

  • Les étiquettes indiquent ce que l'entrée attend
  • Les espaces réservés montrent des exemples de ces attentes

Les espaces réservés ne sont pas conçus pour être l’alternative aux libellés, même si, comme nous l’avons vu dans l’exemple ARIA ci-dessus, ils peuvent rajouter une partie du contexte perdu en l’absence d’étiquettes visuelles.

Idéalement, cependant, nous devrions utiliser les deux:

<label>
    First name<input placeholder="Bruce">
label>

Voir le stylo
Formulaire 2 par SitePoint (@SitePoint)
sur CodePen.

Choix des types d'entrée

Les espaces réservés s'appliquent uniquement aux entrées textuelles, mais il existe en fait toute une gamme de types d'entrée différents, notamment:

<input type="button">
<input type="checkbox">
<input type="color">
<input type="date">
<input type="datetime-local">
<input type="email">
<input type="file">
<input type="hidden"> 
<input type="image">
<input type="month">
<input type="number">
<input type="password">
<input type="radio">
<input type="range">
<input type="reset">
<input type="search">
<input type="submit"> 
<input type="tel">
<input type="text"> 
<input type="time">
<input type="url">
<input type="week">

Les types d'entrées sémantiques sont utiles lors de la validation de formulaire, en particulier lorsque l'on s'appuie sur la validation native, que nous examinerons bientôt. Tout d'abord, apprenons à définir le style de ces entrées.

Entrées de style

L'aspect le plus exaspérant des formulaires de codage est sans doute de remplacer le style par défaut du navigateur. Heureusement, aujourd'hui, appearance: none; prend en charge le navigateur à 96,06% selon caniuse.com.

Après avoir réinitialisé le style par défaut du navigateur Web avec le code CSS suivant, nous pouvons ensuite styliser les entrées comme nous le voulons, et cela inclut même les types d'entrée radio et case à cocher:

input {
 -webkit-appearance: none;
 -moz-appearance: none;
    appearance: none;
    ...
}

Cependant, certaines de ces entrées peuvent présenter des bizarreries difficiles, voire impossibles à surmonter (selon le navigateur Web). Pour cette raison, de nombreux développeurs ont tendance à revenir à la valeur par défaut type="text" attribut = valeur s'ils trouvent ces bizarreries indésirables (par exemple, le signe "caret" sur input type="number").

Cependant, là est une lueur d'espoir…

Spécifier un inputmode

Avec 82,3% de support de navigateur Web selon caniuse.com, le nouveau inputmode L'attribut spécifie la disposition du clavier qui sera révélée sur les appareils portables, quelle que soit l'entrée type utilisé.

Mieux que rien, non?

<input type="text" inputmode="none"> 
<input type="text" inputmode="text"> 
<input type="text" inputmode="decimal">
<input type="text" inputmode="numeric">
<input type="text" inputmode="tel">
<input type="text" inputmode="search">
<input type="text" inputmode="email">
<input type="text" inputmode="url">

Validation de l'entrée utilisateur

Si vous préférez la validation HTML native à une solution JavaScript, n'oubliez pas que inputmode ne fait rien à cet égard. inputmode="email" habitude valider une adresse e-mail, alors que input type="email" volonté. C’est la différence.

Cela mis à part, examinons ce qui déclenche la validation:

<input required> 
<form required> 


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


<input minlength="8"> 
<input maxlength="32"> 
<input maxlength="32" required> 


<input type="date" min="yyyy-mm-dd"> 
<input type="number" max="66" required> 

Créer des règles personnalisées

Les règles personnalisées nécessitent la connaissance des expressions régulières JavaScript, telles qu'utilisées par le RegExp objet (mais, sans les barres obliques ni les guillemets). Voici un exemple qui applique les caractères minuscules (a – z) et minlength / maxlength dans une règle:

<input pattern="(a-z){8,12}">

Plus d'infos ici.

Remarque: la validation frontale (native-HTML ou autre) ne doit jamais, jamais être utilisée comme un substitut à la validation côté serveur!

Styliser les états valides / non valides

Le formulaire avec un texte d'espace réservé dans les champs du formulaire et un bouton d'envoi / d'inscription

Pour plus de clarté, voici comment nous définirons la validité:

input:valid {
    border-left: 1.5rem solid lime;
}

input:invalid {
    border-left: 1.5rem solid crimson;
}

form:invalid {
    
}

Houston nous avons un problème!

Les entrées tentent de valider leurs valeurs (ou leur absence) immédiatement, donc le code suivant (qui affiche uniquement les états valides / invalides pendant que l'entrée contient une valeur) pourrait être meilleur:

input:not(:placeholder-shown):valid {
    border-left: 1.5rem solid lime;
}

Cela montre le style valide / non valide, mais uniquement lorsque le espace réservé n'apparaît pas (car l'utilisateur a tapé quelque chose).

Voir le stylo
Formulaire 3 par SitePoint (@SitePoint)
sur CodePen.

Autres choses de base

Envoi des données du formulaire

L'envoi de données de formulaire au serveur nécessite généralement que les entrées aient name attribut. Cela s'applique également aux entrées masquées:

<input type="email" name="email">
<input type="hidden" name="email" value="{{ user.email }}">

Accepter une entrée au format long

Essentiellement, est la même chose que , à l'exception du fait que les zones de texte ont un support multiligne. Oui, serait certainement plus intuitif, mais hélas est la bonne façon d'accepter les entrées au format long des utilisateurs. De plus, il accepte la plupart (sinon tous) des attributs que les entrées font.

Regrouper les entrées pour une meilleure accessibilité

Bien que les formulaires plus courts offrent une bien meilleure expérience utilisateur, des formulaires plus longs sont parfois inévitables. Dans un tel scénario, le

L'élément peut être utilisé pour contenir des entrées associées, avec un enfant

utilisé comme titre / titre pour le

:

<fieldset>
    <legend>Namelegend>
    <input type="text" name="title">
    <input type="text" name="firstName">
    <input type="text" name="lastName">
fieldset>
<fieldset>
    <legend>Contact detailslegend>
    <input type="email" name="email">
    <input type="tel" name="homePhone">
    <input type="tel" name="mobilePhone">
fieldset>

Choses agréables à savoir

Désactivation des entrées

Ajout du disabled L'attribut peut rendre une entrée (ou tout élément focalisable) obsolète, bien que cela soit généralement appliqué / non appliqué via JavaScript. Voici cependant comment cela fonctionne:

<form disabled>...form>
<fieldset disabled>...fieldset>
<input type="submit" disabled>

Et le CSS qui l'accompagne, si nécessaire:

:enabled {
    opacity: 1;
}
:disabled {
    opacity: 0.5;
}

Cependant, si tout ce que vous voulez faire est d'ajouter un signal visuel supplémentaire indiquant que l'entrée de l'utilisateur n'est pas valide, vous voudrez probablement utiliser le combinateur général des frères et sœurs (~). Le code suivant signifie essentiellement «le bouton d'envoi qui suit tout élément avec une entrée non valide». Cela ne modifie aucune fonctionnalité, mais lorsque nous exploitons la validation de formulaire HTML natif (qui gère automatiquement la désactivation / l'activation de la fonctionnalité d'envoi), c'est très bien:

:invalid ~ input(type=submit) {
    opacity: 0.5;
}

Désactiver une entrée, mais envoyer quand même les données

Un mélange de et , l'exemple suivant garantit que la valeur ne peut pas être modifiée. La différence est que, contrairement à disabled, readonly les valeurs sont envoyées sous forme de données de formulaire; et contrairement hidden, readonly est visible:

<input readonly value="Prefilled value">

Modification des incréments

Les entrées numériques ont un «bouton tournant» pour ajuster la valeur numérique, et elles acceptent également un step attribut qui détermine une valeur incrémentielle alternative de chaque ajustement:

<input type="number" step="0.1" max="1">

Mettre en forme les formulaires, les étiquettes et les jeux de champs sur le focus

On peut utiliser focus-within: styliser n'importe quel parent d'une entrée recevant actuellement le focus. Cet élément sera très probablement l’entrée

, , ou

récipient:

form:focus-within,
fieldset:focus-within,
label:focus-within {
    ...
}

Envoi de plusieurs valeurs avec une seule entrée

multiple est valide pour les types d'entrée fichier et e-mail:

<input multiple type="file"> 
<input multiple type="email"> 

Rédaction de code de formulaire abrégé

Si une forme se compose uniquement d'un singulier

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *