Яке призначення тегу форми html


107

Я не розумію призначення тегу форми в html.

Я легко можу просто ідеально використовувати будь-які типи введення, не використовуючи тег форми. Це майже здається зайвим обертати його навколо входів.

Крім того, якщо я використовую ajax для виклику серверної сторінки, я можу просто використовувати jQuery для цього. Єдиним винятком є ​​те, що я помітив, що вам потрібно з якихось причин обернути сценарій завантаження навколо тегу форми.

То чому форми все ще так широко використовуються для таких простих речей, як введення тексту? Це здається дуже архаїчною та непотрібною справою.

Я просто не бачу користі чи потреби в цьому. Можливо, мені чогось не вистачає.


Як ви визначаєте дію та метод для вашої форми без тегу html <form>?
Даріан

3
Якби я робив це в jQuery, я б використовував функцію click () на кнопці, а всередині цього я б використовував функцію ajax (). На мій погляд, набагато простіший і легший для читання код. І я можу легко оновити сторінку простим javascript
D-Marc

24
Я здивований, що це питання отримало проти. Я просто просто погуглив це.
dwjohnston

2
@dwjohnston, ти повинен бути тут новим ...
Стефано Боріні

3
Чудове питання! Інші причини, через які я не люблю використовувати форми, включають той факт, що це обмежує структуру вашої сторінки (оскільки ви не можете мати форми всередині форм), деякі примхи серіалізації, як той факт, що прапорці будуть ігноруватися, якщо їх не позначити (мається на увазі, що часто я опиняюся вручну підготовка даних для подання), і тому, що HTML - це принципово зміст і структура сторінки, тоді як JS - це динамізм. Елементи форми трохи накладаються на роботу JS, і мені подобається структурувати свої сторінки.
3snoW

Відповіді:


93

Вам не вистачає розуміння семантичної розмітки та DOM.

Реально кажучи, ви можете робити все, що завгодно, з розміткою HTML5, і більшість браузерів проаналізують її. Минулого разу, коли я перевіряв, WebKit / Blink дозволяє навіть псевдоелементи всередині <input>елементів , що є явним порушенням специфікації - Gecko не так сильно. Однак, робити все, що вам подобається, з розміткою, безсумнівно, призведе до втрати її якості щодо семантики.

Чому ми поміщаємо <input>елементи всередину <form>елементів? З тієї ж причини ми поміщаємо <li>теги всередину <ul>та <ol>елементів - це місце, де вони належать. Це семантично правильно і допомагає визначити розмітку. Синтаксичні аналізатори, зчитувачі екрана та різне програмне забезпечення можуть краще зрозуміти вашу розмітку, коли вона семантично правильна - коли розмітка має значення, а не лише структуру.

<form>Елемент також дозволяє визначити methodі actionатрибути, які повідомляють браузеру , що робити , коли форма була відправлена. AJAX не є інструментом 100% охоплення, і як веб-розробник ви повинні практикувати витончену деградацію - форми повинні мати можливість надсилати та передавати дані, навіть коли JS вимкнено.

Нарешті, усі форми належним чином зареєстровані в DOM. Ми можемо підглянути це за допомогою JavaScript. Якщо ви відкриєте свою консоль саме на цій сторінці, і введіть:

document.forms

Ви отримаєте гарну колекцію всіх форм на сторінці. Рядок пошуку, поля коментарів, поле відповідей - усі належні форми. Цей інтерфейс може бути корисним для доступу до інформації та взаємодії з цими елементами. Наприклад, форми можна дуже легко серіалізувати .

Ось декілька матеріалів для читання:

Примітка: <input>елементи можна використовувати поза формами, але якщо ви хочете подати дані будь-яким способом, ви повинні використовувати форму.


Це частина відповіді, де я перегортаю питання.

Як я ускладнюю своє життя, уникаючи форм?

Перше і головне - елементи контейнера. Кому вони потрібні, так ?!

Звичайно, ваш маленький елемент <input>і <button>елементи вкладені в якийсь елемент контейнера? Вони не можуть просто плавати посеред усього іншого. Тож якщо ні <form>, то що? A <div>? A <span>?

Ці елементи повинні десь знаходитись, і якщо ваша розмітка не божевільна, то елемент-контейнер може бути просто формою.

Немає? О

На даний момент голоси в моїй голові дуже цікаві, як ви створюєте свої обробники подій для всіх цих різних ситуацій AJAX. Їх має бути багато, якщо вам потрібно скоротити розмітку, щоб зберегти байти. Тоді ви повинні створити власні функції для кожної події AJAX, яка відповідає кожному "набору" елементів - на які ви повинні націлюватись окремо або за допомогою класів, правда? Існує жодна можливість узагальнити ці елементи загально, оскільки ми встановили, що вони просто блукають навколо розмітки, роблячи все, що завгодно, поки вони не потрібні.

Отже, ви призначите кілька кодів для обробки.

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

Це частина, де ви говорите щось на зразок:

'Однак я повністю використовую багаторазові функції. Перестань перебільшувати '.

Досить справедливо, але вам все одно потрібно створити ці набори унікальних елементів або цільові набори класів, так? Вам все одно доведеться якось згрупувати ці елементи.

Позичте мені свої очі (або вуха, якщо ви використовуєте зчитувач з екрана і вам потрібна допомога - добре, що ми могли б додати трохи ARIA до всієї цієї семантичної розмітки, так?), І ось сила загальної форми.

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>

