Fermer

octobre 7, 2020

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


Historiquement, les formulaires HTML ont été assez délicats – premièrement, parce qu'au moins un peu de JavaScript était nécessaire, et deuxièmement, 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, 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.

 < formulaire > 
     ...
 </  form > 

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

De plus, il y a aussi l'attribut enctype le moins utilisé qui définit le type de codage des données envoyées. De plus, l'attribut target 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. [19659008] < 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  =  " texte "    valeur  =  " Valeur préremplie "  > 
 </  form > 

See the Pen
Form 1
by SitePoint ( @SitePoint )
on CodePen .

Inclure 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:

 ] < étiquette   pour  =  " firstName "  >  Prénom  </  label  > 
 < input   id  =  " firstName "  > 

Comme vous pouvez le voir dans l'exemple ci-dessus, le pour l'attribut de doit correspondre à l'attribut id 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).

ARIA labels

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

 < input   aria-label  =  " Prénom  " > 

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 >  Subscribe  </  h1 > 
 < form > 
      < input   aria-label  =  " Email address "  [19659018] placeholder  =  " bruce@wayneenterpris.es "  > 
 </  form > 

(J'expliquerai à quoi servent les espaces réservés dans un instant.)

Wrapping labels

L'approche la plus propre est de regrouper les entrées dans les étiquettes. De plus, grâce à 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 > [19659010] Prénom  < entrée > 
 </  étiquette > 
 

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

Espaces réservés ne sont pas conçus pour être l'alternative aux étiquettes, 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 > 
     Prénom  < input   placeholder  =  " Bruce "  [19659009]> 
 </  étiquette > 
 

Voir le Pen
Form 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 "  > 
 < entrée   type  =  " case à cocher "  > 
 < entrée   type  =  " couleur "  > 
 < entrée   type  =  " date "  > 
 < input   type  =  " datetime-local "  > 
 < entrée   type  =  " email "  > 
 < entrée   type  =  " file "  > 
 < entrée   type  =  " hidden "  > 
 < entrée   type  =  " image "  > 
 < entrée   type  =  " mois "  > 
 < entrée   type  =  " numéro "  > 
 < input   type  =  " password "  > 
 < entrée   type  =  " radio "  > 
 < entrée   type  =  " range "  > 
 < entrée   type  =  " reset "  > 
 < input   type  =  " search "  > 
 < input   type  =  " submit "  > 
 < entrée   type  =  " tel "  > 
 < input   type  =  " text "  > 
 < input   type  =  " time "  > 
 < entrée   type  =  " url "  > 
 < input   type  =  " week "  > 

Les types d'entrée sémantique sont utiles lors de la validation de formulaire, en particulier lors de l'utilisation sur la validation native, que nous examinerons sous peu. Tout d’abord, apprenons à styliser ces entrées.

Style des entrées

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, apparence: aucun; a 96,06% de support du navigateur selon caniuse.com .

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

 input   {
  -webkit-looks :  none ; 
  -moz -apparence :  aucun ; 
     apparence :  aucun ; 
    ...
} 

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

Cependant, il est une lueur d'espoir…

Spécification d'un mode d'entrée

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

Mieux que rien, non? [19659008] < 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 choisissez la validation HTML native plutôt qu'une solution JavaScript, rappelez-vous que inputmode n'apporte rien à cet égard. inputmode = "email" ne validera pas une adresse e-mail, alors que input type = "email" le fera. C’est la différence.

Mettant cela de côté, voyons ce qui déclenche la validation:

 < input   required > 
 < formulaire   requis > 


 < entrée   type  =  " email "  > 
 < input   type  =  " email "    required > 


 < entrée   minlength  =  " 8 "  > 
 < entrée   maxlength  =  " 32 "  > 
 < input   maxlength  =  " 32 "    required > 


 < input   type  =  " date "    min  =  " yyyy-mm- jj  " > 
 < input   type  =  " number "    max  =  " 66  "   requis > 
 

Création de règles personnalisées

Les règles personnalisées nécessitent la connaissance des expressions régulières JavaScript, telles qu'elles sont utilisées par l'objet RegExp (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 substitut pour la validation côté serveur!

Stylisation des états valides / invalides

 Le formulaire avec un texte de substitution dans les champs du formulaire et un bouton d'envoi / d'inscription

Juste pour plus de clarté, voici comment nous ' d style de validité:

 entrée : valide   {
     border-left :   1,5  rem  solid  chaux ; 
} 

 entrée : invalide   {
     border-left :   1,5  rem  solid  crimson ; 
} 

 formulaire : invalide   {[19659408]} 

Houston, nous avons un problème!

Les entrées tentent de valider leurs valeurs (ou leur absence) immédiatement, donc le code suivant (qui montre uniquement les états valides / invalides tandis que le input contient une valeur) pourrait être mieux:

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

Cela montre le style valide / invalide mais uniquement lorsque l'espace réservé n'est pas affiché (parce que l'utilisateur a tapé quelque chose).

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

Autres éléments de base

Envoi de données de formulaire

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

 < input   type  =  " email "    name  =  "  e-mail  " > 
 < input   type  =  " hidden "    name  =  " email  "   valeur  = "  {{user.email}}  " > 
 

Accepter une entrée de forme longue

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 de forme longue des utilisateurs. De plus, il accepte la plupart (sinon la totalité) 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, parfois les plus longs sont inévitables. Dans un tel scénario, l'élément

peut être utilisé pour contenir des entrées associées, un enfant

étant utilisé comme titre / en-tête pour l'ensemble de champs

:

 < > [19659010]  < legend >  Name  </  legend > 
      < input   type  = [19659009] " texte "    nom  =  " titre "  > 
      < input   type  =  " text "    name  =  " firstName "  [19659009]> 
      < input   type  =  " text "    name  =  " nom  " > 
 </  fieldset > 
 < fieldset > 
      < legend >  Contact details  </  legend > 
     [19659011] < input   type  =  " email "    name  =  " email "  > 
      < input   type  =  " tel "    name  = [19659009] " homePhone "  > 
      < input   type  =  " tel "    nom  =  " mobilePhone "  > 
 </  fieldset > 
 

Choses intéressantes à savoir

Désactivation des entrées

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

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

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

 : activé   {
     opacité :   1 ; 
} 
: désactivé   {
     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 pour 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 tirons parti de la validation de formulaire HTML natif (qui gère automatiquement la désactivation / l'activation de la capacité de soumission), c'est très bien:

 : invalid  ~ input [19659563] [ type  =  submit ]    {
     opacity :   0.5 ; 
} 

Désactivation une entrée, mais en envoyant quand même les données

Un mélange de et l'exemple suivant garantira que la valeur ne peut pas être modifiée. La différence est que, contrairement à disabled les valeurs readonly 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 de rotation» pour ajuster la valeur numérique, et elles acceptent également un attribut step qui détermine une autre valeur incrémentielle de chaque ajustement:

 < input   type  =  " number "    step  =  " 0,1 "    max  =  " 1 "  > 
 

Styliser les formulaires, les étiquettes et les jeux de champs sur le focus

Nous pouvons utiliser focus-within: pour styliser tout parent d'une entrée recevant actuellement le focus. Cet élément sera très probablement le conteneur d’entrée

ou

:

 form : focus-within ,
fieldset : mise au point dans ,
étiquette : 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 [19659019] =  " fichier "  > 
 < entrée   multiple   type  =  " email "  > 
 

Ecriture de code de formulaire abrégé

Si un formulaire se compose uniquement d'un singulier




Source link