Bien valider ses formulaires avec Javascript

Openweb.eu.org > Articles  > Bien valider ses formulaires avec Javascript

Abstract

En fouinant sur le web, on peut découvrir plusieurs pratiques pour appeler
des scripts en Javascript qui vérifient le contenu d’un formulaire. Mais elles
sont, hélas, rarement correctes dans le sens où beaucoup d’entre elles
réduisent l’accessibilité et l’ergonomie des formulaires, voire sont
inefficaces. Cet article vous propose de passer en revue ce qu’il faut faire
et ne pas faire en la matière.

Article

Petit rappel sur les formulaires

Rappelons-nous d'abord de quoi est composé un formulaire :

  • de champs de saisie, matérialisés par des balises input, select et textarea ;
  • de boutons pour valider ou annuler / effacer le formulaire, respectivement <input type="submit" /> et <input type="reset" /> ;
  • une balise form qui encadre le tout ;
  • et éventuellement ce fameux script en Javascript qui va vérifier le contenu avant son envoi vers le serveur Web.

Cet ensemble peut être complété par des balises label, fieldset, legend, etc. pour améliorer l'accessibilité et la structure d'un formulaire. Je vous renvoie à l'article Utilisation des formulaires pour en savoir plus à ce sujet. Nous ne nous occuperons ici que de l'aspect Javascript.

Voila ce que cela pourrait donner :

<form action="url_page_suivante" method="get" name="formSaisie">
  <p>
    <label for="prenom">Saisissez votre prénom :</label>
    <input type="text" name="prenom" id="prenom" />

    <input type="submit" value="Ok" />
  </p>
</form>

Nous sommes dans l'hypothèse où notre page est conforme au XHTML 1.0 Transitionnal, et non Strict, pour faciliter la compréhension des exemples qui suivront. En effet, en XHTML Strict ou HTML 4.01 Strict, l'attribut "name" de la balise form est obsolète. De ce fait, il est impossible avec ces DTD d'utiliser le code document.nom_du_formulaire, très souvent utilisé, pour accéder aux champs de saisie (comme par exemple document.nom_du_formulaire.mon_champs.value). Nous verrons à la fin de cet article comment contourner cette restriction et écrire du code respectant un peu mieux les spécifications du DOM, utilisable avec toutes les versions de HTML et sur tous les navigateurs.

Les erreurs les plus courantes

En général, les formulaires ressemblent à notre exemple, il n'y a pas trop de soucis. Là où ça se gâte, c'est au moment d'inclure le petit bout de code Javascript qui va vérifier que l'internaute a bien saisi un prénom (en se référant à notre exemple), avant d'envoyer le formulaire.

Beaucoup de développeurs, instinctivement, implémentent (à tort) cette vérification au niveau du clic sur le bouton « Ok ». C'est ainsi que l'on trouve ce genre de fonction (à ne pas faire).

<script type="text/javascript">
//<![CDATA[

function valider() {
  // si la valeur du champ prenom est non vide
  if(document.formSaisie.prenom.value != "") {
    // alors on envoie le formulaire
    document.formSaisie.submit();
  }
  else {
    // sinon on affiche un message
    alert("Saisissez le prénom");
  }
}

//]]>
</script>
    

Puis sur le bouton « Ok », on trouve en général l'appel de la fonction valider() sur l'événement "onclick", déclenché lorsque l'on clique sur le bouton, ce qui ressemble à ceci (Cas A) :

<input type="submit" value="Ok" onclick="valider()" />
    

On trouve parfois aussi, non pas un bouton « submit » mais un bouton tout court, ou une image, ou un lien, ce qui est encore moins bien (Cas B):

<input type="button" value="Ok" onclick="valider()" />
<img src="ok.png" onclick="valider()" alt="ok" />
<a href="/articles/validation_formulaire#" onclick="valider()">Ok</a>
    

Souvent même, la fonction valider() est appelée directement dans l'attribut "href" d'un lien (Cas C):

