Qual è lo scopo del tag html form


105

Non capisco lo scopo del tag form in html.

Posso facilmente usare perfettamente qualsiasi tipo di input senza utilizzare il tag form. Sembra quasi ridondante avvolgerlo intorno agli input.

Inoltre, se utilizzo ajax per chiamare una pagina lato server, posso semplicemente usare jQuery per quello. L'unica eccezione è che ho notato che devi avvolgere uno script di caricamento attorno a un tag del modulo per qualche motivo.

Allora perché i moduli sono ancora così ampiamente utilizzati per cose semplici come gli input di testo? Sembra una cosa molto arcaica e inutile da fare.

Semplicemente non ne vedo il beneficio o la necessità. Forse mi manca qualcosa.


Come definisci l'azione e il metodo per il tuo form senza tag html <form>?
Darian

3
Se dovessi farlo in jQuery, utilizzerei la funzione click () sul pulsante e al suo interno utilizzerei la funzione ajax (). Codice molto più semplice e facile da leggere secondo me. E posso facilmente aggiornare la pagina con un semplice javascript
D-Marc

23
Sono sorpreso che questa domanda abbia ricevuto voti negativi. Ho semplicemente cercato su Google questo.
dwjohnston

2
@dwjohnston devi essere nuovo qui ...
Stefano Borini

