Mục đích của thẻ biểu mẫu html là gì


104

Tôi không hiểu mục đích của thẻ biểu mẫu trong html.

Tôi có thể dễ dàng sử dụng hoàn hảo bất kỳ loại đầu vào nào mà không cần sử dụng thẻ biểu mẫu. Gần như có vẻ thừa khi quấn nó quanh các đầu vào.

Ngoài ra, nếu tôi đang sử dụng ajax để gọi một trang phía máy chủ, tôi có thể chỉ cần sử dụng jQuery cho việc đó. Ngoại lệ duy nhất là tôi nhận thấy rằng bạn phải bọc một tập lệnh tải lên xung quanh thẻ biểu mẫu vì một số lý do.

Vậy tại sao biểu mẫu vẫn được sử dụng rộng rãi cho những thứ đơn giản như nhập văn bản? Nó có vẻ như là một việc rất cổ hủ và không cần thiết phải làm.

Tôi chỉ không thấy lợi ích hoặc nhu cầu của nó. Có lẽ tôi đang thiếu một cái gì đó.


Làm cách nào để bạn xác định hành động và phương thức cho biểu mẫu của mình mà không có thẻ html <form>?
Darian

3
Nếu tôi làm điều đó trong jQuery, tôi sẽ sử dụng hàm click () trên nút và bên trong đó, tôi sẽ sử dụng hàm ajax (). Theo tôi, mã đơn giản và dễ đọc hơn nhiều. Và tôi có thể dễ dàng làm mới trang bằng javascript đơn giản
D-Marc

23
Tôi ngạc nhiên rằng câu hỏi này đã nhận được sự phản đối. Tôi hoàn toàn chỉ tìm kiếm điều này.
dwjohnston

2
@dwjohnston bạn phải mới đây ...
Stefano Borini

3
Câu hỏi tuyệt vời! Các lý do khác khiến tôi không thích sử dụng biểu mẫu bao gồm thực tế là nó giới hạn cấu trúc trang của bạn (vì bạn không thể có biểu mẫu bên trong biểu mẫu), một số câu hỏi tuần tự hóa như thực tế là hộp kiểm sẽ bị bỏ qua nếu không được chọn (nghĩa là tôi thường kết thúc chuẩn bị thủ công dữ liệu gửi) và vì HTML về cơ bản là nội dung và cấu trúc của trang, trong khi JS là tính năng động. Các phần tử biểu mẫu bị chồng chéo một chút trong công việc của JS và tôi muốn có cấu trúc các trang của mình.
3snoW

Câu trả lời:


89

Những gì bạn đang thiếu là sự hiểu biết về đánh dấu ngữ nghĩa và DOM.

Thực tế, bạn có thể làm bất cứ điều gì bạn muốn với đánh dấu HTML5 và hầu hết các trình duyệt sẽ phân tích cú pháp đó. Lần trước tôi đã kiểm tra, WebKit / Blink thậm chí còn cho phép các phần tử giả bên trong <input>các phần tử , điều này rõ ràng là vi phạm thông số kỹ thuật - Gecko không quá nhiều. Tuy nhiên, làm bất cứ điều gì bạn thích với đánh dấu của mình chắc chắn sẽ làm mất hiệu lực của nó về mặt ngữ nghĩa.

Tại sao chúng ta đặt <input>các phần tử bên trong các <form>phần tử? Vì lý do tương tự, chúng tôi đặt <li>các thẻ bên trong các phần tử <ul><ol>- đó là nơi chúng thuộc về. Nó chính xác về mặt ngữ nghĩa và giúp xác định đánh dấu. Trình phân tích cú pháp, trình đọc màn hình và các phần mềm khác nhau có thể hiểu rõ hơn đánh dấu của bạn khi nó chính xác về mặt ngữ nghĩa - khi đánh dấu có ý nghĩa, không chỉ cấu trúc.

