Soumettre un formulaire - question existentielle

Bonjour,

Je connais plusieurs moyens de soumettre un formulaire. La balise <a> avec du javascript, le input type button, qui si l'on veut faire du contrôle de champ nécessite aussi du javascript. Il y a aussi peut être d'autres façon de faire avec d'autres balises dès l'instant où l'on joue avec le focus et onclick.

- Doit on privilégier le button pour respecter la sémantique, accessibilité, et dans ce cas, peut on habiller aussi joliement un input type button que la balise <a> ? (coins arrondis, background, .... ) ou pas ?

- Au passage : comment faire pour que quelqu'un qui n'a pas javascript puisse soumettre le formulaire malgré tout ?

Merci pour votre aide,

Sylvain.

Salut,

Pour soumettre un formulaire, tu as également l'élément input avec l'attribut type de valeur "submit".

Qu'on utilise ou non du JavaScript, il est indispensable de toujours vérifier les données envoyées par le formulaire côté serveur, grâce à un langage côté serveur comme PHP. D'une part, les utilisateurs chez lesquels JavaScript est désactivé ne seront pas pénalisés et, d'autre part, la vérification côté serveur permet de se prémunir de certains risques liés à la sécurité de l'application (soumission de code ou de fichier exécutable nuisible, utilisation d'un formulaire de contact comme serveur de spams, sans oublier l'envoi de données ne correspondant pas aux valeurs attendues).

websylvain a écrit :
La balise <a> avec du javascript, le input type button (...). Il y a aussi peut être d'autres façon de faire avec d'autres balises dès l'instant où l'on joue avec le focus et onclick.

OK, à priori tout ça c'est QUE des mauvaises solutions. Car toutes dépendent inutilement de JavaScript.
Les solutions qui vont bien:

<input type="submit" value="Envoyer" />
<input type="image" alt="Envoyer" src="envoyer.png" />
<button type="submit">Envoyer</button>

websylvain a écrit :
le input type button, qui si l'on veut faire du contrôle de champ nécessite aussi du javascript

Le contrôle des données envoyées se fait côté serveur. Ya pas à tortiller.
Le vérification en JavaScript est un bonus pour améliorer l'ergonomie (validation automatique en cours de saisie, plutôt qu'au moment de l'envoi). Si c'est au moment de l'envoi que tu fais une validation en JavaScript, il y a un souci.

Enfin, pour la mise en forme:
- Un INPUT de type "image" permet d'utiliser une image. (Penser à renseigner le texte alternatif.)
- On peut faire pas mal de choses en CSS sur un INPUT ou un BUTTON de type "submit". Mais certains navigateurs, surtout les anciens (IE6 et IE7) peuvent avoir du mal avec certaines propriétés, donc ça demande de bien tester.

Bonjour,

Désolé pour le retard, je me suis absenté

Concernant les contrôles côté serveur, bien évidemment. Je ne voulais pas aborder ce sujet car pour moi, c'est un acquis. Et cela ne doit pas non plus être mis en opposition avec les contrôles javascript qui sont là pour aider le client, et alléger le serveur dans la majorité des cas.

Pour les contrôles javascript, je ne les fait pas en sortie de focus d'un champ car cela complique les contrôles croisés de champs, et peut malgré tout s'avérer trop intrusif, à peine la saisie commencée. Je le ferais donc à la soumission du formulaire, comme très souvent.

Mais puisque l'on parle accessibilité, quelquesoit le choix entre

<input type="submit" value="Envoyer" /> 
<input type="image" alt="Envoyer" src="envoyer.png" /> 
<button type="submit">Envoyer</button>

si le javascript est désactivé, je ne vois pas bien comment cela fonctionnerait, hormis peut être créer une fonction submit() , qui trappe la soumission, fait les contrôles, et ensuite un form.submit . Pour les personnes ayant désactiver le javascript, la soumission se ferait directement. il faudra que j'essaye.

question subsidiaire : avec le type image, je ne vois pas bien comment faire , hormis utiliser du jaascript, ce qui contredit l'idée de soumission possible sans javascript , non ?

Pourquoi aller chercher midi à quatorze heures? Un <input type="image" />, pourquoi pas, si vraiment on a une image de fou en background (encore que...). Pourquoi ne pas tout simplement utiliser cette superbe chose qu'on appelle CSS:

