javascript - son - ¿Cuál es el propósito de la etiqueta de formulario html?
label for para que sirve (3)
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 me di cuenta de que, por algún motivo, debe ajustar un script de carga alrededor de una etiqueta de formulario.
Entonces, ¿por qué los formularios siguen siendo tan ampliamente utilizados para cosas simples como entradas de texto? Parece una cosa muy arcaica e innecesaria de hacer.
Simplemente no veo el beneficio o la necesidad de ello. Tal vez me estoy perdiendo algo.
El elemento HTML representa una sección del documento que contiene controles interactivos para enviar información a un servidor web.
Todos estamos familiarizados con los formularios en las páginas web html. Por muchas razones diferentes, las personas o las empresas solicitan nuestras direcciones de correo electrónico, nombres y URL del sitio. Comprar productos en Internet hoy en día es muy fácil y con el advenimiento 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
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 se me ocurren algunos beneficios:
- 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.
- El método ''enviar'' está disponible en los formularios. Si tiene un formulario con una entrada [type = submit] y no está deshabilitado, cuando alguien presiona ''enter'' mientras completa una de las otras entradas del formulario, el formulario se enviará. Todavía puede hacerlo escuchando el evento ''keydown'' en los elementos de entrada, pero es una buena interfaz de usuario que se obtiene de forma gratuita con las etiquetas de formulario.
- 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?
Lo que falta es una comprensión del marcado semántico y el DOM.
Siendo realistas, puedes hacer lo que quieras con el marcado HTML5, y la mayoría de los navegadores lo analizarán.
La última vez que lo verifiqué, WebKit / Blink incluso permite
seudoelementos dentro de los elementos
<input>
, lo que es una clara violación de la especificación: Gecko no tanto.
Sin embargo, hacer lo que quiera con su marcado, sin duda, lo invalidará en lo que respecta a la semántica.
¿Por qué ponemos elementos
<input>
dentro de los elementos
<form>
?
Por la misma razón, colocamos etiquetas
<li>
dentro de los elementos
<ul>
y
<ol>
: es donde pertenecen.
Es
semánticamente
correcto y ayuda a definir el marcado.
Los analizadores, los lectores de pantalla y varios software pueden comprender mejor su marcado cuando es semánticamente correcto, cuando el marcado tiene significado, no solo estructura.
El elemento
<form>
también le permite definir
method
y atributos de
action
, que le indican al navegador qué hacer cuando se envía el formulario.
AJAX no es una herramienta de cobertura al 100% y, como desarrollador web, debería practicar una degradación elegante: los formularios deberían poder enviarse y los datos transferirse, incluso cuando JS está desactivado.
Finalmente, todos los formularios están registrados 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 la información e interactuar con estos elementos. Por ejemplo, los formularios se pueden serialized muy fácilmente.
Aquí hay material de lectura:
Nota:
<input>
elementos
<input>
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 donde le doy la vuelta a la pregunta.
¿Cómo estoy haciendo mi vida más difícil al evitar las formas?
En primer lugar, elementos contenedores. ¿Quién los necesita, verdad?
¿Ciertamente sus pequeños elementos
<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 solo un formulario.
¿No? Oh.
En este punto, las voces en mi cabeza son muy curiosas sobre cómo crear sus controladores de eventos para todas estas diferentes situaciones de AJAX. Debe haber mucho, si necesita reducir su marcado para guardar bytes. Luego debe crear funciones personalizadas para cada evento AJAX que corresponda a cada ''conjunto'' de elementos, a los que debe dirigirse individualmente o con clases, ¿verdad? No hay forma de agrupar realmente estos elementos genéricamente, ya que hemos establecido que simplemente deambulan por el marcado, haciendo lo que sea hasta que sean necesarios.
Entonces usted codifica algunos manejadores personalizados.
$(''#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 donde dices algo como:
Sin embargo, uso totalmente las funciones reutilizables. Deja de exagerar.
Es justo, pero aún necesita crear estos conjuntos de elementos únicos, o conjuntos de clases de destino, ¿verdad? Todavía tiene 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; bueno, podríamos agregar algo de ARIA a todo este marcado semántico , ¿verdad?), 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 degradación elegante 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-formas en elementos
<div>
que tienen ID específicos; luego puedo apuntar las entradas libremente con
.find
y
.serialize
, y ...''
¿Oh, qué es eso?
¿Realmente envuelve sus elementos
<input>
en un contenedor?
Entonces, ¿por qué aún no es una forma?