Nie rozumiem, do czego służy tag formularza w html.

Z łatwością mogę po prostu doskonale używać dowolnych typów danych wejściowych bez używania tagu formularza. Owijanie go wokół danych wejściowych wydaje się prawie zbędne.

Dodatkowo, jeśli używam ajax do wywoływania strony po stronie serwera, mogę po prostu użyć do tego jQuery. Jedynym wyjątkiem jest to, że zauważyłem, że z jakiegoś powodu musisz owinąć skrypt przesyłania wokół tagu formularza.

Dlaczego więc formularze są nadal tak powszechnie używane do prostych rzeczy, takich jak wprowadzanie tekstu? Wydaje się, że jest to bardzo archaiczna i niepotrzebna rzecz.

Po prostu nie widzę korzyści ani potrzeby. Może czegoś mi brakuje.

To, czego brakuje, to zrozumienie znaczników semantycznych i DOM.

Realistycznie możesz robić, co chcesz, ze znacznikami HTML5, a większość przeglądarek to przeanalizuje. Kiedy ostatnio sprawdzałem, WebKit / Blink dopuszcza nawet pseudoelementy wewnątrz <input>elementów , co jest wyraźnym naruszeniem specyfikacji - Gecko nie tak bardzo. Jednak robienie tego, co chcesz ze swoimi znacznikami, niewątpliwie unieważni je, jeśli chodzi o semantykę.

Dlaczego umieszczamy <input>elementy wewnątrz <form>elementów? Z tego samego powodu umieszczamy <li>tagi wewnątrz elementów <ul>i <ol>- to ich miejsce. Jest semantycznie poprawny i pomaga zdefiniować znaczniki. Parsery, czytniki ekranu i różne oprogramowanie mogą lepiej zrozumieć twoje znaczniki, gdy są one semantycznie poprawne - gdy znaczniki mają znaczenie, a nie tylko strukturę.

<form>Elementem pozwala również na definiowanie methodi actionatrybuty, które poinformować przeglądarkę, co robić, gdy formularz jest składany. AJAX nie jest narzędziem zapewniającym 100% pokrycie, a jako programista stron internetowych powinieneś ćwiczyć wdzięczną degradację - formularze powinny być przesyłane, a dane przesyłane, nawet gdy JS jest wyłączony.

Wreszcie wszystkie formularze są poprawnie rejestrowane w DOM. Możemy rzucić okiem na to za pomocą JavaScript. Jeśli otworzysz konsolę na tej samej stronie i wpisz:

document.forms

Otrzymasz niezłą kolekcję wszystkich formularzy na stronie. Pasek wyszukiwania, pola komentarzy, pole odpowiedzi - wszystkie odpowiednie formularze. Ten interfejs może być przydatny do uzyskiwania dostępu do informacji i interakcji z tymi elementami. Na przykład formularze można bardzo łatwo serializować .

Oto kilka materiałów do czytania:

• Semantyczny HTML
• Przewodnik po formularzach HTML

Uwaga: <input>elementów można używać poza formularzami, ale jeśli zamierzasz podać dane w jakikolwiek sposób, skorzystaj z formularza.

To jest ta część odpowiedzi, w której odwracam pytanie.

Jak utrudniam sobie życie, unikając form?

Przede wszystkim - elementy kontenerowe. Kto ich potrzebuje, prawda ?!

Z pewnością twoje małe <input>i <button>elementy są zagnieżdżone w jakimś elemencie pojemnika? Nie mogą po prostu unosić się w środku wszystkiego innego. Więc jeśli nie <form>, to co? A <div>? A <span>?

Te elementy muszą gdzieś znajdować się i jeśli twój znacznik nie jest szalonym bałaganem, element kontenera może być po prostu formularzem.

Nie? O.

W tym momencie głosy w mojej głowie są bardzo zaciekawione, jak tworzysz programy obsługi zdarzeń dla wszystkich tych różnych sytuacji AJAX. Musi być ich dużo, jeśli chcesz zmniejszyć liczbę znaczników, aby zaoszczędzić bajty. Następnie musisz utworzyć niestandardowe funkcje dla każdego zdarzenia AJAX, które odpowiada każdemu „zestawowi” elementów - które musisz kierować indywidualnie lub za pomocą klas, prawda? Nie ma sposobu, aby naprawdę zgrupować te elementy w sposób ogólny, ponieważ ustaliliśmy, że po prostu wędrują po znacznikach, robiąc wszystko, aż będą potrzebne.