<a href="javascript:valider()">Ok</a>

<a href="javascript:valider()"><img src="ok.png" alt="ok" /></a>
    

Pourquoi ce sont des erreurs ?

Il faut se mettre en tête que :

  1. l'utilisateur peut vouloir préférer appuyer sur la touche Entrée de son clavier plutôt que de cliquer sur le bouton « Ok ». Il peut s'agir des inconditionnels du clavier, mais il peut s'agir aussi de personnes qui sont obligées de passer par le clavier. Il y a ainsi ceux qui utilisent un navigateur texte. Il y a aussi les handicapés moteurs pour qui la manipulation de la souris peut être difficile. Il y a aussi les gens qui doivent manipuler à longueur de temps des formulaires, comme c'est le cas dans les applications intranet. Car éviter de passer du clavier à la souris et de la souris au clavier permet d'être plus productif et est moins fatiguant. Tous les ergonomes vous le diront ;
  2. le Javascript n'est pas forcément disponible dans le navigateur de l'internaute (ou tout simplement désactivé). La plupart des statistiques rapportent que c'est le cas pour 5 à 7% des internautes.

Ces constats nous amènent donc à nous rendre compte que les exemples vus précédemment sont inadaptés.

Dans le cas A, si l'utilisateur appuie sur la touche Entrée en étant dans l'un des champs de saisie, ou s'il met le focus sur le bouton avec la touche Tab puis en appuyant sur Entrée, le formulaire sera envoyé, sans même que la fonction valider() soit exécutée (Ce n'est cependant pas le cas de tout les navigateurs). En effet, elle n'est ici appelée que sur l'événement "onclick".

Dans le cas B, étant donné qu'il ne s'agit ni de bouton « submit », ni de bouton « image », la touche Entrée est inactive, et ne provoque pas l'envoi du formulaire. On est obligé de cliquer sur le bouton, l'image ou le lien. Cela peut être donc embêtant pour certaines personnes comme on l'a vu.

Pire, dans les cas B et C, si le support du Javascript est désactivé ou n'est pas présent dans le navigateur, le formulaire ne pourra jamais être envoyé ! Idem si on n'a pas de souris (navigateur texte) dans le cas B !

La bonne façon de vérifier un formulaire

En fait, il n'existe qu'une seule méthode valable pour vérifier le contenu d'un formulaire en Javascript avant son envoi.

Utilisation des bons boutons

Le/les bouton(s) pour envoyer le formulaire doivent être :

  • soit de type « submit » : <input type="submit" value="Ok" /> ;
  • soit de type image, si on veut un bouton « submit » sous forme d'image : <input type="image" src="ok.png" alt="ok" />.

Rappelez-vous qu'il est possible d'utiliser des feuilles de styles pour changer l'apparence des boutons : couleurs, bordures, image de fond, etc. Il faut noter cependant que certains navigateurs ne permettent pas d'utiliser tous les styles sur les boutons.

L'événement "onsubmit"

Cet événement, spécifique à la balise form, est déclenché lorsque le formulaire est sur le point d'être envoyé, suite à l'appui sur la touche Entrée, ou d'un clic sur un bouton « submit », ou toute autre action indiquant au navigateur d'envoyer le formulaire.

Donc l'éxecution d'un script devant vérifier le contenu du formulaire (ou faisant éventuellement d'autres traitements liés à l'envoi) doit toujours se faire sur l'événement "onsubmit" !

Comme sur tous les événements ("onclick"…), le script appelé doit renvoyer un booléen, true ou false. S'il ne renvoie rien, l'événement reçoit true par défaut. Ce booléen indique si l'événement doit se propager, c'est-à-dire si l'événement par défaut doit s'exécuter.

Ainsi, si vous renvoyez true sur l'événement "onsubmit", le formulaire sera envoyé. Si vous renvoyez false, il ne le sera pas et le navigateur ne changera pas de page. Par exemple, en mettant onsubmit="return false", le formulaire ne pourra jamais être envoyé !