input[type=submit]{
border: 1px solid #000000;
-moz-border-radius: 8px; /*Je ne mets que firefox, pour plus de lisibilité*/
background-color: orange;
color: green;
font-size: 135%;
/*etc...etc... (j'ai mis des couleurs au hasard hein^^)*/

Tellement mieux qu'une image ou que le bouton par défaut. Non?

websylvain a écrit :
Pour les contrôles javascript, je ne les fait pas en sortie de focus d'un champ car cela complique les contrôles croisés de champs, et peut malgré tout s'avérer trop intrusif, à peine la saisie commencée. Je le ferais donc à la soumission du formulaire, comme très souvent.

Dans ce cas je ne vois pas l'intérêt par rapport à une soumission directe du formulaire, contrôle côté serveur, et en cas d'erreur on réaffiche la page avec les données saisies en rajoutant des messages d'erreur bien visibles. JavaScript ne devrait servir qu'à gagner en réactivité en fournissant un feedback plus direct.

websylvain a écrit :
si le javascript est désactivé, je ne vois pas bien comment cela fonctionnerait

Tu n'as jamais fait de formulaire HTML sans utiliser JavaScript?

websylvain a écrit :
créer une fonction submit() , qui trappe la soumission, fait les contrôles, et ensuite un form.submit . Pour les personnes ayant désactiver le javascript, la soumission se ferait directement. il faudra que j'essaye.

C'est le fonctionnement standard d'une validation de formulaire en JavaScript. Tu interceptes l'évènement de soumission du formulaire, fais tes tests, en cas d'erreur tu manipules le DOM pour rajouter des messages d'erreur et tu bloques la soumission avec un return false. Si pas d'erreur tu retournes "true" et puis voilà, la soumission du formulaire n'est pas bloquée (il me semble...).

websylvain a écrit :
avec le type image, je ne vois pas bien comment faire

Cliquer sur un <input type="image" ...> soumet le formulaire. C'est dans la spec HTML4, pour mémoire.
http://www.w3.org/TR/html4/

Salut,

Florent V. a écrit :
en cas d'erreur tu manipules le DOM pour rajouter des messages d'erreur et tu bloques la soumission avec un return false. Si pas d'erreur tu retournes "true" et puis voilà, la soumission du formulaire n'est pas bloquée (il me semble...).

Yep. Ou plus précisément tu te contentes de ne pas retourner false.

Florent V. a écrit :


C'est le fonctionnement standard d'une validation de formulaire en JavaScript. Tu interceptes l'évènement de soumission du formulaire, fais tes tests, en cas d'erreur tu manipules le DOM pour rajouter des messages d'erreur et tu bloques la soumission avec un return false. Si pas d'erreur tu retournes "true" et puis voilà, la soumission du formulaire n'est pas bloquée (il me semble...).

Note, c'est l'événement submit sur le formulaire qu'il faut intercepter, pas l'événement click sur le bouton.

L'intérêt, c'est qu'il est aussi déclenché si l'utilisateur appuie sur 'entrée'. (et aussi sur le form.submit() il me semble)

Et il suffit de retourner false pour bloquer le submit, autrement le submit est fait (donc, ne pas faire de form.submit() !)

Florent V. a écrit :

Dans ce cas je ne vois pas l'intérêt par rapport à une soumission directe du formulaire, contrôle côté serveur, et en cas d'erreur on réaffiche la page avec les données saisies en rajoutant des messages d'erreur bien visibles. JavaScript ne devrait servir qu'à gagner en réactivité en fournissant un feedback plus direct.

Pas vraiment d'accord. Cela évite la surcharge "inutile" côté serveur.

Florent V. a écrit :

Tu n'as jamais fait de formulaire HTML sans utiliser JavaScript?

Un formulaire tout bête, je suis d'accord avec toi.

julienw a écrit :

Note, c'est l'événement submit sur le formulaire qu'il faut intercepter, pas l'événement click sur le bouton.

L'intérêt, c'est qu'il est aussi déclenché si l'utilisateur appuie sur 'entrée'. (et aussi sur le form.submit() il me semble)

Et il suffit de retourner false pour bloquer le submit, autrement le submit est fait (donc, ne pas faire de form.submit() !)

Oui c'est vrai. mais comment fais tu si tu as un bouton save, et un autre draft, avec chacun une fonction différente. check(), et checklite() (moins de contrôle pour enregistrer le brouillon).

websylvain a écrit :


Oui c'est vrai. mais comment fais tu si tu as un bouton save, et un autre draft, avec chacun une fonction différente. check(), et checklite() (moins de contrôle pour enregistrer le brouillon).

c'est autre chose

côté serveur, avec des "name" différents sur tes input submit, tu peux gérer côté serveur.
Côté client, tu vas peut-être être obligé de mettre des onclick. Je sais pas trop trop je t'avoue.

julienw a écrit :

côté serveur, avec des "name" différents sur tes input submit, tu peux gérer côté serveur.

j'ai pas de soucis côté serveur, je sais m'y retrouver sans pb. tout est articulé avec un framework php.

julienw a écrit :

Côté client, tu vas peut-être être obligé de mettre des onclick. Je sais pas trop trop je t'avoue.

ouais, je crois que c'est le problème. ce qui revient un peu à utiliser des type button. enfin pas tout à fait car le gars sans javascript pourra quand même soumettre le formulaire.

websylvain a écrit :


ouais, je crois que c'est le problème. ce qui revient un peu à utiliser des type button. enfin pas tout à fait car le gars sans javascript pourra quand même soumettre le formulaire.

Ouaip mais il faudra côté serveur que tu décides quelle action effectuer dans ce cas.