Je ne comprends pas le but de la balise form en html.

Je peux facilement utiliser parfaitement n'importe quel type d'entrée sans utiliser la balise form. Il semble presque redondant de l'enrouler autour des entrées.

De plus, si j'utilise ajax pour appeler une page côté serveur, je peux simplement utiliser jQuery pour cela. La seule exception est que j'ai remarqué que vous devez envelopper un script de téléchargement autour d'une balise de formulaire pour une raison quelconque.

Alors pourquoi les formulaires sont-ils encore si largement utilisés pour des choses simples comme les entrées de texte? Cela semble être une chose très archaïque et inutile à faire.

Je n'en vois tout simplement pas l'avantage ou la nécessité. Peut-être que je manque quelque chose.

Ce qui vous manque, c'est une compréhension du balisage sémantique et du DOM.

De manière réaliste, vous pouvez à peu près faire ce que vous voulez avec le balisage HTML5, et la plupart des navigateurs l'analyseront. La dernière fois que j'ai vérifié, WebKit / Blink autorise même des pseudo-éléments à l'intérieur des <input>éléments , ce qui est une violation flagrante de la spécification - Gecko pas tellement. Cependant, faire ce que vous voulez avec votre balisage l'invalidera sans aucun doute en ce qui concerne la sémantique.

Pourquoi mettons-nous des <input>éléments à l'intérieur des <form>éléments? Pour la même raison, nous mettons des <li>balises à l'intérieur de<ul><ol> éléments et - c'est là qu'ils appartiennent. C'est sémantiquement correct et aide à définir le balisage. Les analyseurs, les lecteurs d'écran et divers logiciels peuvent mieux comprendre votre balisage lorsqu'il est sémantiquement correct - lorsque le balisage a un sens, pas seulement une structure.

le <form> élément vous permet également de définir methodet actionattributs, ce qui indique au navigateur que faire lorsque le formulaire est soumis. AJAX n'est pas un outil de couverture à 100%, et en tant que développeur Web, vous devez pratiquer la dégradation gracieuse - les formulaires doivent pouvoir être soumis et les données transférées, même lorsque JS est désactivé.

Enfin, les formulaires sont tous correctement enregistrés dans le DOM. Nous pouvons y jeter un coup d'œil avec JavaScript. Si vous ouvrez votre console sur cette même page, et tapez:

document.forms

Vous obtiendrez une belle collection de tous les formulaires de la page. La barre de recherche, les zones de commentaires, la zone de réponse - tous les formulaires appropriés. Cette interface peut être utile pour accéder aux informations et interagir avec ces éléments. Par exemple, les formulaires peuvent être sérialisés très facilement.

Voici du matériel de lecture:

• HTML sémantique
• Guide des formulaires HTML

Remarque: <input> éléments peuvent être utilisés en dehors des formulaires, mais si votre intention est de soumettre des données de quelque manière que ce soit, vous devez utiliser un formulaire.

C'est la partie de la réponse où je retourne la question.

Comment rendre ma vie plus difficile en évitant les formes?

D'abord et avant tout - les éléments de conteneur. Qui en a besoin, non?!

Certes, vos petits éléments <input>et <button>sont imbriqués dans une sorte d'élément conteneur? Ils ne peuvent pas simplement flotter au milieu de tout le reste. Alors si ce n'est pas un <form>, alors quoi? A <div>? UNE<span> ?

Ces éléments doivent résider quelque part, et à moins que votre balisage ne soit un gâchis fou, l'élément conteneur peut simplement être un formulaire.

Non? Oh.

À ce stade, les voix dans ma tête sont très curieuses de savoir comment vous créez vos gestionnaires d'événements pour toutes ces différentes situations AJAX. Il doit y en avoir beaucoup, si vous devez réduire votre balisage pour économiser des octets. Ensuite, vous devez créer des fonctions personnalisées pour chaque événement AJAX qui correspond à chaque «ensemble» d'éléments - que vous devez avoir à cibler individuellement ou avec des classes, non? Il n'y a aucun moyen de vraiment regrouper ces éléments de manière générique, puisque nous avons établi qu'ils se déplaçaient simplement autour du balisage, en faisant tout ce qui est nécessaire jusqu'à ce qu'ils soient nécessaires.

Donc, vous personnalisez le code de quelques gestionnaires.

$('#searchButton').on('click', function (e) {
  e.preventDefault();

  var search = $('#mySearch');

  $.ajax({
    url: 'http://example.com/text',
    type: 'GET',
    dataType: 'text',
    data: 'query=' + search.val(),
    success: function (data) {
      console.log(data);
    }
  });
});


$('#login').on('click', function (e) {
  e.preventDefault();
  var user = $('#username'),
      pass = $('#password'),
      rem = $('#remember');
  
  $.ajax({
    url: 'http://example.com/login',
    type: 'POST',
    data: user.add(pass, rem).serialize(),
    dataType: 'text',
    success: function (data) {
      console.log(data);
    }
  });
});

<!-- No containers, extra markup is silly. -->