Nous devons donc appeler notre fonction valider() sur le "onsubmit", et celle-ci devra renvoyer un booléen pour indiquer si le formulaire doit être envoyé ou non :

<script type="text/javascript">
//<![CDATA[

function valider(){
  // si la valeur du champ prenom est non vide
  if(document.formSaisie.prenom.value != "") {
    // les données sont ok, on peut envoyer le formulaire    
    return true;
  }
  else {
    // sinon on affiche un message
    alert("Saisissez le prénom");
    // et on indique de ne pas envoyer le formulaire
    return false;
  }
}

//]]>
</script>
        

Et la balise form devient :


<form action="url_page_suivante" onsubmit="return valider()"
  method="get" name="formSaisie">
  <p>
    <label for="prenom">Saisissez votre prénom :</label>
    <input type="text" name="prenom" id="prenom" />

    <input type="submit" value="Ok" />
  </p>
</form>
        

Notez l'emploi du mot-clé return sur l'appel de valider().

Ainsi, que l'on appuie sur la touche Entrée ou que l'on clique sur le bouton « submit », la fonction valider() sera toujours appelée. Et si le Javascript n'est pas activé, cela n'empêche pas le contenu du formulaire d'être envoyé.

Quelques précisions

  1. Le test du contenu d'un formulaire en Javascript doit être seulement considéré comme un plus pour le confort de l'utilisation de la page, afin d'éviter un envoi et un rechargement du formulaire si son contenu est invalide. Il ne remplace en aucun cas une vérification faite côté serveur, qui doit être systématique (que ce soit en PHP, ASP, Java, etc.), afin de palier le cas où le Javascript n'est pas activé, donc au cas où le formulaire n'est pas vérifié côté navigateur.
  2. S'il y a du code Javascript qui envoie le formulaire en appelant la methode submit() de l'objet formulaire comme ceci : document.formSaisie.submit();, l'événement "onsubmit" n'est pas déclenché, mais le formulaire est tout de même envoyé. Donc la fonction valider() ne sera pas appelée dans ce cas.
  3. On évitera d'utiliser les méthodes propriétaires à Internet Explorer comme document.all pour récupérer l'objet formulaire ou les objets correspondants aux champs de saisie, afin de garder une interopérabilité maximum. On préferera utiliser les fonctions du DOM comme nous allons le voir dans la section suivante.

La vérification de formulaire en Strict

Le problème des DTD Strict (HTML 4.01 Strict, XHTML 1.0 Strict ou XHTML 1.1), c'est que l'attribut "name" de la balise form est obsolète. Du coup, il est impossible de récupérer l'objet formulaire par l'instruction suivante comme on a très souvent l'habitude de faire : document.formSaisie. Cette instruction est en fait un raccourci de ce qu'il faudrait faire.

Utilisation du DOM avec la collection forms

L'objet document possède une propriété forms, qui est une collection contenant les objets formulaires présents dans la page. On peut alors l'utiliser de deux manières pour récupérer l'objet formulaire désiré

  • document.forms[n]n est le numéro de formulaire, 0 étant le premier formulaire.
  • ou document.forms['mon_formulaire']mon_formulaire est la valeur de l'attribut "id" de la balise form, ou bien de l'attribut "name" en (X)HTML transitionnal. Il faut savoir que si la balise form a les 2 attributs, c'est la valeur de l'attribut "id" qu'il faudra utiliser pour récupérer votre objet formulaire.

Ensuite, un objet formulaire contient une propriété elements qui est une collection contenant les éléments de saisie du formulaire. On récupère donc un élément du formulaire d'une de ces façons :

  • document.forms['mon_formulaire'].elements[n]n est le numéro de l'élément dans la collection, 0 étant le premier élément.
  • ou document.forms['mon_formulaire'].elements['mon_element']mon_element est la valeur de l'attribut "id" ou "name" de l'élément. Même remarque que pour les formulaires si il y a les 2 attributs, il faudra utiliser la valeur de l'attribut "id" pour récupérer l'élément.