Phần <form>tử này cũng cho phép bạn xác định methodactioncác thuộc tính, cho phép trình duyệt biết phải làm gì khi biểu mẫu được gửi. AJAX không phải là một công cụ có phạm vi bảo hiểm 100% và với tư cách là một nhà phát triển web, bạn nên thực hiện quá trình giảm cấp duyên dáng - các biểu mẫu có thể được gửi và dữ liệu được truyền, ngay cả khi JS bị tắt.

Cuối cùng, tất cả các biểu mẫu đều được đăng ký đúng cách trong DOM. Chúng ta có thể xem xét điều này bằng JavaScript. Nếu bạn mở bảng điều khiển của mình trên chính trang này và nhập:

document.forms

Bạn sẽ nhận được một bộ sưu tập đẹp của tất cả các biểu mẫu trên trang. Thanh tìm kiếm, hộp nhận xét, hộp trả lời - tất cả các dạng thích hợp. Giao diện này có thể hữu ích để truy cập thông tin và tương tác với các phần tử này. Ví dụ, các biểu mẫu có thể được đăng nhiều kỳ rất dễ dàng.

Đây là một số tài liệu đọc:

Ghi chú: <input> các phần tử có thể được sử dụng bên ngoài biểu mẫu, nhưng nếu ý định của bạn là gửi dữ liệu theo bất kỳ cách nào, bạn nên sử dụng biểu mẫu.


Đây là một phần của câu trả lời mà tôi lật lại câu hỏi.

Tôi đang làm cho cuộc sống của mình khó khăn hơn bằng cách tránh những hình thức như thế nào?

Đầu tiên và quan trọng nhất - các phần tử vùng chứa. Ai cần chúng, phải không ?!

Chắc chắn các phần tử <input>và nhỏ của bạn <button>được lồng vào bên trong một số loại phần tử chứa? Họ không thể cứ lơ lửng giữa mọi thứ khác. Vậy nếu không phải là a <form>, thì sao? A <div>? A<span> ?

Các phần tử này phải nằm ở đâu đó và trừ khi phần đánh dấu của bạn là một mớ hỗn độn điên rồ, phần tử vùng chứa có thể chỉ là một biểu mẫu.

Không? Oh.

Tại thời điểm này, tiếng nói trong đầu tôi rất tò mò về cách bạn tạo trình xử lý sự kiện của mình cho tất cả các tình huống AJAX khác nhau này. Phải có rất nhiều, nếu bạn cần phải cắt giảm đánh dấu của mình để tiết kiệm byte. Sau đó, bạn phải tạo các hàm tùy chỉnh cho mỗi sự kiện AJAX tương ứng với mỗi 'tập hợp' các phần tử - mà bạn phải nhắm mục tiêu riêng lẻ hoặc với các lớp, phải không? Không có cách nào để thực sự nhóm các yếu tố này một cách chung chung, vì chúng tôi đã xác định rằng chúng chỉ đi lang thang xung quanh đánh dấu, làm bất cứ điều gì cho đến khi chúng cần thiết.

Vì vậy, bạn mã tùy chỉnh một vài trình xử lý.

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

Đây là phần mà bạn nói những điều như:

'Tôi hoàn toàn sử dụng các chức năng có thể tái sử dụng. Đừng quá phóng đại.'

Đủ công bằng, nhưng bạn vẫn cần tạo những tập hợp các phần tử duy nhất này, hoặc tập hợp lớp mục tiêu, phải không? Bạn vẫn phải nhóm các yếu tố này bằng cách nào đó.

Hãy cho tôi mượn đôi mắt của bạn (hoặc đôi tai, nếu bạn đang sử dụng trình đọc màn hình và cần một số hỗ trợ - điều tốt là chúng ta có thể thêm một số ARIA vào tất cả đánh dấu ngữ nghĩa này , phải không?), Và hãy xem sức mạnh của biểu mẫu chung.

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>