Więc niestandardowo kodujesz kilka programów obsługi.

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

To jest ta część, w której mówisz coś takiego:

„Jednak całkowicie korzystam z funkcji wielokrotnego użytku. Przestań przesadzać.

W porządku, ale nadal musisz tworzyć te zestawy unikalnych elementów lub docelowe zestawy klas, prawda? Nadal musisz jakoś pogrupować te elementy.

Pożycz mi swoje oczy (lub uszy, jeśli używasz czytnika ekranu i potrzebujesz pomocy - dobrze, że moglibyśmy dodać trochę ARIA do całego tego semantycznego znacznika, prawda?) I zobacz siłę ogólnej formy.

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>

Możemy tego użyć z każdą popularną formą, utrzymać naszą pełną wdzięku degradację i pozwolić, aby forma całkowicie opisała, jak powinna funkcjonować. Możemy rozszerzyć tę podstawową funkcjonalność, zachowując ogólny styl - bardziej modułowy, mniej bólów głowy. JavaScript martwi się tylko o swoje własne rzeczy, takie jak ukrywanie odpowiednich elementów lub obsługa otrzymywanych odpowiedzi.

A teraz mówisz:

`` Ale zawijam moje pseudo-formularze w <div>elementy, które mają określone identyfikatory - mogę następnie swobodnie kierować dane wejściowe za pomocą .find, i .serializeone, i ... ''

A co to jest? Faktycznie pakujesz swoje <input>elementy w pojemnik?

Dlaczego więc nie jest to jeszcze forma?

Tagi formularzy są nadal potrzebne, jeśli chcesz mieć możliwość przesłania formularza bez AJAX (co może być przydatne na wczesnych etapach rozwoju). Ale nawet jeśli można użyć javascript do przesyłania danych bez tagu formularza, wciąż przychodzi na myśl kilka korzyści:

1. Używanie tagów formularzy może w niektórych przypadkach pomóc ludziom przeczytać i zrozumieć Twój kod, pokazując im swoje zamiary.
2. Metoda „wyślij” jest dostępna na formularzach. Jeśli masz formularz z danymi wejściowymi [type = Submit] i nie jest on wyłączony, to gdy ktoś naciśnie „enter” podczas wypełniania jednego z pozostałych danych wejściowych formularza, formularz zostanie przesłany. Nadal możesz to zrobić, nasłuchując zdarzenia „keydown” w elementach wejściowych, ale jest to niezły kawałek interfejsu użytkownika, który dostajesz za darmo za pomocą tagów formularzy.
3. Jest kilka innych rzeczy, które działają tylko ze znacznikiem formularza lub są łatwiejsze w przypadku znacznika formularza. Programiści w końcu napotkają takie przypadki i zdecydują, że łatwiej jest po prostu zawsze z nich korzystać wszędzie i unikać problemów. Naprawdę, prawdziwe pytanie brzmi: dlaczego nie użyć tagu formularza?

Element HTML reprezentuje sekcję dokumentu, która zawiera interaktywne elementy sterujące do przesyłania informacji do serwera WWW.

Wszyscy znamy formularze na stronach internetowych html. Z wielu różnych powodów ludzie lub firmy proszą o nasze adresy e-mail, nazwy i adresy URL witryn. Kupowanie produktów w Internecie jest dziś w większości proste, a wraz z pojawieniem się urządzeń zabezpieczających, metoda przesyłania danych i ciężko zarobionych pieniędzy odbywa się zwykle za pośrednictwem formularzy.

więcej informacji

link jeden

łącze dwa

Miałem scenariusz, w którym jedna strona internetowa miała 3 formularze, z których wszystkie miały oddzielne pola e-mail (z różnymi identyfikatorami). <div>Najpierw zawinąłem je osobno . Automatyczne wypełnianie iOS w Safari zachowywało się dziwnie, dopóki nie zawinąłem ich wszystkich w <form>tagi. Jeden z formularzy miał tylko jedno pole wejściowe do subskrypcji newslettera. Gdy użytkownik automatycznie wypełnił te dane, strona internetowa została przewinięta do następnego pola wprowadzania, które znajdowało się w innej części strony.

Tak więc, dzięki Oka za długi post. Znaczników o znaczeniu semantycznym należy używać zawsze, gdy to możliwe, ponieważ nigdy nie wiadomo, która przeglądarka / urządzenie nie radzi sobie dobrze z innymi rozwiązaniami.