No entiendo el propósito de la etiqueta de formulario en html.

Puedo usar fácilmente cualquier tipo de entrada perfectamente sin usar la etiqueta de formulario. Casi parece redundante envolverlo alrededor de las entradas.

Además, si estoy usando ajax para llamar a una página del lado del servidor, simplemente puedo usar jQuery para eso. La única excepción es que noté que, por alguna razón, tienes que envolver un script de carga alrededor de una etiqueta de formulario.

Entonces, ¿por qué los formularios todavía se usan tan ampliamente para cosas simples como entradas de texto? Parece una cosa muy arcaica e innecesaria.

Simplemente no veo el beneficio o la necesidad de ello. Quizás me estoy perdiendo algo.

Lo que le falta es una comprensión del marcado semántico y del DOM.

Siendo realistas, puedes hacer prácticamente lo que quieras con el marcado HTML5, y la mayoría de los navegadores lo analizarán. La última vez que verifiqué, WebKit / Blink incluso permite pseudoelementos dentro de <input>elementos , lo cual es una clara violación de la especificación; Gecko no tanto. Sin embargo, hacer lo que quiera con su marcado lo invalidará indudablemente en lo que respecta a la semántica.

¿Por qué ponemos <input>elementos dentro de <form>elementos? Por la misma razón, colocamos <li>etiquetas dentro de los elementos <ul>y <ol>: es donde pertenecen. Es semánticamente correcto y ayuda a definir el marcado. Los analizadores, lectores de pantalla y varios programas de software pueden comprender mejor su marcado cuando es semánticamente correcto, cuando el marcado tiene significado, no solo estructura.

El <form>elemento también le permite definir methody actionatributos, que indican al navegador qué hacer cuando se envía el formulario. AJAX no es una herramienta de cobertura del 100% y, como desarrollador web, debe practicar una degradación elegante: los formularios deben poder enviarse y transferirse los datos, incluso cuando JS está apagado.

Finalmente, todos los formularios se registran correctamente en el DOM. Podemos echar un vistazo a esto con JavaScript. Si abre su consola en esta misma página y escribe:

document.forms

Obtendrá una buena colección de todos los formularios de la página. La barra de búsqueda, los cuadros de comentarios, el cuadro de respuestas: todos los formularios adecuados. Esta interfaz puede ser útil para acceder a información e interactuar con estos elementos. Por ejemplo, los formularios se pueden serializar muy fácilmente.

Aquí hay material de lectura:

• HTML semántico
• Guía de formularios HTML

Nota: los <input>elementos se pueden usar fuera de los formularios, pero si su intención es enviar datos de alguna manera, debe usar un formulario.

Esta es la parte de la respuesta en la que le doy la vuelta a la pregunta.

¿Cómo hago mi vida más difícil evitando las formas?

En primer lugar, elementos contenedores. ¿Quién los necesita, verdad?

Ciertamente, sus elementos pequeños <input>y <button>están anidados dentro de algún tipo de elemento contenedor. No pueden simplemente estar flotando en medio de todo lo demás. Entonces, si no es un <form>, ¿entonces qué? A <div>? A <span>?

Estos elementos tienen que residir en algún lugar y, a menos que su marcado sea un desastre, el elemento contenedor puede ser simplemente una forma.

¿No? Oh.

En este punto, las voces en mi cabeza tienen mucha curiosidad sobre cómo crear sus controladores de eventos para todas estas diferentes situaciones AJAX. Debe haber mucho, si necesita reducir su marcado para ahorrar bytes. Luego, debe crear funciones personalizadas para cada evento AJAX que corresponda a cada 'conjunto' de elementos, que debe tener para apuntar individualmente o con clases, ¿verdad? No hay forma de agrupar realmente estos elementos de forma genérica, ya que hemos establecido que simplemente deambulan por el marcado, haciendo lo que sea hasta que sean necesarios.

Así que personalizas el código de algunos controladores.

$('#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>

Esta es la parte en la que dices algo como:

Sin embargo, utilizo totalmente funciones reutilizables. Deja de exagerar.

Es bastante justo, pero aún necesita crear estos conjuntos de elementos únicos, o conjuntos de clases de destino, ¿verdad? Todavía tienes que agrupar estos elementos de alguna manera.

Préstame tus ojos (u oídos, si estás usando un lector de pantalla y necesitas ayuda, es bueno que podamos agregar algo de ARIA a todo este marcado semántico , ¿no?), Y contempla el poder de la forma genérica.

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>

Podemos usar esto con cualquier forma común, mantener nuestra elegante degradación y dejar que la forma describa completamente cómo debería funcionar. Podemos ampliar esta funcionalidad básica manteniendo un estilo genérico : más modular, menos dolores de cabeza. El JavaScript solo se preocupa por sus propias cosas, como ocultar los elementos apropiados o manejar cualquier respuesta que obtengamos.

Y ahora dices:

'Pero envuelvo mis pseudo-formularios en <div>elementos que tienen ID específicos; luego puedo apuntar las entradas libremente con .find, y .serializeellos, y ...'

¿Oh, qué es eso? ¿De verdad envuelves tus <input>elementos en un contenedor?

Entonces, ¿por qué no es una forma todavía?

Las etiquetas de formulario siguen siendo necesarias si desea poder enviar el formulario sin AJAX (que puede ser útil en las primeras etapas de desarrollo). Pero a pesar de que es posible usar javascript para enviar datos sin una etiqueta de formulario, todavía me vienen a la mente algunos beneficios:

1. El uso de etiquetas de formulario puede ayudar a las personas a leer y comprender su código en algunos casos, mostrándoles sus intenciones.
2. El método 'enviar' está disponible en formularios. Si tiene un formulario con una entrada [tipo = enviar], y no está deshabilitado, cuando alguien presione 'ingresar' mientras completa una de las otras entradas del formulario, el formulario se enviará. Aún puede hacerlo escuchando el evento 'keydown' en los elementos de entrada, pero es una buena parte de la interfaz de usuario que obtiene gratis con las etiquetas de formulario.
3. Hay algunas otras cosas que solo funcionan con una etiqueta de formulario o son más fáciles con una etiqueta de formulario. Los desarrolladores eventualmente se encontrarán con estos casos y decidirán que es más fácil usarlos siempre en todas partes y evitar problemas. Realmente, la verdadera pregunta es, ¿por qué no usar una etiqueta de formulario?

El elemento HTML representa una sección de documento que contiene controles interactivos para enviar información a un servidor web.

Todos estamos familiarizados con los formularios de las páginas web html. Por muchas razones diferentes, las personas o empresas solicitan nuestras direcciones de correo electrónico, nombres y URL de sitios. Comprar productos en Internet hoy en día es, en general, muy sencillo y, con la llegada de los dispositivos de seguridad, el método utilizado para enviar sus datos y el dinero ganado con tanto esfuerzo generalmente se realiza a través de formularios.

más información

enlazar uno

enlace dos

Tuve un escenario en el que una sola página web tenía 3 formularios, todos los cuales tenían campos de correo electrónico separados (con diferentes ID). Los envolví por separado <div>al principio. El autocompletado de iOS en Safari se comportó de manera extraña hasta que los envolví todos en <form>etiquetas. Uno de los formularios tenía un solo campo de entrada, para la suscripción al boletín. Cuando el usuario completó automáticamente esa entrada, la página web se desplazó al siguiente campo de entrada que se encontraba en una parte diferente de la página.

Entonces, gracias Oka por la publicación tan larga. Siempre que sea posible, se deben usar etiquetas con significado semántico, porque nunca se sabe qué navegador / dispositivo no maneja bien otras soluciones.