<input type="text" id="mySearch" value="query" />
<button id="searchButton">Search</button>
<input type="text" id="username" name="username" value="user" />
<input type="password" id="password" name="password" value="pass" />
<input type="checkbox" id="remember" name="remember" checked /> stay logged in
<button id="login">Login</button>

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>

C'est la partie où vous dites quelque chose comme:

«J'utilise cependant totalement des fonctions réutilisables. Arrêtez d'exagérer.

Assez juste, mais vous devez toujours créer ces ensembles d'éléments uniques ou des ensembles de classes cibles, n'est-ce pas? Tu dois encore grouper ces éléments d'une manière ou d'une autre.

Prêtez-moi vos yeux (ou vos oreilles, si vous utilisez un lecteur d'écran et avez besoin d'aide - bonne chose que nous pourrions ajouter un peu d' ARIA à tout ce balisage sémantique , n'est-ce pas?), Et voyez la puissance de la forme générique.

function genericAjaxForm (e) {
  e.preventDefault();
  var form = $(this);
  
  return $.ajax({
    url: form.attr('action'),
    type: form.attr('method'),
    dataType: form.data('type'),
    data: form.serialize()
  });
}

$('#login-form').on('submit', function (e) {
  genericAjaxForm.call(this, e).done(function (data) {
    console.log(data);
  });
});

<form action="http://example.com/login" method="POST" data-type="text" id="login-form">
  <input type="text" name="username" value="user" />
  <input type="password" name="password" value="mypass" />
  <label>
    <input type="checkbox" name="remember" /> Remember me
  </label>

  <button type="submit">Login</button>
</form>

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>

Nous pouvons l'utiliser avec n'importe quelle forme courante, maintenir notre dégradation gracieuse et laisser la forme décrire complètement comment elle devrait fonctionner. Nous pouvons étendre cette fonctionnalité de base tout en conservant un style générique - plus modulaire, moins de maux de tête. Le JavaScript s'inquiète juste de ses propres choses, comme cacher les éléments appropriés ou gérer les réponses que nous obtenons.

Et maintenant tu dis:

'Mais j'emballe mes pseudo-formulaires dans des <div>éléments qui ont des ID spécifiques - je peux alors cibler les entrées de manière lâche avec avec .find, et .serializeeux, et ...'

Oh, qu'est-ce que c'est? Vous enveloppez réellement vos <input>éléments dans un conteneur?

Alors pourquoi n'est-ce pas encore une forme?

Les balises de formulaire sont toujours nécessaires si vous souhaitez pouvoir soumettre le formulaire sans AJAX (ce qui peut être utile dans les premiers stades de développement). Mais même s'il est possible d'utiliser javascript pour soumettre des données sans balise de formulaire, quelques avantages viennent à l'esprit:

1. L'utilisation de balises de formulaire peut aider les gens à lire et à comprendre votre code dans certains cas, en leur montrant vos intentions.
2. La méthode «soumettre» est disponible sur les formulaires. Si vous avez un formulaire avec une entrée [type = soumettre], et qu'il n'est pas désactivé, alors quand quelqu'un clique sur «entrer» tout en remplissant l'une des autres entrées du formulaire, le formulaire sera soumis. Vous pouvez toujours le faire en écoutant l'événement 'keydown' sur les éléments d'entrée, mais c'est un peu d'interface utilisateur que vous obtenez gratuitement avec les balises de formulaire.
3. Il y a quelques autres choses qui ne fonctionnent qu'avec une balise de formulaire ou qui sont plus faciles avec une balise de formulaire. Les développeurs finiront par tomber sur ces cas et décideront qu'il est plus facile de toujours les utiliser partout et d'éviter les problèmes. Vraiment, la vraie question est, pourquoi ne pas utiliser une balise de formulaire?

L'élément HTML représente une section de document qui contient des contrôles interactifs pour soumettre des informations à un serveur Web.

Nous connaissons tous les formulaires sur les pages Web HTML. Pour de nombreuses raisons, des personnes ou des entreprises demandent nos adresses e-mail, noms et URL de site. L'achat de produits sur Internet est aujourd'hui un jeu d'enfant et avec l'avènement des dispositifs de sécurité, la méthode utilisée pour soumettre vos coordonnées et l'argent durement gagné est généralement effectuée via des formulaires.

Plus d'informations

lier un

lier deux

J'ai eu un scénario où une seule page Web avait 3 formulaires, qui avaient tous des champs de courrier électronique séparés (avec des ID différents). Je les ai enveloppés séparément <div>au début. Le remplissage automatique iOS sur Safari s'est comporté étrangement jusqu'à ce que je les entoure tous de <form>balises. L'un des formulaires n'avait qu'un seul champ de saisie, pour l'inscription à la newsletter. Lorsque l'utilisateur remplissait automatiquement cette entrée, la page Web faisait défiler jusqu'au champ de saisie suivant situé sur une partie différente de la page.

Alors, merci Oka pour ce long message. Les balises avec une signification sémantique doivent être utilisées autant que possible, car vous ne savez jamais quel navigateur / appareil ne gère pas bien les autres solutions.