Notre fonction valider() devient donc

function valider(){
  frm=document.forms['frmSaisie'];
  if(frm.elements['prenom'].value != "") {
    return true;
  }
  else {
    alert("Saisissez le prénom");
    return false;
  }
}
        

Ou encore

function valider(){
  elt=document.forms['frmSaisie'].elements['prenom'];
  if(elt.value != "") {
    return true;
  }
  else {
    alert("Saisissez le prénom");
    return false;
  }
}
        

C'est une méthode qui fonctionne sur tous les navigateurs. Tout comme la solution suivante.

Utilisation de this

Le mot clé this désigne toujours l'objet courant. Si on l'utilise lors de l'appel de la fonction valider() dans le "onsubmit", on peut transmettre l'objet formulaire à la fonction valider() :

<script type="text/javascript">

//<![CDATA[

function valider(frm){
  if(frm.elements['prenom'].value != "") {
    return true;
  }
  else {
    alert("Saisissez le prénom");
    return false;
  }
}

//]]>
</script>

<form onsubmit="return valider(this)" id="frmSaisie" …>
…
</form>
        

À noter une petite astuce au passage : si vous avez besoin de faire des manipulations du formulaire Javascript sur des événements des champs de saisie ou de boutons, sachez que les objets Javascript correspondants à ces éléments HTML ont une propriété form représentant l'objet formulaire. Voici un exemple d'utilisation :

<script type="text/javascript">
//<![CDATA[

function afficher(frm){
  alert("Vous avez tapé : " + frm.elements['prenom'].value)
}
//]]>
</script>

<form>
  <p>

    <label for="prenom">Saisissez votre prénom :</label>
    <input type="text" name="prenom" id="prenom" />
    <input type="button" value="Afficher" onclick="afficher(this.form)" />
    <input type="submit" value="Ok" />

  </p>
</form>
        

Les commentaires dans la balise script

En théorie, le code situé entre les balises script, doit être encadré par <![CDATA[ et ]]>. C'est la manière en XHTML d'indiquer que le contenu représente des données.

En HTML, il faut utiliser les délimiteurs de commentaires HTML, à savoir <!-- et -->, pour éviter que le code javascript ne s'affiche dans les anciens navigateurs.

