Html form etiketinin amacı nedir


108

Html'deki form etiketinin amacını anlamıyorum.

Form etiketini kullanmadan herhangi bir girdi türünü mükemmel bir şekilde kullanabilirim. Girişlerin etrafına sarmak neredeyse gereksiz görünüyor.

Ek olarak, bir sunucu tarafı sayfasını çağırmak için ajax kullanıyorsam, bunun için sadece jQuery kullanabilirim. Bunun tek istisnası, bir yükleme komut dosyasını herhangi bir nedenle bir form etiketinin etrafına sarmanız gerektiğini fark ettim.

Öyleyse, metin girdileri gibi basit şeyler için formlar neden hala bu kadar yaygın olarak kullanılıyor? Yapılması çok arkaik ve gereksiz bir şey gibi görünüyor.

Bunun faydasını veya ihtiyacını görmüyorum. Belki bir şeyi kaçırıyorum.


Formunuz için html <form> etiketi olmadan eylemi ve yöntemi nasıl tanımlarsınız?
Darian

3
Bunu jQuery'de yapacak olsaydım, düğmedeki click () işlevini kullanırdım ve bunun içinde ajax () işlevini kullanırdım. Bence kodu okumak çok daha basit ve daha kolay. Sayfayı basit bir javascript ile kolayca yenileyebilirim
D-Marc

24
Bu sorunun olumsuz oy almasına şaşırdım. Bunu tamamen Google'da araştırdım.
dwjohnston

2
@dwjohnston Burada yeni olmalısın ...
Stefano Borini

3
Harika soru! Formları kullanmaktan hoşlanmadığım diğer nedenler arasında sayfa yapınızı sınırlaması (formların içinde formlara sahip olamayacağınız için), işaretlenmezse onay kutularının göz ardı edilmesi gibi bazı serileştirme tuhaflıkları (yani çoğu zaman Gönderme verilerini manuel olarak hazırlamak) ve HTML temelde sayfanın içeriği ve yapısı, JS ise dinamizmdir. JS'nin işinde form öğeleri biraz örtüşüyor ve sayfalarımın yapılandırılmasını seviyorum.
sn

Yanıtlar:


94

Eksik olan şey, anlamsal işaretleme ve DOM anlayışıdır .

Gerçekçi olarak, HTML5 işaretlemesiyle hemen hemen istediğiniz her şeyi yapabilirsiniz ve çoğu tarayıcı bunu ayrıştırır. Son baktığımda, WebKit / Blink bile verir içindeki sözde elemanları <input>elemanları spec açık bir ihlalidir olan - Gecko çok değil. Bununla birlikte, işaretlemenizle istediğinizi yapmak, anlambilim söz konusu olduğunda şüphesiz onu geçersiz kılacaktır.

<input>Öğeleri neden öğelerin içine koyarız <form>? Aynı nedenden ötürü <li>etiketleri <ul>ve <ol>öğelerinin içine koyarız - ait oldukları yerdir. Bu var semantik olarak doğru ve işaretlemeyi tanımlamak için yardımcı olur. Ayrıştırıcılar, ekran okuyucular ve çeşitli yazılımlar, anlamsal olarak doğru olduğunda işaretlemenizi daha iyi anlayabilir - işaretlemenin sadece yapısı değil, anlamı olduğunda.

<form>Eleman ayrıca tanımlamanızı sağlar methodve actionform gönderildiğinde ne yapacağını tarayıcısına anlatan, hangi bağlıyor. AJAX,% 100 kapsama aracı değildir ve bir web geliştiricisi olarak, zarif bir indirgeme alıştırması yapmalısınız; JS kapalı olsa bile formlar gönderilebilir ve veri aktarılabilir olmalıdır.

Son olarak, formların tümü DOM'a düzgün bir şekilde kaydedilir. JavaScript ile buna bir göz atabiliriz. Konsolunuzu tam da bu sayfada açarsanız ve şunu yazın:

document.forms

Sayfadaki tüm formların güzel bir koleksiyonuna sahip olacaksınız. Arama çubuğu, yorum kutuları, cevap kutusu - tüm uygun formlar. Bu arayüz, bilgiye erişmek ve bu öğelerle etkileşim kurmak için yararlı olabilir. Örneğin formlar çok kolay bir şekilde serileştirilebilir .

İşte bazı okuma materyalleri:

Not: <input>öğeler formların dışında kullanılabilir, ancak niyetiniz herhangi bir şekilde veri göndermekse, bir form kullanmalısınız.


Bu, cevabın soruyu tersine çevirdiğim kısmı.