3
Ottima domanda! Altri motivi per cui non mi piace usare i moduli includono il fatto che limita la struttura della tua pagina (perché non puoi avere moduli all'interno dei moduli), alcune stranezze di serializzazione come il fatto che le caselle di controllo verranno ignorate se non selezionate (il che significa che spesso finisco per preparando manualmente i dati di invio), e perché HTML è fondamentalmente il contenuto e la struttura della pagina, mentre JS è il dinamismo. Gli elementi del modulo si sovrappongono un po 'al lavoro di JS e mi piace che le mie pagine siano strutturate.
3snoW

Risposte:


90

Quello che ti manca è una comprensione del markup semantico e del DOM.

Realisticamente, puoi praticamente fare quello che vuoi con il markup HTML5 e la maggior parte dei browser lo analizzerà. L'ultima volta che ho controllato, WebKit / Blink consente persino pseudo-elementi all'interno di <input>elementi , il che è una chiara violazione delle specifiche: Gecko non così tanto. Tuttavia, fare quello che vuoi con il tuo markup lo invaliderà senza dubbio per quanto riguarda la semantica.

Perché inseriamo <input>elementi all'interno di <form>elementi? Per lo stesso motivo per cui inseriamo i <li>tag all'interno degli elementi <ul>e <ol>: è il luogo a cui appartengono. È semanticamente corretto e aiuta a definire il markup. Parser, screen reader e vari software possono comprendere meglio il markup quando è semanticamente corretto, quando il markup ha un significato, non solo una struttura.

L' <form>elemento consente anche di definire methode actionattributi, che dicono al browser cosa fare quando il modulo viene inviato. AJAX non è uno strumento di copertura al 100% e, come sviluppatore web, dovresti esercitarti in un degrado grazioso: i moduli dovrebbero essere in grado di essere inviati e i dati trasferiti, anche quando JS è disattivato.

Infine, i moduli sono tutti registrati correttamente nel DOM. Possiamo dare un'occhiata a questo con JavaScript. Se apri la tua console proprio in questa pagina e digita:

document.forms

Avrai una bella raccolta di tutti i moduli sulla pagina. La barra di ricerca, le caselle dei commenti, la casella delle risposte: tutte le forme corrette. Questa interfaccia può essere utile per accedere alle informazioni e interagire con questi elementi. Ad esempio, i moduli possono essere serializzati molto facilmente.

Ecco del materiale da leggere:

Nota: gli <input>elementi possono essere utilizzati al di fuori dei moduli, ma se la tua intenzione è di inviare i dati in qualsiasi modo, dovresti utilizzare un modulo.


Questa è la parte della risposta in cui capovolgo la domanda.

In che modo sto rendendo la mia vita più difficile evitando le forme?

Prima di tutto - elementi contenitore. Chi ne ha bisogno, vero ?!

Certamente il tuo piccolo <input>e gli <button>elementi sono annidati all'interno di una sorta di elemento contenitore? Non possono semplicemente fluttuare nel mezzo di tutto il resto. Quindi se non una <form>, allora cosa? A <div>? A <span>?

Questi elementi devono risiedere da qualche parte e, a meno che il tuo markup non sia un pasticcio folle, l'elemento contenitore può essere solo un modulo.

No? Oh.

A questo punto le voci nella mia testa sono molto curiose di come crei i tuoi gestori di eventi per tutte queste diverse situazioni AJAX. Devono essercene molte, se è necessario ridurre il markup per salvare byte. Quindi devi creare funzioni personalizzate per ogni evento AJAX che corrisponde a ogni "set" di elementi - che devi avere come target individualmente o con classi, giusto? Non c'è modo di raggruppare davvero questi elementi in modo generico, poiché abbiamo stabilito che si limitano a vagare per il markup, facendo qualsiasi cosa fino a quando non sono necessari.

Quindi personalizzi il codice di alcuni gestori.

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

Questa è la parte in cui dici qualcosa come:

'Uso totalmente le funzioni riutilizzabili però. Smettila di esagerare.

Abbastanza giusto, ma è comunque necessario creare questi set di elementi unici o set di classi target, giusto? Devi ancora raggruppare questi elementi in qualche modo.

Prestami i tuoi occhi (o le tue orecchie, se stai usando uno screen reader e hai bisogno di assistenza - per fortuna potremmo aggiungere un po 'di ARIA a tutto questo markup semantico , giusto?), E osserva il potere della forma generica.

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>

Possiamo usarlo con qualsiasi forma comune, mantenere la nostra graziosa degradazione e lasciare che la forma descriva completamente come dovrebbe funzionare. Possiamo espandere questa funzionalità di base mantenendo uno stile generico : più modulare, meno mal di testa. JavaScript si preoccupa solo delle sue cose, come nascondere gli elementi appropriati o gestire le risposte che otteniamo.

E ora dici:

"Ma racchiudo le mie pseudo-forme in <div>elementi che hanno ID specifici: posso quindi indirizzare gli input liberamente con con .find, e .serializeloro, e ..."

Oh, cos'è quello? Hai davvero avvolto i tuoi <input>elementi in un contenitore?

Allora perché non è ancora un modulo?


2
Questo è un buon punto nel dare un'occhiata a tutte le forme. Posso capire perché questo sarebbe visto come un vantaggio. Oltre a questo, perché dici che gli input dovrebbero essere usati all'interno di un modulo? Non sembra fornire alcun vantaggio reale. Solo codice extra. Non ho mai letto nulla online che dica che è semanticamente scorretto posizionare gli input al di fuori dei moduli, quindi non penso che sia giusto confrontarli con uls e ols. E realisticamente, non vorrei mai che nessuno usasse i miei siti web se javascript fosse disattivato. Inoltre, probabilmente rappresenterebbe solo l'1% degli utenti online.
D-Marc

2
Sembra meno che tu stia cercando una risposta sul motivo per cui utilizziamo gli <form>elementi e più che tu stia cercando di affermare le tue scelte di markup. Questo va bene, come ho detto, si è liberi di fare ciò che ti piace con il vostro codice, ma mi hanno spiegato le ragioni principali per cui noi sviluppatori utilizzano forme.
Oka

2
Ottimi punti fatti. Apprezzo davvero il fatto che tu abbia dedicato del tempo per elaborare maggiormente la tua risposta e fornire esempi di codice reali. Darò ai moduli un altro tentativo e vedrò se mi piace farlo di più. Grazie ancora per l'aiuto. Tuttavia, non credi che sia inutile avvolgere un modulo attorno a una sola casella di testo?
D-Marc

Dipende dal contesto. Un input che non viene mai inviato direttamente , come una casella di ricerca che esegue il polling di un endpoint API esclusivamente tramite AJAX su eventi diversi da submit, può omettere di essere racchiuso in un modulo poiché non avrebbe alcuna funzionalità senza JavaScript. Non è un markup non valido avere una semantica <input>esterna <form>, forse povera. Se c'è un modo in cui i dati possono essere inviati senza AJAX, con un submitevento appropriato , un modulo è probabilmente il migliore. Anche in questo caso, l'elemento necessita di un contenitore e gli <form>elementi sono a livello di blocco per impostazione predefinita, quindi agiscono proprio come un file <div>.
Oka

6

I tag del modulo sono ancora necessari se vuoi essere in grado di inviare il modulo senza AJAX (che può essere utile nelle prime fasi di sviluppo). Ma anche se è possibile utilizzare javascript per inviare dati senza un tag form, vengono comunque in mente alcuni vantaggi:

  1. L'uso dei tag del modulo può aiutare le persone a leggere e comprendere il tuo codice in alcuni casi, mostrando loro le tue intenzioni.
  2. Il metodo "invia" è disponibile sui moduli. Se hai un modulo con un input [type = submit] e non è disabilitato, quando qualcuno preme "invio" durante la compilazione di uno degli altri input del modulo, il modulo verrà inviato. Puoi ancora farlo ascoltando l'evento 'keydown' sugli elementi di input, ma è un bel po 'di ui che ottieni gratuitamente con i tag del modulo.
  3. Ci sono alcune altre cose che funzionano solo con un tag form o sono più facili con un tag form. Gli sviluppatori alla fine si imbatteranno in questi casi e decideranno che è più facile usarli sempre ovunque ed evitare problemi. In realtà, la vera domanda è, perché non utilizzare un tag form?

Inoltre, cose come jQuery .serialize()funziona solo sugli elementi del modulo.
EJTH

0

L'elemento HTML rappresenta una sezione del documento che contiene controlli interattivi per inviare informazioni a un server web.

Conosciamo tutti i moduli sulle pagine web html. Per molti motivi diversi, persone o aziende richiedono i nostri indirizzi e-mail, nomi e URL del sito. L'acquisto di prodotti su Internet oggi è per lo più un gioco da ragazzi e con l'avvento dei dispositivi di sicurezza, il metodo utilizzato per inviare i tuoi dati e il denaro guadagnato con fatica viene solitamente eseguito tramite moduli.

Ulteriori informazioni

collegamento uno

collegamento due


Sì, ma non è necessario avvolgere input di testo come indirizzi e-mail o password nei moduli per inviare i dati. Posso farlo facilmente con Ajax. I moduli non forniscono alcuna sicurezza aggiuntiva. Tuttavia, posso farlo con php se crittografa i dati.
D-Marc

0

Ho avuto uno scenario in cui una singola pagina Web aveva 3 moduli, tutti con campi di posta elettronica separati (con ID diversi). All'inizio li ho avvolti separatamente <div>. Il riempimento automatico di iOS su Safari si è comportato in modo strano finché non li ho racchiusi tutti in <form>tag. Uno dei moduli aveva un solo campo di input, per l'iscrizione alla newsletter. Quando l'utente ha compilato automaticamente quell'input, la pagina web è stata spostata al campo di input successivo che si trovava in una parte diversa della pagina.

Quindi, grazie Oka per il lungo post. I tag con significato semantico dovrebbero essere usati quando possibile, perché non sai mai quale browser / dispositivo non gestisce bene altre soluzioni.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.