Share
Även om det finns många ändringar till det bättre i HTML5-specifikationen, finns det inget bättre resultat för pengarna för den datastyrda webbplatsen än omformningen av formulär. Dessa enkla ändringar kommer att ändra hur du anger, validerar, bearbetar och till och med visar inmatningar. Du kommer att kunna skapa mer användbara webbapplikationer med mindre kod och mindre förvirring.
"Under senare tid har majoriteten av innovation i former kommit från användningen av JavaScript, snarare än gammaldags HTML. Medan det inte finns något fel med att använda JavaScript för att förbättra formulär, ger den sin egen användbarhet tillsammans med många utvecklingshuvudvärk. "
HTML 5 genomgår fortfarande ändringar innan det slutförs. Om du tittar på specen ser du att det fortfarande finns ett sista samtal för kommentarer tillsammans med uttalanden, till exempel, Implementatörer bör vara medvetna om att denna specifikation inte är stabil. Dessutom, speciellt för syftet med denna handledning, med fokus på förändringarna i blanketter, är webbläsarimplementation spottig minst sagt. Med det sagt är förändringarna i horisonten värda att undersöka idag. Även om förändringarna är stora, verkar implementeringen för utvecklare ganska lätt. I den här handledningen tar vi en överblick över dessa banbrytningsändringar och tänker på hur de påverkar användarens ingång.
Tidigare har förändringar i blanketter varit relativt mindre. Om du går tillbaka till HTML 3.2-specifikationen, som slutfördes 1997, kommer du att se samma grundläggande formulärinsatser som du använder idag. Välj, textarea, radio, kryssrutor och text var tillgängliga då. En generation webbutvecklare har vuxit skrivning till samma standarder. Medan senare versioner av specifikationen medförde ändringar i formulär, som fältet, etiketten, legenden och formuläråtgärder som onsubmit eller onchange, har sättet vi hanterar användarinmatningen förbli något statiskt. Under de senaste åren har majoriteten av innovation i former kommit från användningen av JavaScript, snarare än gammaldags HTML. Medan det inte finns något fel med att använda JavaScript för att förbättra formulär, ger det sin egen användbarhet tillsammans med många utvecklingshuvudvärk. Det finns till exempel många olika sätt att vi kan validera formulär med hjälp av JavaScript, men vad händer när en användare inte har JavaScript aktiverat? Vi måste vidare tillämpa logik på våra serversideskript. I slutändan har vi ett inte så konsekvent sätt att hantera användarinmatning. HTML 5 tar inte upp alla innovationshuvudvärk för formulär under de senaste 13 åren, men det ger oss massor av verktyg för
göra våra jobb mycket enklare och tillåter oss att producera mycket mer konsekventa former.
Det finns tre grundläggande förändringar som vi bör undersöka. Först kommer vi att titta på ändringarna till inmatningselementen, som autokomplettering eller autofokus. Den andra är ändringar i ingångsstaten, och det finns ganska många! Slutligen ska vi undersöka de nya formulärelementen. Det är viktigt att återställa att specifikationen är i flöde; så jag skulle inte bli förvånad om det i framtiden finns subtila förändringar i det vi diskuterar. Det är det som gör det roligt!
Input attribut är de objekt som du placerar i ingångar för att förklara vad ingången gör. Till exempel:
I exemplet ovan är ingångsattributen värde, storlek och maxlängd. Dessa har funnits länge. HTML 5 ändrar inte begreppet att ha inmatningselement, utan lägger till ganska många fler. Det verkar vara minst en subtraktion, eller snarare substitution, och det är ändringen av funktionshindrade ser nu ut att bli readonly. Specen går inte i detalj till förändringen, men om jag var en spelande man skulle förändringen möjliggöra händelsehanterare, såsom onblur, att elda - vilket ett inaktiverat element förhindrar.
De nya attributen inkluderar autofokus, autofullständig, lista, obligatorisk, multipel, mönster, min och max, steg och platshållare. Jag tänker på dessa som två olika smaker av element. Den första smaken ökar användarens upplevelse, medan den andra förbättrar utvecklingsupplevelsen. Vad jag menar med detta är autofokus, autofullständig, lista, flera och platshållare hjälper användarupplevelsen vid val av objekt, eller kanske genom att ge en beskrivning av vad blankettinmatningen söker eller genom att hjälpa till att fylla i formuläret. krävs, min och max, mönster och steg lägger till utvecklingserfarandet genom att säga vad som borde vara i själva formen.
Vad varje av dessa nya attribut gör är relativt lätt att förstå. Till exempel:
Ovan fokuserar autofokuselementet textinmatningen på sidbelastning. Det betyder att så snart sidan laddas är denna textinmatning redo att ta en post. Du kan börja skriva direkt, eftersom det här elementet har fokus för dokumentet. Något som vi brukade göra i JavaScript i en linje eller så, kan nu göras med ett enda ord.
I ovanstående exempel, genom att stänga av autofullständig, behåller du webbläsaren från att fylla i formulärfältet från ett tidigare värde. Ingenting buggar mig mer än att se mitt kreditkortsnummer komma i form så snart jag skriver en siffra. Standard för autokomplettering ska vara på, så den enda gången du behöver använda detta element är när du vill förhindra att formulärfältet fyller i från tidigare poster. Det lägger till användarupplevelsen genom att hålla känslig information från bara "poppar upp".
Listattributet är väldigt coolt. I huvudsak tillhandahåller du en datalist, och det kommer att skapa en nedgång från din textinmatning. Tänk på det som en naturlig automatisk komplett. Ta det lite längre, och i stället för att du måste lägga till ett JavaScript-bibliotek för en snabb uppslagning, baserat på nyckelposter, kan du enkelt lägga till en händelsehanterare med en AJAX-post och du hamnar med en droppe ner som blir mer specifik som användaren skriver in i lådan. Med HTML 5 skapas denna funktionalitet med bara några rader.
Med flera attribut kan du välja flera objekt från din datalista. Du kan till exempel ha en blankett som skickar meddelanden från din webbplats. Genom att använda multipelelementet kan du tillåta användaren att välja flera mottagare för att skicka meddelandet. Det här är något vi kan åstadkomma med lite JavaScript nu, men med HTML 5 behöver vi bara lägga till ett enda kommando i formuläret.
Platshållarens attribut är något vi har gjort i åratal med en touch av JavaScript. Vad detta gör är, så snart inmatningen är inriktad, kommer Typ här att försvinna. Om det inte fanns någon ändring i texten på oskärpa, kommer Typ här att visas igen. Än en gång tar vi lite JavaScript ut ur bilden för att förbättra användarupplevelsen.
Dessa nya nya attribut förbättrar hela vår utveckling. Med undantag för "steg", varje hjälpmedel vid validering av användarinmatningen.
Det nödvändiga attributet är exakt som det låter. Jag, utvecklaren av den här webbsidan, kräver att du fyller i det här formuläret innan du skickar in. Det här är den grundläggande formulärvalideringen som vi använder idag med JavaScript. Vad tog ett bibliotek innan för att lägga till en obligatorisk post, tar nu ett enda ord i formuläret.
Av alla de nya formattributen är detta det jag är mest glada över. Herr Form, låt mig presentera dig för min gode vän, Regex. Det är rätt, vi kan validera formulärposter baserat på reguljära uttryck. Medan den här kommer att vara mystifierande först, när du lär dig regelbundet uttryck, blir möjligheterna att validera nu oändliga.
Jag har klumpat de sista tre i ett exempel, eftersom de alla handlar om nummervalidering - eller det antal nummer som vi kan inkludera.
Var och en av dessa handlar om numeriska värden. Förvirra inte dem med maxlängd, som handlar om antalet tecken en ingång kommer att ta. Stegelementet är precis som det låter. När du väljer ett numeriskt värde, steg upp det med .5 eller nere med .5 - vilket betyder denna ingångstyp kommer att ha möjliga värden på 1, 1,5, 2, 2,5 och så vidare.
Från och med nu, så vitt jag vet, är webbläsarstöd lite spottigt på dessa attribut. Här är ett snabbt diagram som visar vad jag kunde hitta på implementeringarna.
Det finns åtta nya ingångstyper, som inte räknar alla nya datum och tidstyper, som i vårt syfte klarar jag i en. Det är viktigt att notera att webbläsare som inte har implementerat de nya inmatningstyperna kommer att försämras till en typ av text på var och en som jag har testat. Vad de nya inmatningstyperna ger är en förmåga att validera användarinmatning baserat på vilken typ du använder. Det finns också mer validering att komma som jag kommer att diskutera i de följande två avsnitten. Var och en av de nya inmatningstyperna gör att vi kan skilja från ett textfält till något mer specifikt. Till exempel, för att ta heltal eller float-värden före HTML 5, använde vi mest en inmatningstyp av text. Bara från anteckningen är den kontra intuitiv för nybörjare. Genom att vara mer specifika har vi bättre visuell kontroll över vårt gränssnitt, ju mer specifikt elementet i HTML, desto större kontroll har du från CSS, och desto lättare är det att definiera de visuella elementen. Dessutom kan webbläsare med de nya specifika ingående typerna finjustera vad inmatningsområdet ska vara. Slutligen kan vi, med mobildatabasen, skapa webbsändningsformulär som kan formas så att de ser ut som naturliga applikationer eller kan forma tangentbordet som vi använder.
Låt oss titta på nummerhantering först:
Vart och ett av dessa ingångstyper tillåter oss att spela med siffror, och när vi skickar in formulären bör vi vara säkra på att vi har dessa float-värden för vår server-sida-bearbetning utan den tilläggna JavaScript-valideringen. Enkelt uttryckt, för vart och ett av dessa typer väntar vi oss på att få nummer tillbaka inom det område som vi definierar och med det steg vi vill ha. Skillnaden mellan de två typerna är hur de visas. Medan jag väntar på att se implementering på taltypen, skulle jag förvänta mig antingen en rulle eller en textruta, eller möjligen en typ av ett val med siffror. Typ av intervall är lite annorlunda, eftersom det ser ut som ett glidande värde, som liknar vad du förväntar dig att se för en volymkontroll.
En annan stor lättnad att standardisera din backend utveckling är den nya datum och tid input typer. Från Opera-implementeringen som jag har sett visar varje kalender kalendern, vilket gör det möjligt för användaren att välja ett datum. Återigen kan vi validera på vår hemsida att ingången är i det format som vi förväntar oss. Varje gör precis vad du skulle tro Du väljer en månad, vecka, dag eller tid. Den som är lite annorlunda är datetime-local, som visar datum och tid utan tidszonförskjutning. Om du till exempel väljer ett flyg, skulle datetime-lokal visa tid och datum i staden du går, vilket inte nödvändigtvis är den tidszon du är närvarande i.
Var och en av dessa ingående typer är beskrivande. Webbadressen och e-posttyperna har båda valideringarna av giltiga urlmönster och giltiga e-postmönster. Telefonen överensstämmer emellertid inte med något specifikt mönster. Det spårar bara raster. Om du vill genomdriva ett valideringsmönster i telefonfältet kan du alltid använda mönstret. Vart och ett av dessa element minus färg kommer också att ta listattributet, minus färg. Färg är oddballen av gänget; Jag kan se den praktiska användningen, där du kan välja en färg från en fin dragning som visar färger och genomdriva textinmatningen på något som # 000000, men det passar mig inte riktigt över resten av ändringarna, enligt min mening. Det är som att spela vilken som inte är som de andra.
Liksom attributen är implementering av inmatningstypens webbläsare ganska spottig. Min iPhone verkar stödja mer av dessa än Safari, vilket är lite roligt för mig. Detta är det bästa jag kunde hitta, som att stödja.
Antalet ändringar i formulärelementen är inte lika drastiska som ingående attribut och typer. Det sagt är det några nya element att vara medveten om. Vi har redan täckt datalist - det är hur vi definierar vad som ska väljas från ett listelement-samtal - men vi har inte sett nyckelgener, utdata, framsteg eller mätare. Utanför keygen. Dessa är inte helt lika självförklarande som de nya attributen. Låt dig gräva i dessa bara lite.
Den här är lite förvirrande. Det genererar inte en offentlig nyckel för dig. Istället är det en nyckelpargeneratorstyrning. När formuläret har skickats, paketerar det nyckelparet för att lagra den privata nyckeln i den lokala nyckelhallen och skickar den offentliga nyckeln tillbaka till servern. Det kommer att generera klientcertifikatet och erbjuda det tillbaka till användaren att ladda ner. När du har laddat ner och sparat med den privata nyckeln kan du sedan verifiera tjänster, till exempel SSL eller certifikatautentisering.
+ =
Tänk på utgångselementet som ett textområde på steroider. Vad du kan göra är att beräkna från två typtypsinmatningar och mata ut den beräkningen utan att någonsin skicka formuläret tillbaka till servern. Om du bara returnerar falskt usubmit, i det ovanstående exemplet, kommer det att beräkna number_1 plus number_2 och ge dig svaret. Som många saker som diskuteras i den här handledningen är det något vi kan uppnå idag med JavaScript, men det minskar verkligen mängden kod som vi behöver skriva i framtiden.
12cm
De sista två nya elementen är framsteg och mätare. De är lika, men med en skillnad. Framsteg är tänkt att användas för att mäta framsteg i en viss uppgift. Om du till exempel har fem sidor att slutföra innan en undersökning görs, skulle du visa framstegselementet i det området. Mätaren är å andra sidan en mätning av någonting. Det kan hända att du visar resterande diskutrymme som en användare har lämnat. Du skulle använda mätaren för att visa den mätningen. Det finns nya gränselement, som låga, höga och optimala. Dessa ersätter min- eller maxelementen; så om de överstiger dem blir de nya formens nedre och övre gränser.
Liksom resten av HTML 5-formuläret ändras, är webbläsarens implementering dålig för tillfället. Heres vad som verkar fungera, och vad gör inte (vid tidpunkten för detta skrivande).
Från vad jag kan se finns det ingen anledning att inte börja använda HTML 5-formulär. Inmatningselementen och typerna bryts alla bra, även i IE6, där de antingen ignoreras som element eller försämras till textingångar. Vi måste vänta ett tag för att valideringsattributen ska bli verklighet, men med det sagt finns det fortfarande vissa användningsområden idag utan dessa fördelar. IPhone ändrar till exempel tangentbordet om du använder url-, e-post- eller nummertyperna. Sortimentets ingångstyp stöds redan i WebKit-webbläsare, så du kan vara den första barnen i blocket med ett antal glidreglage som fungerar utan JavaScript. Specen slutförs snabbt, och webbläsare hämtar sig ganska snabbt till paradigmskiftet. Det finns ingen tid som nuvarande att åtminstone börja leka med dessa nya leksaker! Vad tror du?
Accentsconagua