Chúng tôi có thể sử dụng điều này với bất kỳ biểu mẫu thông thường nào, duy trì sự xuống cấp duyên dáng của chúng tôi và để biểu mẫu mô tả hoàn toàn cách nó hoạt động. Chúng tôi có thể mở rộng chức năng cơ bản này trong khi vẫn giữ một phong cách chung - mô-đun hơn, ít đau đầu hơn. JavaScript chỉ lo lắng về những thứ của riêng nó, như ẩn các phần tử thích hợp hoặc xử lý bất kỳ phản hồi nào mà chúng tôi nhận được.

Và bây giờ bạn nói:

'Nhưng tôi bọc các biểu mẫu giả của mình trong <div>các phần tử có ID cụ thể - sau đó tôi có thể nhắm mục tiêu các đầu vào một cách lỏng lẻo với .find, và .serializechúng, và ...'

Ô .. cái đó là gì thế? Bạn thực sự bọc các <input>phần tử của mình trong một thùng chứa?

Vậy tại sao nó vẫn chưa phải là hình thức?


2
Đó là một điểm tốt khi xem qua tất cả các hình thức. Tôi có thể hiểu tại sao đó sẽ được coi là một lợi thế. Bên cạnh đó, tại sao bạn lại nói rằng đầu vào nên được sử dụng bên trong một biểu mẫu? Nó dường như không cung cấp bất kỳ lợi thế thực sự nào. Chỉ có mã phụ. Tôi chưa bao giờ đọc bất kỳ điều gì trực tuyến nói rằng việc đặt đầu vào bên ngoài biểu mẫu là không chính xác về mặt ngữ nghĩa, vì vậy tôi không nghĩ rằng việc so sánh nó với uls và ols là không chính xác. Và thực tế, tôi sẽ không bao giờ muốn bất kỳ ai sử dụng trang web của mình nếu họ đã tắt javascript. Thêm vào đó, có thể chỉ chiếm 1% người dùng trực tuyến.
D-Marc

2
Nghe có vẻ giống như bạn đang tìm kiếm câu trả lời về lý do tại sao chúng tôi sử dụng <form>các yếu tố, và giống như bạn đang cố gắng khẳng định lựa chọn đánh dấu của riêng mình. Điều này là tốt, như tôi đã nói, bạn có thể tự do làm bất cứ điều gì bạn thích với đánh dấu của mình, nhưng tôi đã giải thích lý do chính tại sao các nhà phát triển chúng tôi sử dụng biểu mẫu.
Oka

2
Điểm tuyệt vời được thực hiện. Tôi thực sự đánh giá cao việc bạn đã dành thời gian để xây dựng câu trả lời của mình nhiều hơn và cung cấp các ví dụ mã thực tế. Tôi sẽ thử các biểu mẫu khác và xem liệu tôi có thích làm như vậy hơn không. Cảm ơn một lần nữa vì sự giúp đỡ. Tuy nhiên, bạn có nghĩ rằng việc quấn một biểu mẫu chỉ quanh một hộp văn bản là vô nghĩa không?
D-Marc

Phụ thuộc vào bối cảnh. Một đầu vào không bao giờ gửi trực tiếp , chẳng hạn như hộp tìm kiếm thăm dò một điểm cuối API độc quyền qua AJAX trên các sự kiện khác submit, có thể bỏ qua việc được bao bọc trong một biểu mẫu vì nó sẽ không có bất kỳ chức năng nào nếu không có JavaScript. Đánh dấu không hợp lệ khi có <input>bên ngoài một <form>, chỉ có thể là ngữ nghĩa kém. Nếu có cách nào đó mà dữ liệu có thể được gửi mà không cần AJAX, với một submitsự kiện thích hợp , thì một biểu mẫu có lẽ là tốt nhất. Một lần nữa, phần tử cần một vùng chứa và <form>các phần tử là cấp khối theo mặc định, vì vậy chúng hoạt động giống như một <div>.
Oka