Formlardan kaçınarak hayatımı nasıl daha da zorlaştırıyorum?

İlk ve en önemlisi - konteyner elemanları. Kimin ihtiyacı var, değil mi ?!

Kesinlikle küçük <input>ve <button>öğeleriniz bir tür konteyner öğesinin içine yerleştirilmiştir ? Her şeyin ortasında öylece yüzüyor olamazlar. Öyleyse a değilse <form>, o zaman ne? A <div>? A <span>?

Bu öğelerin bir yerde bulunması gerekir ve işaretlemeniz çılgın bir karmaşa değilse, kapsayıcı öğesi yalnızca bir form olabilir.

Hayır? Oh.

Bu noktada kafamdaki sesler, tüm bu farklı AJAX durumları için olay işleyicilerinizi nasıl yarattığınızı çok merak ediyor. Baytlardan tasarruf etmek için işaretlemenizi azaltmanız gerekirse, çok şey olmalı. Daha sonra, her bir öğe 'kümesine' karşılık gelen her AJAX olayı için özel işlevler oluşturmalısınız - bunları tek tek veya sınıflarla hedeflemeniz gerekir, değil mi? Bu unsurları genel olarak gruplamanın bir yolu yok, çünkü bunların sadece işaretleme etrafında dolaştıklarını, ihtiyaç duyulana kadar her şeyi yaptıklarını belirledik.

Yani birkaç işleyiciyi özel olarak kodlarsınız.

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

Bu, şöyle bir şey söylediğiniz kısımdır:

Yine de tamamen yeniden kullanılabilir işlevler kullanıyorum. Abartmayı bırak. "

Yeterince adil, ancak yine de bu benzersiz unsurları veya hedef sınıf setlerini yaratmanız gerekiyor, değil mi? Yine de bu unsurları bir şekilde gruplamanız gerekiyor .

Bana gözlerinizi ödünç verin (veya kulaklarınız, eğer bir ekran okuyucu kullanıyorsanız ve biraz yardıma ihtiyacınız varsa - iyi ki tüm bu anlamsal işaretlemeye biraz ARIA ekleyebiliriz , değil mi?) Ve genel formun gücünü görün.

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>

Bunu herhangi bir ortak biçimde kullanabilir, zarif bozulmamızı koruyabilir ve formun nasıl çalışması gerektiğini tamamen açıklamasına izin verebiliriz . Genel bir tarzı korurken bu temel işlevselliği genişletebiliriz - daha modüler, daha az baş ağrısı. JavaScript, uygun öğeleri gizlemek veya aldığımız herhangi bir yanıtla ilgilenmek gibi kendi şeyleri hakkında endişelenir.

Ve şimdi diyorsun:

"Ancak sözde formlarımı <div>belirli kimliklere sahip öğelere sarıyorum - daha sonra girdileri .find, ve .serializeonlarla gevşek bir şekilde hedefleyebilirim ve ... '

Ah o ne? Aslında senin sarın <input>bir kapta elemanlarını?

Öyleyse neden henüz bir form değil?


3
Bu, tüm formlara bir göz atmanın iyi bir noktasıdır. Bunun neden bir avantaj olarak görüldüğünü anlayabiliyorum. Bunun yanı sıra neden girdilerin bir form içinde kullanılması gerektiğini söylüyorsunuz? Gerçek bir avantaj sağlamıyor gibi görünüyor. Yalnızca ekstra kod. Girişleri formların dışına yerleştirmenin anlamsal olarak yanlış olduğunu söyleyen hiçbir şeyi çevrimiçi olarak okumadım, bu yüzden onu uls ve ols ile karşılaştırmanın adil olduğunu düşünmüyorum. Ve gerçekçi olarak, eğer javascript kapalıysa, hiç kimsenin web sitelerimi kullanmasını istemem. Ayrıca bu, muhtemelen çevrimiçi kullanıcıların yalnızca% 1'ini oluşturur.
D-Marc

2
<form>Öğeleri neden kullandığımıza dair bir cevap arıyormuşsunuz gibi görünmüyor ve daha çok kendi işaretleme tercihlerinizi onaylamaya çalışıyorsunuz gibi. Bu dediğim gibi, yapmanız serbesttir, gayet neyse İşaretlemenize ile sever, ama ben var geliştiricilerin formları kullanmak başlıca sebepleri açıkladı.
Oka