Ми можемо використовувати це з будь-якою поширеною формою, підтримувати нашу витончену деградацію і нехай форма повністю описує, як вона повинна функціонувати. Ми можемо розширити цю базову функціональність, зберігаючи загальний стиль - більше модульний, менше головного болю. JavaScript просто турбується про власні речі, такі як приховування відповідних елементів або обробка отриманих відповідей.

А тепер ти кажеш:

"Але я обертаю свої псевдо-форми в <div>елементи, що мають конкретні ідентифікатори - тоді я можу вільно націлювати вхідні дані за допомогою .find, і .serializeїх, і ..."

О, що це? Ви насправді загортаєте свої <input>елементи в контейнер?

То чому це ще не форма?


3
Це хороший момент, якщо заглянути в усі форми. Я розумію, чому це було б розцінено як перевагу. Крім того, чому ви говорите, що вхідні дані повинні використовуватися всередині форми? Здається, це не дає жодної реальної переваги. Тільки додатковий код. Я ніколи не читав нічого в Інтернеті, де говориться, що семантично некоректно розміщувати вводи за межами форм, тому я не вважаю, що чесно порівнювати це з uls та ols. І реально, я ніколи не хотів би, щоб хтось користувався моїми веб-сайтами, якщо у них вимкнено JavaScript. Плюс на це, мабуть, припадає лише 1% користувачів в Інтернеті.
D-Marc

2
Звучить менше, ніби ви шукаєте відповіді, чому ми використовуємо <form>елементи, а більше, як ви намагаєтесь підтвердити власні можливості розмітки. Це нормально, як я сказав, ви вільні робити незалежно вам , як з розміткою, але я вже пояснив основні причини , за якими ми розробники використовують форму.
Ока,

2
Великі очки. Я щиро вдячний за той факт, що ви знайшли час, щоб детальніше обговорити свою відповідь та навести реальні приклади коду. Я ще раз дам форми, щоб перевірити, чи більше мені подобається робити це так. Ще раз спасибі за допомогу. Однак, чи не здається вам, що безглуздо обгортати форму лише одним текстовим полем?
D-Marc

Залежить від контексту. Вхідні дані, які ніколи не надсилаються безпосередньо , як вікно пошуку, яке опитує кінцеву точку API виключно через AJAX щодо інших подій submit, може пропустити загортання у форму, оскільки вона не мала б жодної функціональності без JavaScript. Не є неприпустимою розміткою наявність <input>зовнішньої сторони <form>, можливо лише поганої семантики. Якщо існує спосіб, що дані можуть бути подані без AJAX, з відповідною submitподією, форма, мабуть, найкраща. Знову ж таки, елементу потрібен контейнер, а <form>елементи за замовчуванням мають рівень блоку, тому вони діють так само, як a <div>.
Ока,

7

Теги форми все ще необхідні, якщо ви хочете мати можливість подати форму без AJAX (що може бути корисним на ранніх стадіях розробки). Але навіть незважаючи на те, що можна використовувати javascript для надсилання даних без тегу форми, все одно приходить на думку кілька переваг:

  1. Використання тегів форми може допомогти людям прочитати та зрозуміти ваш код у деяких випадках, показавши їм свої наміри.
  2. Метод "подати" доступний у формах. Якщо у вас є форма із введенням [type = submit], і вона не відключена, тоді, коли хтось натискає клавішу "enter" під час заповнення одного з інших входів форми, форма буде надіслана. Ви все ще можете це зробити, прослуховуючи подію 'keydown' на елементах введення, але це чудовий інтерфейс, який ви отримуєте безкоштовно за допомогою тегів форми.
  3. Є ще кілька речей, які працюють лише з тегом форми або простіше з тегом форми. З часом розробники зіткнуться з цими справами і вирішать, що простіше просто використовувати їх скрізь і уникати проблем. Справді, справжнє питання полягає в тому, чому б не використовувати тег форми?

Крім того, такі речі, як jQuery, працюють .serialize()лише з елементами форми.
EJTH,

0

Елемент HTML представляє розділ документа, який містить інтерактивні елементи керування для подання інформації на веб-сервер.

Ми всі добре знайомі з формами на веб-сторінках html. З багатьох різних причин люди або компанії запитують наші електронні адреси, імена та URL-адреси веб-сайтів. Сьогодні покупка продуктів в Інтернеті здебільшого дуже легка, і з появою захисних пристроїв метод подання ваших даних та зароблених грошей зазвичай виконується через форми.

більше інформації

посилання один

посилання два


Так, але вам не потрібно обертати текстові введення, такі як адреси електронної пошти або паролі, у формах, щоб подавати дані. Я легко можу це зробити за допомогою ajax. Форми не забезпечують жодної додаткової безпеки. Однак я можу зробити це за допомогою php, якщо зашифрую дані.
D-Marc

0

У мене був сценарій, коли одна веб-сторінка мала 3 форми, кожна з яких мала окремі поля електронної пошти (з різними ідентифікаторами). <div>Спочатку я загорнув їх окремо . Автозаповнення iOS у Safari поводилося дивно, поки я не обернув їх усі <form>тегами. Одна з форм мала лише одне поле введення для підписки на розсилку. Коли користувач автоматично заповнював це введення, веб-сторінку прокручували до наступного поля введення, яке було розташоване в іншій частині сторінки.

Отже, дякую Oka за довгий допис. Теги із семантичним значенням слід використовувати по можливості, оскільки ви ніколи не знаєте, який браузер / пристрій погано справляється з іншими рішеннями.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.