Nu HTML5 eindelijk een beetje op stoom lijkt te komen en na het zien van enkele technische voorbeelden van wat er allemaal kan met HTML5 besloten we om ons eens te verdiepen in wat er wij er praktisch mee kunnen.

Hype

De HTML5 hype is vooral gericht op het nieuwe video element wat het voor bijvoorbeeld Youtube mogelijk maakt om zich eindelijk los te maken van de gesloten "standaard" Flash om filmpjes af te kunnen spelen. Dit juichen wij van harte toe. Ook gaat er veel aandacht uit naar het toch al langer bestaande, maar nu eindelijk gestandaardiseerde, canvas element waar we zelf ook al dankbaar gebruik van hebben gemaakt voor enkele projecten.

Formulieren

Maar gezien we met name de laatste tijd steeds meer projecten hebben waar inschrijvings- en registratieprocedures een belangrijke rol spelen hebben we vooral gekeken naar de nieuwe mogelijkheden voor wat betreft formulieren en invoerelementen. Dit is een onderbelicht maar toch zeer belangrijk aspect van de nieuwe standaard.

Als we de nieuwe mogelijkheden in kort zouden moeten samenvatten komt dat neer op het volgende: formulieren worden normaal gesproken op geldige invoer gecontroleerd nadat men het heeft ingediend. Gaat er iets mis dan wordt het formulier opnieuw getoond met de foutieve invoer aangestipt en de vraag de fout te verbeteren.  Maar het zou voor het gebruiksgemak veel beter zijn om direct bij het invoeren van verkeerde gegevens feedback te geven dat het zojuist ingevoerde gegeven onjuist is.