2
Harika puanlar verildi. Cevabınızı daha fazla detaylandırmak ve gerçek kod örnekleri sunmak için zaman ayırdığınız için gerçekten minnettarım. Formları bir kez daha deneyeceğim ve böyle yapmayı daha çok sevip sevmeyeceğime bakacağım. Yardımın için tekrar teşekkürler. Ancak, bir formu yalnızca bir metin kutusunun etrafına sarmanın anlamsız olduğunu düşünmüyor musunuz?
D-Marc

Bağlama bağlıdır. Bir API uç noktasını yalnızca AJAX aracılığıyla sorgulayan bir arama kutusu gibi doğrudan gönderilmeyen bir girdi, JavaScript olmadansubmit herhangi bir işlevselliğe sahip olmayacağı için bir forma sarılmayı ihmal edebilir . A dışında, muhtemelen zayıf anlambilimlere sahip olmak geçersiz işaretleme değildir . Verilerin AJAX olmadan, uygun bir etkinlikle gönderilmesinin bir yolu varsa , muhtemelen en iyisi formdur. Yine, öğenin bir kaba ihtiyacı vardır ve öğeler varsayılan olarak blok düzeyindedir, bu nedenle tıpkı bir . <input><form>submit<form><div>
Oka

7

Formu AJAX olmadan gönderebilmek istiyorsanız form etiketleri yine de gereklidir (bu, geliştirmenin ilk aşamalarında yararlı olabilir). Ancak javascript'i form etiketi olmadan veri göndermek için kullanmak mümkün olsa da, yine de birkaç avantaj akla geliyor:

  1. Form etiketlerini kullanmak, insanların niyetlerinizi göstererek bazı durumlarda kodunuzu okuyup anlamalarına yardımcı olabilir.
  2. 'Gönderme' yöntemi formlarda mevcuttur. Girişli [tür = gönder] bir formunuz varsa ve devre dışı bırakılmamışsa, biri diğer form girişlerinden birini doldururken "enter" tuşuna bastığında, form gönderilir. Bunu yine de giriş öğelerindeki 'keydown' olayını dinleyerek yapabilirsiniz, ancak bu, form etiketleriyle ücretsiz olarak alacağınız güzel bir kullanıcı arabirimi parçasıdır.
  3. Yalnızca form etiketiyle çalışan veya form etiketiyle daha kolay olan birkaç başka şey daha vardır. Geliştiriciler sonunda bu durumlarla karşılaşacak ve onları her zaman her yerde kullanmanın ve sorunlardan kaçınmanın daha kolay olduğuna karar verecekler. Gerçekten, gerçek soru, neden olduğu değil form etiketini kullanın?

Ayrıca, jQuery gibi şeyler .serialize()yalnızca form öğeleri üzerinde çalışır.
EJTH

0

HTML öğesi, bir web sunucusuna bilgi göndermek için etkileşimli kontroller içeren bir belge bölümünü temsil eder.

Hepimiz html web sayfalarındaki formlara aşinayız. Birçok farklı sebepten dolayı insanlar veya şirketler e-posta adreslerimizi, isimlerimizi ve site URL'lerimizi soruyor. Günümüzde İnternet üzerinden ürün satın almak çok kolay ve güvenlik cihazlarının ortaya çıkmasıyla, bilgilerinizi ve zor kazanılan parayı göndermek için kullanılan yöntem genellikle formlar aracılığıyla gerçekleştirilir.

Daha fazla bilgi

birini bağla

bağlantı iki


Evet, ancak verileri göndermek için formlarda e-posta adresleri veya parolalar gibi metin girişlerini kaydırmanız gerekmez. Bunu ajax ile kolayca yapabilirim. Formlar herhangi bir ekstra güvenlik sağlamaz. Ancak, verileri şifrelersem bunu php ile yapabilirim.
D-Marc

0

Tek bir web sayfasının 3 formu olduğu ve hepsinin ayrı e-posta alanları (farklı kimliklerle) olduğu bir senaryom vardı. <div>İlk başta onları ayrı ayrı sardım . Safari'de iOS otomatik doldurma, hepsini <form>etiketlere sarana kadar garip davrandı . Formlardan birinde haber bülteni aboneliği için yalnızca bir giriş alanı vardı. Kullanıcı bu girişi otomatik olarak doldurduğunda, web sayfası, sayfanın farklı bölümünde bulunan sonraki giriş alanına kaydırıldı.

Bu yüzden, uzun gönderi için teşekkürler Oka. Anlamsal anlamı olan etiketler mümkün olduğunda kullanılmalıdır çünkü hangi tarayıcının / cihazın diğer çözümleri iyi işlemediğini asla bilemezsiniz.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.