5

Thẻ biểu mẫu vẫn cần thiết nếu bạn muốn có thể gửi biểu mẫu mà không cần AJAX (có thể hữu ích trong giai đoạn đầu phát triển). Nhưng mặc dù có thể sử dụng javascript để gửi dữ liệu mà không cần thẻ biểu mẫu, một số lợi ích vẫn xuất hiện trong tâm trí:

  1. Sử dụng thẻ biểu mẫu có thể giúp mọi người đọc và hiểu mã của bạn trong một số trường hợp, bằng cách cho họ thấy ý định của bạn.
  2. Phương thức 'gửi' có sẵn trên các biểu mẫu. Nếu bạn có biểu mẫu có đầu vào [type = submit] và nó không bị vô hiệu hóa, thì khi ai đó nhấn 'enter' trong khi điền vào một trong các đầu vào biểu mẫu khác, biểu mẫu sẽ được gửi. Bạn vẫn có thể làm điều đó bằng cách lắng nghe sự kiện 'keydown' trên các phần tử đầu vào, nhưng thật tuyệt vời khi bạn nhận được miễn phí với các thẻ biểu mẫu.
  3. Có một số thứ khác chỉ hoạt động với thẻ biểu mẫu hoặc dễ dàng hơn với thẻ biểu mẫu. Các nhà phát triển cuối cùng sẽ gặp phải những trường hợp này và quyết định dễ dàng hơn là luôn sử dụng chúng ở mọi nơi và tránh các vấn đề. Thực sự, câu hỏi thực sự là, tại sao không sử dụng thẻ biểu mẫu?

Ngoài ra, những thứ như jQuery .serialize()chỉ hoạt động trên các phần tử biểu mẫu.
EJTH

0

Phần tử HTML đại diện cho một phần tài liệu chứa các điều khiển tương tác để gửi thông tin đến máy chủ web.

Tất cả chúng ta đều quen thuộc với các biểu mẫu trên các trang web html. Vì nhiều lý do khác nhau mà mọi người hoặc công ty đang yêu cầu địa chỉ e-mail, tên và URL trang web của chúng tôi. Ngày nay, việc mua sản phẩm trên Internet chủ yếu là dễ dàng và với sự ra đời của các thiết bị bảo mật, phương pháp được sử dụng để gửi thông tin chi tiết và số tiền khó kiếm được thường được thực hiện thông qua biểu mẫu.

thêm thông tin

liên kết một

liên kết hai


Có, nhưng bạn không cần phải xoay quanh các đầu vào văn bản như địa chỉ email hoặc mật khẩu trong các biểu mẫu để gửi dữ liệu. Tôi có thể dễ dàng làm điều đó với ajax. Biểu mẫu không cung cấp thêm bất kỳ bảo mật nào. Tuy nhiên, tôi có thể làm điều đó với php nếu tôi mã hóa dữ liệu.
D-Marc

0

Tôi đã có một tình huống trong đó một trang web có 3 biểu mẫu, tất cả đều có các trường email riêng biệt (với các ID khác nhau). Lúc đầu tôi gói chúng riêng biệt <div>. Tính năng tự động điền của iOS trên Safari hoạt động kỳ lạ cho đến khi tôi gói tất cả chúng trong <form>thẻ. Một trong các biểu mẫu chỉ có một trường đầu vào, để đăng ký bản tin. Khi người dùng tự động điền thông tin đầu vào đó, trang web sẽ được cuộn đến trường nhập liệu tiếp theo nằm trên phần khác của trang.

Vì vậy, cảm ơn Oka cho bài viết dài. Các thẻ có ý nghĩa ngữ nghĩa nên được sử dụng bất cứ khi nào có thể, vì bạn không bao giờ biết trình duyệt / thiết bị nào không xử lý tốt các giải pháp khác.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.