A honlapkészítés egyik legösszetettebb feladata az internetes űrlapok, vagy más néven formok készítése. Először is el kell készítenünk az űrlap HTML-részét, ami elviekben (majdnem) ugyanolyan egyszerű, mint például egy (kicsit bonyolultabb) táblázat összeállítása, azonban böngészés közben alaposabban megnézve a formok forráskódjait, azt láthatjuk, hogy bizony még a komolyabb cégek programozói is sok kisebb-nagyobb hibát követnek el ezek szerkesztése közben.
Egyes listákat érdemes szekciókra bontani
Miután készen van az űrlap tartalmi része, jöhet a formázás. Ennél a lépésnél sokszor komoly problémát okoz, hogy az űrlapkontrolloknak is nevezett elemek grafikai megvalósítása böngészőnként eltér, ami megnehezít(het)i ezek hajszál- vagy inkább pixelpontos elhelyezését. Ezen kívül a HTML-nyelv tervezői ugyanazzal a címkével látták el a szöveges mezőket, a csoportos és az egyedi választómezőket és a gombokat, és ahogyan azt korábban már említettük, nem minden böngésző tudja értelmezni az attribútum szelektorokat, így helyenként rákényszerülünk némi trükközésre, hogy az azonos nevű, ám teljesen eltérő elemeket megfelelően tudjuk formázni. Az olyan „apróságokról” pedig már ne is beszéljünk, hogy az – igencsak ajánlott – címkék helye is erősen függ attól, hogy éppen milyen űrlapkontrollhoz kapcsolódnak.
Egy klasszikus „felülcímkézett” minimalista elrendezés
Manapság ildomos, hogy formjaink ne csak szépek, de okosak is legyenek. Így például jó, ha egy űrlap még az adatok elküldése előtt ellenőrzi, hogy a felhasználó kitöltött-e minden szükséges mezőt, az egyes adatok formailag helyesek-e (már ahol ezt lehet ellenőrizni), és ha bármilyen hibát talál, akkor azt megfelelő formában a felhasználó tudomására hozza. Sőt, ma már több olyan űrlappal találkozhatunk az interneten, amelyek nem (csak) a küldés gomb megnyomása után ellenőrzik a megfelelő kitöltést, hanem már menet közben jelzik, ha problémát találtak. Ezenkívül főként – az átlagosnál jelentősebb – összetettebb űrlap, kérdőív esetén érdemes minél intelligensebb formokat létrehozni, amelyek folyamatosan figyelik, hogy a felhasználó hova kattint, és szükség esetén annak megfelelően „alakítják” saját magukat. Például ha a kérdőív egyik kérdése az életkor, akkor egy 14 éves felhasználótól ne akarják megkérdezni, hogy melyik főiskolára, egyetemre jár, hanem automatikusan rejtsék el ezt a kérdést.
Ha kevés a helyünk, össze is zsúfolhatjuk az elemeket
A Websuli korábbi leckéiben többször emlegetett szokásos három réteg – a tartalom, a forma és a viselkedés – az űrlapok esetében kibővül egy negyedikkel, a szerveroldali feldolgozással, hiszen az űrlapoknak (nagyon kevés kivételtől eltekintve) az a céljuk, hogy a honlap üzemeltetője adatokat gyűjtsön a felhasználóktól, a felhasználókról. Az, hogy az elküldött adatok szerveroldali ellenőrzése, tárolása és feldolgozása mi módon történik, az számos dologtól függ, ám a Websuliban – legalábbis egyelőre – egészen biztosan nem is fogunk ezzel a kérdéskörrel foglalkozni. Éppen ezért mi konferenciák honlapjához a „szegény ember űrlapját” fogjuk elkészíteni, ami az adatokat egyszerűen e-mailben küldi el az előre megadott címre.
Az űrlap kerete
Az űrlap legfőbb ismérve a HTML-kódban az, hogy egy ‹form› címkével kezdődik, amit természetesen egy ‹/form› fog majd a végén lezárni. E két címke között szinte bármilyen más HTML-elemeket használhatunk, így maguknak az űrlapkontrolloknak és az űrlaphoz szűkebben-tágabban kapcsolódó egyéb részeknek (például magyarázó szövegek, kitöltést segítő információk stb.) elhelyezését bármilyen módon, szakaszokkal (‹div›, bekezdésekkel (‹p›), listákkal (‹ul› vagy ‹ol›), táblázatokkal (‹table›), képekkel (‹img›) stb. megoldhatjuk.
Így néz ki regisztrációs űrlapunk „kerete”, azaz az eleje és a vége
A ‹form› címke legfontosabb attribútuma az ‹action›, ami tulajdonképpen nem más, mint egy relatív vagy abszolút hivatkozás a kérdőív adatait feldolgozó programra. Erre a címre a böngésző – hacsak némi JavaScript-kóddal másképp nem rendelkezünk – a küldés (Submit) gomb megnyomása, valamint sok esetben az [Enter] billentyű leütését követően küldi el a korábban bevitt adatokat. Ahogy említettük, a mi kérdőívünk e-mailben fogja elküldeni az adatokat, ezért az action attribútumnak egy szabványos, e-mailre mutató hivatkozást adjunk meg: mailto:noreplay@lorem.org. Esetleg a végére még odabiggyeszthetjük a levél tárgyát is, így a teljes hivatkozás a következőképpen fog kinézni: mailto:noreplay@lorem.org?subject=Lorem%20Ipsum%20konferencia. Nagyon fontos, hogy a szóköz helyett annak ún. escape-kódját, a %20-at használjuk, és ajánlott az ékezetes karakterek mellőzése is a címben. Az ékezetes karakterek elviekben nem okoz(hat)nak hibát, ám erősen böngésző- és levelezőprogram-függő, hogy mit is kapunk: magukat az ékezetes betűket, vagy mindenféle krikszkrakszokat.
Természetesen a „művészlelkek” az űrlapokat is feldíszíthetik (és nem csak virággal)
A böngészőnek nemcsak azt kell megmondanunk a ‹form› címkében, hogy hova, hanem azt is, hogy milyen módon és milyen kódolással kell elküldenie az adatokat. Előbbi megadására a method, utóbbiéra az enctype attribútum szolgál. A method attribútum két értéket vehet fel, az alapértelmezett GET-et (vagyis ha nem adunk meg method attribútumot, akkor az egyenértékű azzal, mintha a method="get" szerepelne a ‹form›-ban), amikor is az adatokat URL-változóként küldetjük el, vagy a POST-ot (method="post"), ami HTTP-posttranzakcióként fogja az adatokat a megadott címre elküldeni. Azt, hogy milyen módon várja az adatokat a feldolgozó program, annak írója fogja számunkra megadni, de azt tudni kell, hogy a POST egyrészt sokkal biztonságosabb (a GET például még a kicsillagozott jelszavakat is nyíltan, olvashatóan küldi el), másrészt a GET esetében a maximálisan elküldhető adatok mennyisége korlátozott. Az, hogy mennyi adatot küldhet el a felhasználó a GET metódussal, az a böngészőjétől és a feldolgozóprogramot tároló szervertől is függ. Például az Internet Explorerben egy URL legfeljebb 2083 karakter lehet, ami azt jelenti, hogy a felhasználó legfeljebb 2048 karakternyi adatot tud elküldeni. De hiába is használna valaki más böngészőt, ami akár több tízezer karakternyi adatot is képes lenne elküldeni a szerver felé (pl. a Firefox címsávjában 65 536 karakter fér el, de küldeni még ennél is többet tud), ha az Apache webszerver vagy a Microsoft IIS legfeljebb kb. 4000 karaktert, illetve maximum 16 384 karaktert képes fogadni.
A PC World regisztrációs űrlapja is a jelenleg divatos elrendezést követi
Most már tudjuk azt, hogy hova és hogy milyen módon kell küldeni az adatot, de még azt is jó, ha megadjuk, hogy milyen kódolással, erre használ(hat)juk az enctype attribútumot. Az alapértelmezett kódolás – igazodva a GET metódushoz – az application/x-www-form-urlencoded, amikor is a böngésző az adatokat szabványos URL-kóddá alakítja át. Ha azt szeretnénk, hogy az adatok semmilyen módon ne változzanak, akkor válasszuk a multipart/form-data „kódolást”, amely főként akkor nagyon ajánlott, ha az adatok feltöltött állományt is tartalmaznak. Végül választhatjuk a text/plain kódolást, ami csak annyit változtat az adatokon, hogy a szóközöket pluszjelre cseréli. Miután mi e-mailben küldetjük el adatainkat, ezért nekünk most ez utóbbit kell használnunk. Így végül is űrlapunk nyitócímkéje a következőképpen fog festeni: ‹form action="mailto:noreplay@lorem.org?subject=Lorem%20Ipsum%20konferencia" method="post" enctype="text/plain" id="registration"›
A sokoldalú ‹input› címke
A HTML mindenképpen egyik legváltozatosabb címkéje az ‹input›, hiszen attól függően, hogy milyen típust állítunk be benne, megjelenhet egyszeres vagy többszörös választómezőként, szövegbeviteli mezőként, egyszerű, összetett vagy képes gombként, de maradhat akár láthatatlan is. Azt, hogy az ‹input›-nak éppen melyik szerepét kell eljátszania, a type attribútum határozza meg. Ráadásul attól függően, hogy milyen típusú adat bevitelére használjuk ezt a címkét, lehet vagy kell a többi attribútumot beállítanunk, hiszen például egy szövegmező esetén nem sok értelme van checked paraméternek, ahogyan egy checkbox vagy egy gomb esetén a maxlength értéke értelmezhető nehezen.
Először nézzük át röviden, hogy mi mindenre is használhatjuk az ‹input›-ot, milyen hatással lesznek a címkére az egyes type értékek:
text: egy egysoros, alapértelmezés szerint 20 karakter széles szövegmezőt hoz létre, amelybe a felhasználó tetszőleges karakterekből álló szöveget gépelhet be;
password: a texthez hasonló szöveges beviteli mező, ám ennél a bevitt karaktereket a böngésző csillaggal vagy pontokkal jeleníti meg;
checkbox: egy négyzet, amelynek kijelölt állapotát általában egy pipa vagy egy kereszt jelzi, a checkbox állapotát rá- vagy a címkéjére (ld. később) kattintva változtathatjuk meg;
Bogyók és kockák, avagy egyszeres és többszörös választási lehetőségek
radio: az ún. rádiógomb a checkboxhoz hasonlóan egykattintásos választást tesz lehetővé, azzal a nem elhanyagolható különbséggel, hogy az egy csoportba tartozó rádiógombok közül mindig csak egy lehet kiválasztva;
file: egy speciális beviteli mező, amelyhez egy Tallózás (Browse) feliratú gomb tartozik, és azt a célt szolgálja, hogy a felhasználó a számítógépéről egy tetszőleges állományt tudjon a szerverre feltölteni;
hidden: egy rejtett mezőt hoz létre, ami nem jelenik meg, de aminek előre értéket adhatunk meg (például a kérdőív azonosítója, nyelve stb.) és/vagy amelynek értékét JavaScripttel módosíthatjuk (például böngésző típusa, a kitöltés ideje stb.);
button: egy kattintható gomb, amelyet a legtöbbször arra használunk, hogy a felhasználó elindítson egy JavaScript-funkciót (használata nem igazán javasolt);
submit: egy küldés gombot hoz létre, amit megnyomva a böngésző az adatokat elküldi a ‹form› action paramétereként megadott címre;
image: viselkedést tekintve megegyezik a submittel, ám gomb helyett képként jelenik meg (helyette használjuk inkább a submitet, amelynek a kinézetét a megfelelő stílusokkal átalakíthatjuk);
reset: általában a submit mellett használt gomb, aminek megnyomásra a böngésző alapállapotba hozza valamennyi űrlapkontrollt.
E gyors áttekintés után pedig nézzük meg kicsit alaposan a különböző ‹input›-típusokat.
Rövidebb és hosszabb szövegek
Rövidebb és közepesen hosszú (kb. 60–200 karakter) szövegek bevitelére text típusú ‹input› űrlapkontrollt használunk. Ahogyan azt fentebb már említettük, ez az elem egy alapértelmezés szerint 20 karakter széles egysoros szövegbeviteli mezőt hoz létre. Ebbe a mezőbe a felhasználó elviekben tetszőleges hosszú szöveget vihet be, amely ha nem fér el, akkor a böngésző automatikusan balra vagy jobbra görgeti a kilógó részeket. A mező szélességét a size attribútummal változtathatjuk meg, ami azt mondja meg a böngészőnek, hogy hány karakternyi helyet biztosítson a beírandó szövegnek – azonban a szélességet több ok miatt is érdemesebb az elemhez rendelt width stílussal módosítani. Már csak azért is, mert a böngészők a size alapján a saját stíluslapjukból számolják ki a mező szélességét, így ez böngészőnként szinte biztosan el fog térni, míg width-tel pixelben megadva mindig ugyanazt a méretet fogjuk kapni. Ugyanakkor a mező magasságát hiába változtatjuk meg, attól csak több helyet fog foglalni, de többsorossá nem válik, az text típusú ‹input› mindig egysoros lesz.
A hosszabb kérdőíveket néha érdemesebb többoldalasra elkészíteni
A szövegmezőnek – ahogyan minden más űrlapkontrollnak – meg kell adnunk egy nevet, amilyen néven a későbbiekben hivatkozni tudunk rá. Nevet természetesen a name attribútumnak értéket adva rendelhetünk az egyes kontrollokhoz. Elvi korlátozás nem sok van a név megadáskor, azonban érdemes itt is odafigyelni olyan apróságokra, mint például hogy a név betűvel kezdődjön, és ne használjunk benne ékezetes és speciális karaktereket, valamint szóközt. A név mellett érdemes, sőt sok esetben kimondottan ajánlott megadni egy egyedi azonosítót (id) is, amelynek – már csak kényelmi okok miatt is – érdemes ugyanazt választani, mint a névnél (kivéve a rádiógomboknál, de erről később).
A Yahoo! űrlapja folyamatos ellenőrzi a beírt adatokat
Sok esetben előfordul, hogy szeretnénk korlátozni a szövegmezőbe bevihető karakterek számát, egyrészt azért, mert például teljesen felesleges megengedni, hogy egy név mezőbe akár több száz karaktert vihessenek be, másrészt, mert ha az adatbázis létrehozásakor meghatároztuk, hogy a nevet legfeljebb 60 karakteren tároljuk, akkor a 62 karakteren bevitt név vége elveszik, vagy rosszabb esetben programhibát okoz feldolgozás közben. Az egy mezőbe bevihető karakterek számát a maxlength attribútum határozza meg. Például a böngésző a ‹input type="text" name="lastname" id="lastname" maxlength="60" /› címkével létrehozott szövegmezőbe legfeljebb 60 karaktert enged bevinni.
A más kontrolloknál ajánlott (submit, reset), sőt egyeseknél kötelező (checkbox, radio) value attribútumot a szövegmezőknél csak nagyon ritkán szoktuk használni. Ez a paraméter egy alapértelmezett értéket rendel a változóhoz, amit a felhasználó megváltoztathat – hacsak a disabled vagy a readonly attribútumokkal nem zároljuk a mezőket. Ezeknek az attribútumoknak kötelezően a saját nevüket kell megadni értékként, vagyis a disabled="disabled" és a readonly="readonly" formát kell használni, ha tiltani akarjuk a szövegmező módosítását. A kettő között szöveges kontrollok esetén semmi különbség nincs, ám míg tiltani bármilyen kontrollt tudunk, addig csak olvashatóvá csak szövegeseket tehetünk (text és password).
Így néz ki űrlapunk a formázás után
Ha szeretnénk lehetővé tenni, hogy a felhasználó hosszabb, akár több ezer karakteres szövegeket vihessen be, akkor e célra nem igazán alkalmas ez a megoldás. A szöveges ‹input› mezőbe a felhasználó elviekben akár ilyen hosszú szöveget is nyugodtan begépelhet – hacsak a maxlength-szel nem korlátoztuk a karakterek számát –, azonban ennek áttekinthetősége nem igazán mondható optimálisnak. Ezért az ilyen esetekben (például megjegyzések, észrevételek, szabad üzenetek) az ‹input› kontroll helyett érdemesebb a ‹textarea›-t használni. Ennél a kontrollnál a szélességet a size helyett a cols, míg a magasságot a rows attribútummal lehet megadni, de ezek helyett használhatjuk a width és a height stílusokat is. Az ‹input›-hoz képest jelentős eltérés, hogy a ‹textarea›-nál nincs value attribútum, hanem helyette az alapértelmezett értéket a nyitó és a záró címke közé kell írnunk, de ha ilyet nem adunk meg, akkor sem használhatjuk a rövid változatot (‹textarea /›), hanem ki kell írnunk a nyitó és a záró címkét: ‹textarea cols="65" rows="5" name="comment" id="comment"›‹/textarea›
Érdekes és sokszor bosszantó, hogy ellentétben az ‹input›-tal, a ‹textarea›-nál nincsen maxlength attribútum, vagyis ha szeretnénk korlátozni ezeknél a maximálisan bevihető karakterek számát, akkor erről nekünk kell programozottan gondoskodnunk (ahogyan azt a következő leckénél meg is tesszük).
Választási lehetőségek
Sok esetben – főként a felhasználónak – kényelmesebb, ha nem szövegesen kell válaszolnia egyes kérdésekre, hanem választhat a felkínált lehetőségekből.
Erre a célra használhatjuk az ún. választókapcsolókat, vagy ismertebb nevükön chekboxokat. Arra nagyon oda kell figyelnünk az űrlapok szerkesztésekor, hogy önmagában egy ilyen checkbox nem más, mint egy négyzet, ami vagy ki van jelölve vagy nincs, ezt a felhasználó a négyzetre történő kattintással változtathatja. Ezeket a kapcsolókat – ahogyan azt korábban már említettük – szintén egy ‹input› címkével tudjuk létrehozni, ha a kontroll típusának checkboxot adunk meg. Ezen kívül szükség lesz még egy névre (name) és egy értékre (value) is, hogy a böngésző tudja, milyen néven és milyen értéket kell a feldolgozóprogramnak elküldenie, ha a kapcsoló éppen „be” állásban van (ha üres, akkor az érték is üres lesz): ‹input type="checkbox" name="frm_prn" id="prn" value="prn" /›.
Az id attribútumot a választókapcsolók esetén kiemelten fontos megadni, hogy a kapcsolóhoz tartozó címke tudjon mire hivatkozni. Ugyanis amíg a szöveges mezőknél csak érdemes, addig a választókapcsolók és a rádiógomboknál szinte kötelező a címkék használata – és ez az, amiről nagyon sokan megfeledkeznek.
Főként a rádiógombok és a választómezők néznek ki nagyon másként az Internet Explorerben
Azt, hogy az egyes mezőknél milyen adatot is várunk, azt valamilyen módon a felhasználó tudomására kell hoznunk. Ahogyan azt a ‹form› címke bemutatásánál is mondtuk, az űrlapon belül szinte bármilyen HTML-elemet használhatunk – többek között arra is, hogy jelezzük, milyen adatot kell bevinni a szövegmezőkbe, mit is jelentenek az egyes kapcsolók. Sok űrlap esetében erre a célra sima szövegeket – alig valamivel jobb megoldásként ‹span›-okba vagy táblázatcellákba ágyazva – szoktak használni, amelyeknél csak megjelenésük helyéből derül ki, hogy melyik kontrollhoz is tartoznak. Egy szövegmező vagy pláne egy szöveges terület esetében ez még nem annyira probléma, ezeknél még elmegy ez a megoldás is. Azonban a felhasználók a programoknál megszokták, hogy egy választókapcsoló esetén nem feltétlenül kell magára a kontrollra kattintani, sok esetben sokkal kényelmesebb a hozzá kapcsolódó szöveg fölött ugyanezt megtenni, az eredmény ugyanaz lesz. De ha semmi nem kapcsolja össze a kontrollt és a leíró szöveget, akkor honnan tudja a böngésző, hogy egy adott szöveges elemre kattintáskor melyik kontroll állapotát kell megváltoztatni? Ezért érdemes ezeket a leíró szövegeket az erre a célra szolgáló címkeelemekbe ágyazni. Például ha a fenti checkbox elé vagy mögé illesztünk egy címkeelemet (‹label for="prn"›nyomtatott változat‹/label›), akkor a böngésző már tudni fogja, hogy ha erre a szövegre kattint valaki, akkor azt ugyanúgy kell kezelni, mintha a prn azonosítójú kontrollra kattintottak volna. Ez esetben ezt azt jelenti, hogy meg kell változtatni a prn azonosítóval ellátott kapcsoló állapotát, de ha egy olyan címkére kattintunk, ami például egy szövegmezőhöz kapcsolódik, akkor ezzel azt a szövegmezőt tesszük aktívvá.
Csak egy maradhat
A már többször említett rádiógombok nem csak annyiban térnek el a választókapcsolóktól, hogy kör alakúak, míg azok négyzetesek, hanem sokkal inkább abban, hogy amíg a checkboxok „önálló életet élnek”, és egymástól teljesen függetlenül tudjuk állapotukat változtatni, addig az egy csoportba tartozó rádiógombok közül mindig csak egy lehet kijelölve. Azaz, ha az egyikre – vagy a hozzá kapcsolódó címkére – rákattintunk, akkor azt kijelöljük, de ezzel biztosan megszüntetjük az összes többi kijelölését.
A Google Chrome űrlapelemei mintha a Firefoxból erednének
Azt, hogy mely rádiógombok tartoznak egy csoportba, az dönti el, hogy azonos-e a nevük. Ahogyan az a regisztrációs űrlapunk forráskódjában is látható, a 195. és a 196. sorokban, valamint a 205. és 206. sorokban található rádiógomboknak azonos a nevük, így ha e kontrollok bármelyikére is kattint a felhasználó, az biztos, hogy a kontroll párjának megszűnik a kijelölése. Természetesen nemcsak kettesével rendelhetünk össze rádiógombokat, hanem egy-egy csoportban tetszőleges számú ilyen „gombóc” lehet. E példákból az is jól látszik, hogy miért is kell ez esetben a névnek és az azonosítónak eltérnie. Hiszen amíg a név nem egyedi (kettő vagy több elem is ugyanazt a nevet viseli), addig címkét csak egyedi azonosítóhoz rendelhetünk. (Egy ilyen sima igen-nem kérdés megválaszolására használhattunk volna checkboxot is, ám ha kötelezővé tennénk a választ erre a kérdésre, akkor már nem tudnánk eldönteni, hogy a felhasználó „nem”-et akart-e mondani, vagy csak elfelejtett válaszolni a kérdésre.)
Választás listából
Azokban az esetekben, amikor vagy (nagyon) sok választási lehetőséget kínálunk a felhasználónak, vagy szeretnénk némi helyet spórolni az űrlapon, felkínálhatunk egy listát, amiből a felhasználó egy vagy több lehetőséget választhat. Az ilyen listákat ‹select›‹/select› címkék közé, magukat a listaelemeket pedig ‹option›‹/option› címkék közé kell illeszteni, sőt arra is lehetőségünk van, hogy az összetartozó elemcsoportokat ‹optgroup›‹/optgroup› címkékkel vehetjük körbe, amelyekhez címke (label) attribútumokat is megadhatunk.
A szokásos név-érték összerendelés ezeknél a listáknál úgy történik, hogy a nevet a listához, vagyis a ‹select›-hez, míg az értékeket a listaelemekhez, azaz a ‹option›-ökhöz rendelhetünk. Utóbbiak esetében, a value értéket nem kell megadnunk, ezek hiánya esetén az ‹option› és ‹/option› közötti szöveg lesz a listaelemhez rendelt érték.
Az Operában megint másként jelennek meg a grafikai elemek
Alapértelmezés szerint ezekből a listákból a felhasználó csak egy elemet választhat ki, de a multiple="multiple" attribútum megadása esetén a ‹Shift› és ‹Ctrl› billentyűk nyomva tartásával egyszerre több listaelem is kijelölhető, míg alapértelmezett kijelölés(eke)t is megadhatunk az ‹option› elemekhez rendelt selected="selected" attribútummal.
Kontrollcsoportok
Hosszabb, 4-5 kontrollnál többet tartalmazó űrlapok esetén javasolt az összetartozó kontrollokat tartalmilag és látványban is jól elkülöníteni. Ezt elviekben megtehetnénk sima ‹div›-ekkel vagy sok más módon, azonban a HTML-nyelv kitalálói erre a célra külön elemet hoztak létre, a ‹fieldset›-et, így az összetartozó kontrollokat érdemes egy ‹fieldset›‹/fieldset› páros közé helyeznünk. A böngészők ezeket a ‹fieldset›-eket jellemzően önálló kerettel látják el, amelynek felső vonalára némi szöveget illeszthetünk, amit a ‹fieldset›-en belül elhelyezett ‹legend› elemben kell elhelyezni.
Küldés és törlés
Ahhoz, hogy a felhasználó el tudja küldeni a megadott adatokat, szükség van egy gombra, aminek megnyomásakor a böngésző az űrlapkontrollok tartalmát elküldi a ‹form›-ban megadott címre – e célra szolgálnak a submit típusú ‹input› elemek. Ilyen gombból elviekben tetszőleges számú lehet egy űrlapon belül, de ezek megnyomása mindig ugyanazt a hatást fogja eredményezni. Ezeknek a gomboknak is adhatunk értéket, ami – eltérően a többi kontrolltól – a gomb alapértelmezett feliratát fogja módosítani.
A Safariban minden kicsit gömbölyűbb, így az űrlapok elemei is
A submit gomb mellé érdemes egy olyan gombot is elhelyezni, amelynek megnyomásával a felhasználó alaphelyzetbe állíthatja az űrlap kontrolljait. Ez csak annyiban tér el a küldésétől, hogy a típusa reset.
*
Legközelebb űrlapunknak némi formát is adunk, sőt egyik-másik kontroll viselkedésén is módosítunk egy kicsit.
A Wufoo online űrlapkészítő programjában számos hasznos ötlettel találkozhatunk
A cikkben szereplő forráskódok letölthetők innen