Pour que le contenu de la balise script en XHTML soit interpreté correctement, quel que soit le navigateur (pas trop vieux, de l'époque de IE6 par exemple), y compris donc ceux qui ne connaissent pas XHTML, il faut alors utiliser l'astuce suivante :

<script type="text/javascript">
//<![CDATA[
...
//]]>
</script>
   

La façon la plus simple et celle qui garantie une parfaite compatibilité entre les navigateurs, est de mettre le script dans un fichier séparé :

<script type="text/javascript" src="nom_de_mon_fichier.js"></script>
    

Conclusion

Si la validation en JavaScript est pratique pour l'utilisateur, il convient de la développer correctement de façon à rester compatible avec tous les types de navigateurs et d'usages. Pour cela, le recours au bouton submit s'impose !

À propos de cet article

  • Openweb.eu.org
  • Technologie : DOM
  • Thème : Accessibilité, Pages dynamiques
  • Auteur :
  • Publié le :
  • Mise à jour : 14 mai 2008
  • 34 commentaires

Vos commentaires

  • Anonyme Le 29 juillet 2010 à 09:57

    Un article clair et precis. !
    Javascript reste néanmoins pour moi un sous-langage a ne pas mettre entre toutes les mains de bidouilleurs ou plutôt scriptouilleurs. (ss langage car pas assez de sécurité, pas de typage, trop de variante, lié aux navigateurs et j’en passe)

  • Jones Le 20 novembre 2010 à 16:47

    très bonne explications !
    Le seul problème avec submit est qu’on est obligé de recharger de page ce que l’on voudrait parfois pas vraiment avec javascript...

  • Goldorak Le 14 janvier 2011 à 10:03

    Superbe documentation ! Si tous les tutos pouvaient être de cette qualité...!

    Merci Laurent !

  • Seb Le 28 janvier 2011 à 03:41

    "La plupart des statistiques rapportent que c’est le cas pour 5 à 7% des internautes."
    Aujourd’hui, en 2011, ce taux est inférieur à 2%
    Un article où des tests on été effectués sur les visiteurs de Yahoo :http://dev.neowebmag.com/javascript-ajax/combien-de-visiteurs-desactivent-javascript

    Le taux moyen de JavaScript désactivé oscille autour de 1,3% des visiteurs réels (1,46% pour la France), avec pour taux le plus élevé près 2% aux États-Unis et le plus bas autour de 0,25% au Brésil.

    Des témoignages pour de plus petits sites, donnent des résultats toujours inférieurs à 1%.

  • Seb Le 28 janvier 2011 à 03:42

    "La plupart des statistiques rapportent que c’est le cas pour 5 à 7% des internautes."
    Aujourd’hui, en 2011, ce taux est inférieur à 2%
    Un article où des tests on été effectués sur les visiteurs de Yahoo :http://dev.neowebmag.com/javascript-ajax/combien-de-visiteurs-desactivent-javascript

    Le taux moyen de JavaScript désactivé oscille autour de 1,3% des visiteurs réels (1,46% pour la France), avec pour taux le plus élevé près 2% aux États-Unis et le plus bas autour de 0,25% au Brésil.

    Des témoignages pour de plus petits sites, donnent des résultats toujours inférieurs à 1%.

  • GUI Le 4 février 2011 à 10:29 En réponse à : Jones

    Pas avec le XHR !!!!
    Si ton but est d’éviter de recharger les pages, tu utilises Ajax, donc tu peux faire des submit sans recharcger la page. C’est le but !

  • Anonyme Le 26 mai 2011 à 09:13

    Cool les explications... merci ! Je passais par hasard et voilà que je tobe sur ce bonheur ! J’ai vrament apprecié ce mini tuto-conseil

  • Anonyme Le 31 mai 2011 à 12:39

    Super !
    Merci ! enfin un article clair, simple et précis, bravo !

  • mouhibi Le 1er juin 2011 à 11:38

    waaaaaaaaaw je peux rien dire sourire

  • mouhibi Le 1er juin 2011 à 12:17 En réponse à : Anonyme

    tres bonne expliquation sourire
    merci

  • Asmaa Le 8 juin 2011 à 22:09

    merciiiiiii bcp pour cet article

  • Kach Le 24 août 2011 à 13:36

    Enfin des réponses à mes questions.

    Merci

  • Kiki Le 21 septembre 2011 à 09:44

    Parfaite et concis, cette explication expose bien les erreurs à ne pas commettre ! Moi même en BTS informatique de Gestion 2ème année, ce rappel ne peut faire que du bien ! Merci !

  • medalimeziane Le 9 février 2012 à 14:26

    Salut,
    Je veux remercier mon ami Google qui m’a emmené de la Tunisie jusqu’ici sur cette page.

    Merci pour à Laurent Jouanneau de cet article clair et complet qui reste encore une référence malgrès le passage de presque 8 ans déjà.

    Toutefois, j’espère trouver une aussi complète explication sur la meilleure validation coté serveur en PHP.

    Encore merci..

  • Anonyme Le 24 février 2012 à 22:22

    Merci pour ce très bon article sourire

  • amateur Le 23 septembre 2012 à 17:45

    Merci beaucoup pour ces explications qui m’ont beaucoup éclairé.

  • XcentY Le 26 octobre 2012 à 08:57

    Je ne m’avancerai pas pour dire que telle ou telle manière choisie par un développeur est une erreur et que l’auteur est la bonne et unique manière de faire.
    Le problème de son "onSubmit()" avec la validation par la touche Return est pour moi le plus gros soucis puisque des utilisateurs inexpérimentés valideraient le formulaire avant d’avoir rempli tous les champs. De plus, les gens qui utilisent le clavier, naviguent dans le formulaire avec la touche de tabulation et il n’y a rien qui empêche de valider le formulaire en tapant la touche Return quand la tabulation arrive sur le bouton.

  • Laurentj Le 21 novembre 2012 à 09:19

    @XcentY
    >Le problème de son "onSubmit()" avec la validation par la touche Return
    Il n’y a aucun problème avec la touche return ou tab : dans le script JS du onsubmit, qui est appelé quand on appuie sur Return ou que l’on clique sur le bouton de submit, à vous de vérifier le contenu du formulaire et de renvoyer true ou false (ou de faire un preventDefault() sur l’event sbmit), pour accepter ou non l’envoi du formulaire.

    Bref, si le JS du onsubmit est correctement fait, le formulaire ne peut être envoyé au serveur si le contenu n’est pas valide.

    Et de toute manière, il faut aussi COTE SERVEUR, toujours valider les données qui sont soumises, car le JS peut avoir buggé dans la page, ou que l’utilisateur a désactivé le JS dans son navigateur, ou encore que le formulaire est envoyé par un robot (cas des outils pour spammer).
    Donc non, il n’y a aucun souci si le développeur fait une bonne vérification des données à la fois coté client (en js) et coté serveur (ce qui est le plus important).

  • rick des bois Le 19 février 2013 à 11:41

    Merci ce tuto clair et concis m’a beaucoup aidé dans mon apprentissage. clin d'œil

  • sarah Le 8 mars 2013 à 21:29

    Hello, merci pour cet article. J’étais sur un tuto qui s’est révélé incomplet en fait ! grace à vous j’ai trouvé l’erreur. Thx.

  • sami Le 19 mars 2013 à 10:49

    c’est très bien

  • emma Le 19 mars 2013 à 17:30

    bonjour

    Merci pour votre tuto qui est super bien expliqué
    j’aimerais savoir comment vous gérez la vérification de plusieurs champs ?
    quelle est la meilleure méthode pour vous ?
    Personnellement, j’ai fais des if imbriqués.

    merci par avance pour votre avis

  • Béryl Le 20 mars 2013 à 18:49

    Tuto clair, précis et fouillé.
    Les exemples sont simples et utilisables immédiatement.
    Les mises en garde sont particulièrement pertinentes.

    Bravo et merci à Laurent, son auteur, de nous guider aussi bien.

  • B Le 20 mars 2013 à 20:00

    A l’attention d’Emma (19 mars 17:30)
    Une tentative pour vous donner le listing de la façon de faire que j’ai adoptée n’ayant pu aboutir du fait que toutes les accolades ne ressortaient pas, je vous propose de vous l’envoyer par mail si vous le souhaitez.
    Il s’agit en fait de répéter, dans un fichier que j’appelle verif.js, la formule suivante autant de fois qu’il y a de champs de formulaire à vérifier :

    if (condition sur le champ)
    [accolade] alerte += "\n- Nom" ; n=n+1 ; test=false [accolade]

    en ayant pris le soin d’initialiser alerte à "", n à 0, test à true.
    On termine en vérifiant la valeur de n :
    - 0 : on sort sans alerte ;
    - 1 : message d’erreur au singulier et liste des erreurs concaténées dans "alerte" ;
    - 2 : comme ci-dessus pour 1, mais message d’erreur au pluriel.
    L’émission du message d’erreur consiste à écrire alert(alerte).
    On termine par un "return test" (sans les guillemets).

    Pour être complet, on place la ligne suivante entre les balises et du fichier du formulaire :

    <script type="text/javascript" src="verif.js"></script>

    Cordialement

  • Béryl Le 20 mars 2013 à 20:04

    Oups !
    Le message précédent est parti un peu vite.

    A l’attention d’Emma (19 mars 17:30)

    Une tentative pour vous donner le listing de la façon de faire que j’ai adoptée n’ayant pu aboutir du fait que toutes les accolades ne ressortaient pas, je vous propose de vous l’envoyer par mail si vous le souhaitez. Il s’agit en fait de répéter, dans un fichier que j’appelle verif.js, la formule suivante autant de fois qu’il y a de champs de formulaire à vérifier :

    if (condition sur le champ) [accolade] alerte += "\n- Nom" ; n=n+1 ; test=false [accolade]

    en ayant pris le soin d’initialiser alerte à "", n à 0, test à true. On termine en vérifiant la valeur de n :
    - 0 : on sort sans alerte ;
    - 1 : message d’erreur au singulier et liste des erreurs concaténées dans "alerte" ;
    - 2 : comme ci-dessus pour 1, mais message d’erreur au pluriel. L’émission du message d’erreur consiste à écrire alert(alerte). On termine par un "return test" (sans les guillemets).

    Pour être complet, on place la ligne suivante entre les balises et du fichier du formulaire :

    <script type="text/javascript" src="verif.js"></script>

    Cordialement

  • Jiji Le 5 avril 2013 à 12:12

    Très clair ; merci

  • Koffi Le 29 mai 2013 à 10:52

    Très bon tuto. Je dirai tout simplement, Bravo !

  • Webmaster Le 29 mai 2013 à 19:20

    je veux savoir comment vérifier une adresse e-mail
    un exemple svp
    cordialement

  • Mohcine Le 19 juin 2013 à 16:22

    Un très bon article,

    Merci à vous tous

  • zeboudja Le 3 juillet 2013 à 10:13

    Merci pour cette clarté

  • nobody Le 11 septembre 2013 à 14:24

    Bonjour,

    les méthodes indiquées ici sont idéales, (vérification côté serveur, et client, usage du onsubmit et du input submit) cependant, la réalité et l’évolution des techniques change quelque peu la donne.

    A l’heure de l’Ajax, avec un usage intensif du JavaScript, et une standardisation des différentes implémentations, il devient de plus en plus rare de trouver des sites fonctionnant SANS JavaScript. En effet, le confort et les fonctionnalités que procure l’utilisation de XHR, font qu’il est parfois impossible de faire un site équivalent sans activation du JavaScript.

    C’est malheureusement au dépend des personnes à besoins spécifiques comme avec les lecteurs Braille, ou audio. (bien que de nombreux systèmes le gèrent de nos jours également).

    l’activation ou non du JavaScript est devenu un problème exceptionnel (ce que montre les différentes enquêtes...).

    Quant au "input submit", c’est alors les graphistes des applications qui s’arrachent les cheveux par manque de standardisation de l’apparence de ces derniers qui peuvent vous ruiner une belle page.

    Quant aux handicap visuels, c’est souvent plus du ressort d’une bonne présentation et d’une gestion propre du CSS que cela se trouve gérer.

    J’encourage néanmoins l’utilisation autant que possible des bonnes pratiques ci-dessus énoncées, mais parfois il faut savoir faire quelques exceptions.

  • andy Le 31 mars 2014 à 17:26

    super explication, merci ! on ne peut pas être plus clair. enfin une aide en programmation bien expliquée !

  • nesrine Le 14 mai 2014 à 19:24

    je veut changer l’apparence des messages d’alerte pouvez vous m’aider voici le code
    function verifClient()

    var val3 =document.getElementById("val3").value ;
    var forme2 = document.getElementById("forme2") ;

    $.ajax(
    url : "ajaxSupClinet.php",
    type : "get",
    data : "name=" + val3 ,

    success : function(resultat)

    if( $.trim(resultat) == "true" && confirm (’Voulez vous supprimer le client ?’ ))

    alert("Client supprimée") ;
    forme2.submit() ;

    else

    alert("Client inexistant") ;
    return false ;


    ) ;


  • Elodie Le 4 juillet à 11:28

    Excellent article

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici
  • Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Suivre les commentaires : RSS 2.0 | Atom