Soms wordt dit met wat zelfgemaakte Javascript geregeld, maar het nadeel daarvan is dat er geen standaardmanier is om deze verkeerde invoer aan te duiden. Ook zijn er mensen die Javascript blokkeren of uitgeschakeld hebben. En als laatste kan Javascript problemen opleveren met screenreaders (computerprogramma's die de tekst op het scherm voorlezen); die raken vaak in de war als er ineens iets verandert op een pagina.

Met HTML 5 wordt het mogelijk om bij het invoerelement zelf al aan te geven wat de toegestane invoer is en of het veld verplicht is of niet. Het is vervolgens aan de webbrowser om het op een duidelijke en toepasselijke manier aan de gebruiker te melden wanneer deze iets niet of onjuist invoert.

De test

Om deze mogelijkheden te evalueren hebben we een testpagina gemaakt waar een profiel wordt gevraagd voor een denkbeeldige website.  We hebben zo'n beetje de volledige mogelijkheden van HTML5 voor formulieren gebruikt; zo wordt er voor het zoekveld een zogeheten autocomplete gebruikt welke uit een gegeven lijst met opties de invoer van de gebruiker aanvult. Bij de adresgegevens hebben we spellingscontrole aan- en uitgezet voor specifieke velden.  Ook zijn hier alle velden behalve het tussenvoegsel verplicht gesteld. Bij de contactgegevens hebben we specifieke veldtypes voor e-mail, telefoonnummers en URLs gebruikt met een invoerpatroon wat aangeeft wat voor tekens er in telefoonnummers zijn toegestaan (en het moet beginnen met +31 en dan een spatie).

Als laatste hebben we onder "overig" de meer exotische veldtypen gebruikt zoals een datumveld, een "range"-veld waar men een bereik tussen een minimum- en een maximumwaarde kan invoeren op een onprecieze manier en zelfs een kleurwaardeveld waar je een kleurenmenger zou moeten krijgen.

De resultaten

Deze test hebben we vervolgens met de 5 grootste browsers (Firefox 3.6.3, de Webkit nightly build van 15-06-2010, Google Chrome 5.0.375, Opera 10.60b1 en Internet Explorer 8) bezocht en gekeken wat ze ervan bakken. Niet zo heel veel, blijkt helaas!

Firefox

Over Firefox zijn we over het algemeen redelijk enthousiast en daar hadden we dus ook hoge verwachtingen van. Maar helaas... Firefox doet helemaal niets met de nieuwe invoerelementen. Het enige waar deze wel naar kijkt is het spellcheck attribuut waarmee je kunt aangeven of een veld wel of niet een spellingscontrole behoeft. Zelfs met het relatief simpele autofocus attribuut werd door deze browser niets gedaan.

Het gedrag van Firefox in de test is overigens identiek onder Windows, Mac OS X en NetBSD.

Voor de volledigheid hebben we ook nog even een nightly build van Firefox (versie "3.7a6pre") geprobeerd. Daar kregen we hetzelfde resultaat met als uitzondering dat de autofocus nu wel gehonoreerd werd. Vooruitgang!

Internet Explorer

We wilden eigenlijk testen met de preview-versie van IE9 maar deze draait alleen op Vista of Windows 7 en we hadden bij Solide even geen behoefte om enkele honderden euro's op te hoesten om onze Windows-XP testbakken op te waarderen naar een nieuwe Windows zodat we deze nieuwe browser konden uitproberen.

We weten het, XP is oud en binnenkort end-of-life, maar we houden deze testbakken eigenlijk alleen maar aan vanwege IE6 en IE7 omdat die helaas nog steeds door veel van onze klanten gebruikt worden. Er gebruikt hier op dit moment niemand meer Windows.

We hebben het voor de vorm nog maar even getest in IE8, maar die voldeed volledig aan onze verwachtingen: alle nieuwe elementen en attributen worden volkomen genegeerd.

Webkit nightly

Het Webkit project (de "rendering engine" achter o.a. Chrome en Safari) bouwt iedere nacht snapshots die je makkelijk kunt downloaden en direct draaien zonder enige problemen.

Helaas was in webkit nightly de HTML rendering zo brak dat er helemaal niets getoond werd van ons formulier. Je zou denken dat dit is omdat het een onstabiele snapshot betreft, maar we kregen hetzelfde resultaat in Safari 5.0 onder Windows.

Chrome

Google's Chrome gebruikt ook de webkit engine, maar blijkbaar wordt er door Google iets meer aan kwaliteitscontrole gedaan, want hier kregen we gelukkig wel iets te zien van het formulier.

Visueel valt ons meteen iets op: er wordt een schuifbalk getoond voor het "gewicht" veld.  Ter herinnering: we hadden dit gedefinieerd als een "range" veld (met een minimumwaarde van 50 en een maximumwaarde van 200, en een ingestelde granulariteit van 5 kg per stap puur voor de test).  We kunnen schuiven aan de balk maar we krijgen totaal geen feedback wat de waarde nou is

In de standaard staan twee voorbeeldplaatjes van hoe een browser een range veld zou kunnen visualiseren, en in de tekst wordt ook duidelijk dat dit een veld is voor waardes waar precisie niet erg belangrijk is. Maar dit betekent niet dat je helemaal niet hoeft aan te geven wat voor een waarde je invoert!

Als we het formulier verder niet invullen en proberen op te slaan springt de cursor naar het "voornaam" veld.  Dit blijkt Chrome's manier te zijn om aan te geven dat dit een verplicht veld is wat we niet hebben ingevuld.  Zinvolle feedback?  Ho maar.

Vullen we dit veld wel in en klikken we op opslaan, dan springt hij naar "achternaam" ("tussenvoegsel" was niet verplicht). Zo gingen we een tijdje door totdat we bij email aankwamen.  Hier zit ook een controle op het formaat dus "123abc" zou niet zijn toegestaan.  Dit klopt, als we dat invullen en op opslaan klikken springt de cursor naar dat veld.  Ook hier totaal geen feedback waarom hij dit doet. Blijkbaar moet een email adres een @ bevatten, dus we maken er een echt adres van en gaan door.  Bij telefoonnummer
honoreert hij onze validatie op het formaat (+31, spatie en dan alleen cijfers, koppeltekens of spaties) op dezelfde manier; foutieve invoer wordt afgestraft door naar het veld te springen... Bij het veld website vereist hij een volledig juiste URL, dus "www.netbsd.org" wordt niet geaccepteerd, maar "http://www.netbsd.org" wel.  Leg dat maar eens uit aan een gemiddelde gebruiker.

Bij geboortedatum wordt het pas echt leuk. Daar zit een validatie op dat de datum voor 2000 moet liggen.  Maar vullen we netjes iets realistisch zoals "01-01-1990" in, en klikken we op opslaan, dan springt de cursor weer doodleuk naar dit veld. Na ons even achter de oren te hebben gekrabd denken we dat hij het misschien anders wil ingegeven te hebben. We proberen "01/01/1990". Nee, dat klopt ook niet. "01 01 1990" dan?  Ook niet!  "1 januari 1990" dan?  Nee hoor, Chrome blijft stoïcijns de cursor in dit invoervlak plaatsen.

Wat blijkt? Hij wil het per sé in ISO-formaat hebben: "1990-01-01". Dit waarschijnlijk omdat de andere volgorde ambigu is; Amerikanen schrijven de maand eerst gevolgd door de dag en het jaar terwijl we hier in Nederland de dag eerst schrijven en dan de maand. Allemaal leuk en aardig, maar geen hond die zijn datums zo schrijft.

Het "aantal kinderen" veld wordt verder goed gecontroleerd op ongeldige invoer, maar ook bij "kleur haar" verzanden we weer in een worsteling met de browser.  We probeerden vanalles: "blond", "grijs", "pimpelpaars" maar geen enkele van onze invoer werd geaccepteerd.  Logisch ook, want de toegestane invoer bestaat uit CSS kleurcodes. Leg dat maar eens uit aan je oma van 80 die ook eens wil proberen om via internet een bolletje bordeauxrood maroon #800000 breigaren te bestellen.

Opera

We hebben het beste voor het laatst bewaard. Opera is een snelle, goede browser die een kleine maar trouwe schare fans heeft. Desondanks lopen zij qua technologie opmerkelijk vaak voorop. Zo was de alom geroemde tabinterface voor het eerst te vinden in Opera en ook waren ze een van de eersten met goede CSS ondersteuning toen deze standaard pas uitkwam.  Het verbaast ons dus ook niets dat ze ook bij HTML5 er als de kippen bij zijn.

De laatste releaseversie (10.53) heeft zelfs al basale ondersteuning voor HTML 5, maar we hebben getest met laatste beta-versie (10.60b1). Veel verschil zit daar overigens niet in.

In de screenshot valt goed te zien dat Opera met het datumveld iets speciaals doet: als je er op klikt krijg je een kalendertje voor je neus waarin zelfs ongeldige datums grijs worden weergegeven. Je kunt er ook niet op klikken. Dit is een voorbeeld van hoe het wel moet! Als dit in andere browsers wordt overgenomen kunnen al die net-niet-helemaal javascript implementaties van kalenders de prullenmand in. Hier worden wij erg blij van

Als we vervolgens iets verkeerds invullen in een van de andere velden gebeurt er eerst niets. Dit is wel verwarrend. Pas als je op "opslaan" drukt wordt het formulier gevalideerd en worden fouten een voor een afgehandeld. Zo wordt bij een ongeldig e-mailadres het veld rood knipperend opgelicht en verschijnt er een vlak met uitleg:

Het ziet er niet uit, maar het is wel nuttig en informatief. Gemiste kans is wel het oplichten van alle foutief ingevulde velden. In plaats daarvan wordt van boven naar beneden gecontroleerd en bij het eerste het beste veld wat foutief is ingevoerd krijg je zo'n melding. Vul je dat veld in en klik je opnieuw op "opslaan", dan wordt weer alles van voor naar achter gecontroleerd en wordt het volgende foutief ingevulde veld aangeduid. Zo ben je wel even bezig met het invullen van zo'n formulier...

Een andere gemiste kans is feedback bij de schuifbalk voor het "gewicht" invulveld. Hier geldt dezelfde kritiek als we bij Chrome gaven; het is een goed begin maar het kan beter.

Wel goed vinden we de "spin control" die getoond wordt bij het "aantal kinderen" veld; je kunt met de pijltjes omhoog en omlaag het getal ophogen en verlagen tot de minimum- en maximumwaardes en niet verder. Dit zorgt, samen met het kalendertje en zelfs de gewicht schuifbalk dat het formulier hufterproof is geworden; het is onmogelijk om een verkeerde waarde in te vullen.

Helaas zit er voor de haarkleur ook hier geen kleurkiezer in. Sterker nog, hij voert helemaal geen validatie uit. Zo konden we "pimpelpaars" gewoon ingeven en naar de server versturen.

Bij een browser met zo'n uitgebreide ondersteuning hadden we eigenlijk ook een visuele indicatie van "verplichtheid" verwacht. In dit formulier is het niet van te voren te zien welke velden vereist zijn en welke niet. Nou is dit wel te regelen met wat extra opmaak of styling op het verplichte veld zelf (want het is nog steeds niet mogelijk met CSS een rood sterretje te zetten achter het label wat hoort bij een verplicht veld!), maar dat zou eigenlijk ook in de browser gedaan kunnen worden (eventueel in de "user agent style sheet"; een aan te passen standaard waarde voor de CSS).

Conclusie

Er zijn maar weinig browsers die HTML 5 ondersteuning hebben en waar er wel ondersteuning is kan de usability nog flink wat verbeteringen gebruiken. De manier waarop foute invoer wordt aangeduid is zeer onbeholpen en onduidelijk en wordt er niet eens aangegeven wat voor vorm de invoer verwacht wordt te hebben. De browsermakers kunnen hier nog veel leren van Opera.

Er is dus helaas nog een lange weg te gaan voordat HTML5 formulieren praktisch bruikbaar zijn. Tot die tijd houden we het maar bij Javascript-validatie en validatie op de server.