¿Cuál es el propósito de la etiqueta de formulario html?


105

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.


¿Cómo se define la acción y el método para su formulario sin la etiqueta html <form>?
Darian

3
Si tuviera que hacerlo en jQuery, usaría la función click () en el botón y dentro de eso usaría la función ajax (). En mi opinión, el código es mucho más simple y fácil de leer. Y puedo actualizar fácilmente la página con un simple javascript
D-Marc

23
Me sorprende que esta pregunta haya recibido votos negativos. Simplemente busqué en Google esto.
dwjohnston

2
@dwjohnston debes ser nuevo aquí ...
Stefano Borini

3
¡Gran pregunta! Otras razones por las que no me gusta usar formularios incluyen el hecho de que limita la estructura de su página (porque no puede tener formularios dentro de los formularios), algunas peculiaridades de la serialización como el hecho de que las casillas de verificación se ignorarán si no se marcan (lo que significa que a menudo termino preparando manualmente los datos de envío), y porque HTML es fundamentalmente el contenido y la estructura de la página, mientras que JS es el dinamismo. Los elementos del formulario se superponen un poco en el trabajo de JS, y me gusta tener mis páginas estructuradas.
3 de

Respuestas:


90

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:

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?


2
Ese es un buen punto al echar un vistazo a todas las formas. Puedo ver por qué eso se consideraría una ventaja. Además de eso, ¿por qué dices que las entradas deben usarse dentro de un formulario? No parece proporcionar ninguna ventaja real. Solo código extra. Nunca he leído nada en línea que diga que es semánticamente incorrecto colocar entradas fuera de los formularios, por lo que no creo que sea justo compararlo con uls y ols. Y, de manera realista, nunca me gustaría que nadie usara mis sitios web si tienen javascript desactivado. Además, eso probablemente solo representaría quizás el 1% de los usuarios en línea.
D-Marc

2
Suena menos como si estuviera buscando una respuesta sobre por qué usamos <form>elementos, y más como si estuviera tratando de afirmar sus propias opciones de marcado. Esto está bien, como dije, eres libre de hacer lo que quieras con tu marcado, pero yo ha explicado las principales razones por las que los desarrolladores utilizan formas.
Oka

2
Grandes puntos hechos. Realmente aprecio el hecho de que se haya tomado el tiempo de elaborar más su respuesta y proporcionar ejemplos de código real. Daré otra oportunidad a los formularios y veré si me gusta más hacerlo así. Gracias de nuevo por la ayuda. Sin embargo, ¿no cree que no tiene sentido envolver un formulario en un solo cuadro de texto?
D-Marc

Depende del contexto. Una entrada que nunca se envía directamente , como un cuadro de búsqueda que sondea un punto final de API exclusivamente a través de AJAX en eventos distintos de submit, puede omitir estar envuelto en un formulario, ya que no tendría ninguna funcionalidad sin JavaScript. No es un marcado no válido tener un <input>exterior de a <form>, solo posiblemente una semántica deficiente. Si existe una forma de enviar los datos sin AJAX, con un submitevento adecuado , probablemente lo mejor sea un formulario. Nuevamente, el elemento necesita un contenedor, y los <form>elementos están a nivel de bloque de forma predeterminada, por lo que actúan como un <div>.
Oka

6

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?

Además, cosas como jQuery .serialize()solo funcionan en elementos de formulario.
EJTH

0

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


Sí, pero no es necesario incluir entradas de texto como direcciones de correo electrónico o contraseñas en formularios para enviar datos. Puedo hacer eso fácilmente con ajax. Los formularios no ofrecen seguridad adicional. Sin embargo, puedo hacer eso con php si cifro los datos.
D-Marc

0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.