Share
Hoewel er veel veranderingen zijn ten goede in de HTML5-specificatie, is er geen betere mogelijkheid voor de data-driven website dan de transformatie van formulieren. Deze eenvoudige wijzigingen zullen de manier waarop u invoer invoert, valideert, verwerkt en zelfs weergeeft, transformeren. U zult meer bruikbare webtoepassingen kunnen maken met minder code en minder verwarring.
"In het recente verleden is het merendeel van de innovatie in formulieren afkomstig van het gebruik van JavaScript in plaats van ouderwetse HTML. Hoewel er niets mis is met het gebruik van JavaScript om formulieren te verbeteren, brengt het zijn eigen bruikbaarheid samen met veel ontwikkelingshoofdpijn. "
HTML 5 wordt nog steeds gewijzigd voordat het is voltooid. Als u naar de specificatie kijkt, ziet u dat er nog steeds een laatste oproep is voor opmerkingen, samen met verklaringen, zoals, Uitvoerders moeten zich ervan bewust zijn dat deze specificatie niet stabiel is. Bovendien, met name voor de doeleinden van deze zelfstudie, met de nadruk op de wijzigingen in formulieren, is de implementatie van de browser op zijn zachtst gezegd vlekkerig. Dat gezegd hebbende, de veranderingen aan de horizon zijn het bekijken waard vandaag. Hoewel de wijzigingen van groot belang zijn, lijkt de implementatie voor ontwikkelaars vrij eenvoudig. In deze zelfstudie zullen we een hoog niveauoverzicht van deze baanbrekende veranderingen bekijken en nadenken over hoe deze van invloed zijn op de aard van gebruikersinvoer.
In het verleden waren wijzigingen in vormen relatief gering. Als u teruggaat naar de HTML 3.2-specificatie, die in 1997 werd voltooid, ziet u dezelfde ingangen voor basisvormen die u vandaag gebruikt. Selecteer, tekstgebied, radio, checkboxes en tekst waren toen beschikbaar. Een generatie webontwikkelaars is opgegroeid met het schrijven naar dezelfde normen. Terwijl latere versies van de specificatie wijzigingen in formulieren brachten, zoals de veldset-, label-, legenda- en formulieracties, zoals onsubmit of onchange, is de manier waarop we omgaan met gebruikersinvoer enigszins statisch gebleven. In het recente verleden is het merendeel van de innovatie in formulieren afkomstig van het gebruik van JavaScript in plaats van ouderwetse HTML. Hoewel er niets mis is met het gebruik van JavaScript om formulieren te verbeteren, brengt het zijn eigen bruikbaarheid samen met veel ontwikkelingshoofdpijn. Er zijn bijvoorbeeld veel verschillende manieren waarop we formulieren kunnen valideren met JavaScript, maar wat gebeurt er als een gebruiker JavaScript niet heeft ingeschakeld? We moeten verder logica toepassen op onze server side scripts. Uiteindelijk hebben we een niet zo consistente manier om met gebruikersinvoer om te gaan. HTML 5 behandelt niet elke innovatiehoofdpijn voor vormen in de afgelopen 13 jaar, maar het geeft ons wel voldoende hulpmiddelen
onze banen veel gemakkelijker maken, en stelt ons in staat om veel meer consistente vormen te produceren.
Er zijn drie basisveranderingen die we moeten onderzoeken. Eerst kijken we naar de wijzigingen in de invoerelementen, zoals automatisch aanvullen of autofocus. De tweede is veranderingen in de invoerstaten, en dat zijn er nogal wat! Ten slotte zullen we de nieuwe formulierelementen bekijken. Het is belangrijk om te herhalen dat de specificatie in beweging is; dus ik zou niet verbaasd zijn als er in de toekomst subtiele veranderingen komen in wat we bespreken. Dat is wat dit leuk maakt!
Invoerattributen zijn die items die u invoert om uit te leggen wat de invoer aan het doen is. Bijvoorbeeld:
In het bovenstaande voorbeeld zijn de invoerattributen waarde, grootte en maximumlengte. Deze bestaan al geruime tijd. HTML 5 verandert niets aan het concept van invoerelementen, maar voegt er nogal wat meer aan toe. Er lijkt tenminste één aftrekking te zijn, of liever substitutie, en dat is de verandering van invalide die nu alleen lijkt te worden gewijzigd. De specificatie gaat niet gedetailleerd in op de wijziging, maar als ik een gokfiguur was, zou de wijziging toestaan dat gebeurtenishandlers, zoals onblur, vuren - wat een uitgeschakeld element voorkomt.
De nieuwe kenmerken omvatten autofocus, automatisch aanvullen, lijst, vereist, meerdere, patroon, min en max, stap en tijdelijke aanduiding. Ik zie deze als twee verschillende smaken van elementen. De eerste smaak verbetert de ervaring voor de gebruiker, terwijl de tweede de ontwikkelingservaring verbetert. Wat ik hiermee bedoel, is autofocus, automatisch aanvullen, lijst, meerdere en placeholder helpt de gebruikerservaring bij het selecteren van items, of misschien door een beschrijving te geven van waar de invoer van het formulier naar op zoek is, of door hulp bij het invullen van het formulier. vereist, min en max, patroon en stap voegen toe aan de ontwikkelingservaring door te zeggen wat er in het formulier zelf zou moeten staan.
Wat elk van deze nieuwe kenmerken doet, is relatief eenvoudig te begrijpen. Bijvoorbeeld:
Hierboven stelt het autofocuselement de tekstinvoer bij het laden van de pagina scherp. Dit betekent dat zodra de pagina wordt geladen, deze tekstinvoer gereed is om een invoer te maken. U kunt meteen beginnen met typen, omdat dit element de focus van het document heeft. Iets dat we vroeger in JavaScript deden in een rij of zo, kan nu met een enkel woord worden gedaan.
In het bovenstaande voorbeeld, door autocomplete uit te schakelen, zorgt u ervoor dat de browser het formulierveld niet van een vorige waarde invult. Niets doet me meer dan dat ik mijn creditcardnummer in een formulier zie verschijnen zodra ik een cijfer typ. De standaardwaarde voor automatisch aanvullen is ingeschakeld, dus de enige tijd die u nodig hebt om dit element te gebruiken, is wanneer u wilt voorkomen dat het formulierveld uit eerdere items wordt ingevuld. Het draagt bij aan de gebruikerservaring door gevoelige informatie te houden van "gewoon" opduiken.
Het lijstkenmerk is erg cool. In wezen geeft u een datalist op, en het zal een vervolg op uw tekstinvoer creëren. Zie het als een natuurlijke auto compleet. Ga nog een stapje verder en in plaats van een JavaScript-bibliotheek toe te voegen voor een snelle opzoeking, op basis van sleutelitems, zou je eenvoudig een "onchange" event handler kunnen toevoegen, met een AJAX-bericht, en dan krijg je een drop-down naar beneden dat specifieker wordt naarmate de gebruiker de box invoert. Met HTML 5 kan deze functionaliteit met slechts enkele regels worden gemaakt.
Met het kenmerk Meervoud kunt u meerdere items uit uw datalist selecteren. U hebt bijvoorbeeld een formulier dat berichten van uw website verzendt. Door het meerdere elementen te gebruiken, kunt u de gebruiker toestaan meerdere ontvangers te selecteren om dat bericht te verzenden. Nogmaals, dit is iets wat we nu met een beetje JavaScript kunnen bereiken, maar met HTML 5 hoeven we slechts één enkele opdracht aan het formulier toe te voegen.
Het kenmerk placeholder is iets wat we al jaren doen met een vleugje JavaScript. Wat dit doet is, zodra de invoer gefocust is, zal Type Here verdwijnen. Als er geen verandering in de tekst is bij vervaging, verschijnt Type Hier opnieuw. Nogmaals, we nemen wat JavaScript uit de foto om de gebruikerservaring te verbeteren.
Deze volgende nieuwe kenmerken verbeteren allemaal onze ontwikkeling. Met uitzondering van "step", helpt elk bij de validatie van de gebruikersinvoer.
Het vereiste kenmerk is precies zoals het klinkt. Ik, de ontwikkelaar van deze webpagina, moet u dit formulier invullen voordat u op Verzenden klikt. Dit is de standaard formuliervalidatie die we vandaag gebruiken met JavaScript. Wat een bibliotheek eerder nam om een vereist gegeven toe te voegen, neemt nu een enkel woord in het formulier.
Van alle nieuwe formulierattributen is dit degene waar ik het meest enthousiast over ben. Meneer Form, laat me u voorstellen aan mijn goede vriend, Regex. Dat klopt, we kunnen formulierinvoeringen valideren op basis van reguliere expressies. Hoewel deze in eerste instantie raadselachtig zal zijn, terwijl je reguliere expressie leert, worden de validatiemogelijkheden nu onbegrensd.
Ik heb de laatste drie samengevoegd tot één voorbeeld, omdat ze allemaal te maken hebben met nummervalidatie - of het bereik van nummers dat we kunnen opnemen.
Elk van deze heeft te maken met numerieke waarden. Verwar ze niet met de maxlength, die zich bezighoudt met het aantal karakters dat een input zal hebben. Het stapelement is precies zoals het klinkt. Terwijl u een numerieke waarde selecteert, verhoogt u deze met .5 of omlaag met .5 - dit betekent dat dit invoertype de mogelijke waarden van 1, 1.5, 2, 2.5 enzovoort heeft.
Vanaf nu is, voor zover ik weet, browser-ondersteuning enigszins vlekkerig op deze attributen. Dit is een snel overzicht van wat ik heb kunnen vinden over de implementaties.
Er zijn acht nieuwe ingangstypen, niet alle nieuwe datum- en tijdtypen meegerekend, die ik voor onze doeleinden op één plaats vind. Het is belangrijk op te merken dat de browsers die de nieuwe invoertypen niet hebben geïmplementeerd zullen degraderen tot een type tekst op elke die ik heb getest. Wat de nieuwe invoertypen opleveren, is de mogelijkheid om gebruikersinvoer te valideren op basis van het type dat u gebruikt. Er komt ook meer validatie aan de orde die ik in de volgende twee paragrafen zal bespreken. Elk van de nieuwe invoertypen stelt ons in staat om van een tekstveld te scheiden naar iets specifieks. Om bijvoorbeeld vóór of na HTML 5 gehele of zwevende waarden te gebruiken, hebben we meestal een invoertype gebruikt. Alleen al vanaf de annotatie is het intuïtief voor beginners. Door specifieker te zijn, hebben we dan een betere visuele controle over onze interface, omdat hoe specifieker het element in HTML is, hoe groter het besturingselement binnen de CSS is, en hoe eenvoudiger het is om die visuele elementen te definiëren. Met de nieuwe specifieke invoertypen kunnen browsers nu bovendien fijn afstemmen wat het invoerbereik zou moeten zijn. Eindelijk, met de komst van mobiel computergebruik, zijn we in staat webapplicatie-formulierelementen te maken die kunnen worden gestileerd om eruit te zien als natuurlijke applicaties, of het toetsenbord kunnen vormen dat we gebruiken.
Laten we eerst kijken naar nummerverwerking:
Elk van deze invoertypen stelt ons in staat om met getallen te spelen, en wanneer we de formulieren posten, moeten we zeker zijn dat we die zwevende waarden hebben voor onze serverzijdige verwerking zonder de toegevoegde JavaScript-validatie. Eenvoudig gesteld, voor elk van deze typen verwachten we dat de nummers terugkomen binnen het bereik dat we definiëren en met de stap die we willen. Het verschil tussen de twee typen is hoe ze worden weergegeven. Terwijl ik wacht om de implementatie op het nummertype te zien, zou ik een rol of een tekstvak verwachten, of misschien een type van een select-nummer. Het bereiktype is een beetje anders, in zoverre dat het een glijdende waarde lijkt, vergelijkbaar met wat je zou verwachten te zien voor een volumeregelaar.
Nog een grote opluchting om uw back-endontwikkeling te standaardiseren, zijn de nieuwe datum- en tijdinvoertypen. Van de Opera-implementatie die ik heb gezien, toont elk een kalender drop-down, waarmee uw gebruiker een datum kan selecteren. Nogmaals, we kunnen op onze webpagina bevestigen dat de invoer in het formaat is dat we verwachten. Elk doet precies wat je zou denken; u selecteert een maand, week, dag of tijd. Degene die een beetje anders is, is de datetime-local, die de datum en tijd weergeeft zonder je tijdzone-offset. Als u bijvoorbeeld een vlucht selecteert, geeft de datetime-local de tijd en datum weer in de stad waar u naartoe gaat, wat niet noodzakelijk de tijdzone is waar u zich in bevindt.
Elk van deze invoertypen is beschrijvend. De URL- en e-mailtypen hebben allebei validaties van geldige URL-patronen en geldige e-mailpatronen. De telefoon voldoet echter niet aan een specifiek patroon. Het verwijdert gewoon regeleinden. Als u een validatiepatroon op het telefoonveld wilt afdwingen, kunt u altijd het patroonelement gebruiken. Elk van deze elementen minus kleur neemt ook het lijstattribuut, minus kleur. Kleur is de vreemdeling van het stel; Ik kan het praktische gebruik ervan zien, waar je een kleur kunt selecteren uit een mooie pull-down die kleuren laat zien, en de tekstinvoer afdwingen van iets als # 000000, maar het past niet echt in de rest van de veranderingen, naar mijn mening. Het is alsof je speelt, een die niet is zoals de anderen.
Net als de kenmerken is de browser-implementatie van het invoertype vrij vlekkerig. Mijn iPhone lijkt meer van deze te ondersteunen dan Safari, wat een beetje grappig voor me is. Dit is het beste dat ik kon vinden, ter ondersteuning.
Het aantal wijzigingen in de formulierelementen is niet zo ingrijpend als invoerattributen en -typen. Dat gezegd hebbende, er zijn een paar nieuwe elementen om op te letten. We hebben datalist al behandeld - het is hoe we definiëren wat er wordt geselecteerd uit een lijstelement-aanroep - maar we hebben keygen, output, voortgang of meter niet gezien. Buiten keygen. deze zijn niet zo vanzelfsprekend als de nieuwe attributen. Laten we hier een beetje in graven.
Deze is een beetje verwarrend. Het genereert geen publieke sleutel voor u. In plaats daarvan is het een generatorregeling voor het sleutelpaar. Nadat het formulier is ingediend, verpakt het het sleutelpaar om de privésleutel in het lokale sleutelarchief op te slaan en stuurt het de openbare sleutel terug naar de server. Het genereert het clientcertificaat en biedt het weer aan de gebruiker om te downloaden. Nadat u deze hebt gedownload en opgeslagen met de persoonlijke sleutel, kunt u vervolgens services verifiëren, zoals SSL of certificaatverificatie.
+ =
Beschouw het uitvoerelement als een tekstgebied op steroïden. Wat u kunt doen, is het berekenen van twee typen tekstinvoer en deze berekening uitvoeren zonder het formulier ooit terug te sturen naar de server. Als u false false opgeeft, berekent het in het bovenstaande voorbeeld nummer_1 plus nummer_2 en geeft u het antwoord. Zoals zoveel dingen die in deze tutorial worden besproken, is dit iets dat we vandaag met JavaScript kunnen bereiken, maar dit vermindert echt de hoeveelheid code die we in de toekomst moeten schrijven.
12cm
De laatste twee nieuwe elementen zijn voortgang en meter. Ze zijn vergelijkbaar, maar met één verschil. Vooruitgang is bedoeld om de voortgang van een specifieke taak te meten. Als u bijvoorbeeld nog vijf pagina's moet voltooien voordat een enquête is voltooid, geeft u het voortgangsgedeelte in dat gebied weer. De meter is daarentegen een maat voor iets. U wilt misschien de resterende schijfruimte weergeven die een gebruiker nog heeft. U zou de meter gebruiken om die meting weer te geven. Er zijn nieuwe grenselementen, zoals laag, hoog en optimaal. Deze vervangen de min- of max-elementen; dus als ze deze overschrijden, worden ze de nieuwe onder- en bovengrenzen van de vorm.
Net als de rest van de HTML 5-formulierwijzigingen, is de implementatie van de browser op dit moment slecht. Hier is wat lijkt te werken, en wat niet (op het moment van dit schrijven).
Van wat ik kan zien, is er geen reden om HTML 5-formulieren niet te gebruiken. De invoerelementen en -typen worden allemaal goed afgebroken, zelfs in IE6, waar ze worden genegeerd als elementen of worden gedegradeerd tot tekstinvoer. We zullen nog een tijdje moeten wachten voordat de validatiekenmerken werkelijkheid worden, maar met dat gezegd, er zijn tegenwoordig nog steeds enkele toepassingen zonder die voordelen. De iPhone wijzigt bijvoorbeeld het toetsenbord als u de url-, e-mail- of nummertypen gebruikt. Het bereikinvoertype wordt al ondersteund in WebKit-browsers, dus u kunt de eerste gebruiker van het blok zijn met een getalslider die werkt zonder JavaScript. De specificatie wordt snel afgerond en browsers maken nogal snel gebruik van de paradigmaverschuivingen. Er is geen tijd als het heden om op zijn minst te beginnen met het spelen met dit nieuwe speelgoed! Wat denk je?
Accentsconagua