CSS3 formuliervalidatie

[Zoefff]

Met de komst van CSS3 zijn er een aantal fijne pseudo-selectors zoals :valid en :invalid toegevoegd die gebruikt kunnen worden om formulier validatie eenvoudiger te maken.

Het probleem waar ik tegenaan loop is dat een selector input:invalid al wordt geëvalueerd bij het openen van de pagina, nog voordat iemand content heeft kunnen toevoegen. Dat is op z'n minst een beetje cru aangezien de bezoeker niet eens de kans krijgt om valide input te geven

Ik heb me door alle documentatie die ik over (pseudo) selectors ken doorgeworsteld, maar kan geen mogelijkheden vinden om hier omheen te werken. Iets in de richting van "input[!value]:invalid", maar dit voorbeeld mag (natuurlijk) niet.

Testcase:

HTML:

<input type="text" value="" required />

Cascading Stylesheet:

input:valid {
    border: green; 
}
input:invalid {
    border: red; 
}

Nu heb ik het opgelost met een smerig regeltje javascript, maar dat doe ik eigenlijk liever niet:

JavaScript:

$('input').change(function() {
    $(this).attr('edited', 'edited');
});

Cascading Stylesheet:

input[edited]:invalid {
    border: red;
}

Gezien dit antwoord op StackOverflow schat ik m'n kansen laag in, maar wellicht is er nog iemand met suggesties?

[OkkE]

Volgens mij is daar, op dit moment, inderdaad nog geen oplossing voor. Wat op A List Apart werd voorgesteld, was om het te combineren met :focus.
.

Cascading Stylesheet:

input:focus:required:invalid {
  background-color: pink;
}
input:required:valid {
  background-color: #fff;
}

Kwam pas nog een andere website tegen waar ze het over dit probleem hadden maar die kan ik zo snel niet meer vinden...

[ Voor 14% gewijzigd door OkkE op 10-10-2011 13:35 ]

[Zoefff]

Dat artikel ben ik in m'n zoektocht inderdaad ook tegengekomen. Maar ook dat vind ik niet echt fijn voor de gebruiker. Ga je het betreffende veld invullen, krijg je allereerst een foutmelding om je oren. Niet heel vriendelijk, zeker niet motiverend

[Juup]

Kun je niet zoiets doen:

Cascading Stylesheet:

input:invalid
{
    color: red;
}
input[value=""]:invalid
{
    color: #000;
}

[Zoefff]

Daar heb ik ook al mee gespeeld, maar ik krijg het helaas niet op de juiste manier voor elkaar. Het werkt deels wel, maar het lijkt er op dat beide zaken altijd als even belangrijk wordt geëvalueerd waardoor je geen onderscheid kan maken.

In jouw opzet zou je het bijvoorbeeld zo kunnen doen:

Cascading Stylesheet:

input[value=""]:invalid {
    border: 1px solid #ccc;
}

input[value]:invalid {
    border: 1px solid red;
}

Maar dan krijgt het element nooit een rode rand, ook als ik de twee declaraties omdraai of het [value] gedeelte achterwege laat.

Het lijkt er op dat de regel die [value=""] bevat altijd wordt uitgevoerd omdat het element immers ook op die manier in de pagina staat. Bij het invoeren van data veranderd dit ook niet, en blijft de regel dus uitgevoerd worden. Zelfs als er een [value!=""] of iets in die richting mogelijk zou zijn gaat het waarschijnlijk niet helpen...

De javascript oplossing heb ik inmiddels ook maar gewoon opgenomen in de demo en me stiekem al een beetje bij het probleem neergelegd

[MoietyMe]

Je kunt wel een soort van live validatie maken en de gebruiker de tijd geven om het juiste antwoord in te vullen.

http://agosto.nl/dev/validation/

Misschien niet helemaal wat je zoekt, misschien ook wel

[geert1]

Ik vraag me ten zeerste af of formulier-validatie met CSS zou moeten worden opgelost. Wat heeft een opmaaktaal te maken met het verwerken van gebruikersgedrag? Deze nieuwe pseudoclasses zijn ook niet verfijnd genoeg om validatie netjes af te handelen volgens mij. Hierboven is al aangegeven dat je de validatie pas wilt triggeren als er foutieve invoer is gegeven en je van het veld afgaat (onblur). Of tijdens het typen misschien, maar zeker niet bij het laden van de pagina of bij het betreden van het veld. Dit soort subtiliteiten qua gedrag kunnen beter aan javascript worden overgelaten naar mijn mening. Met bijvoorbeeld jQuery zou je gemakkelijk de html5-attributen zoals "required" uit kunnen lezen. Zou sterk mijn voorkeur hebben boven een CSS-only-oplossing.

Wat nog wel kan is een combi van JS en CSS-pseudoclasses. Je kunt bijvoorbeeld met JS een class op een element plaatsen op het moment dat er iets moet gebeuren qua validatie (gedrag), en dan met de pseudoclasses de vormgeving afhandelen, in combinatie met die class.

Toch vraag ik me af met welke bedoeling deze pseudoclasses geïntroduceerd zijn. Het voelt alsof de ontwikkelaars van de CSS3-standaard dit niet helemaal hebben doordacht of afgemaakt. Maar misschien komen er ook nog nieuwe inzichten of trucs in de toekomst.

[ Voor 12% gewijzigd door geert1 op 13-10-2011 11:25 ]

[OkkE]

Het hele idee met HTML5 is dat de browser zelf de validatie gaat doen in plaats van Javascript, dan wil je ook via CSS de styling er van regelen. Op dit moment werkt het inderdaad nog niet optimaal, maar dat ligt meer aan de manier hoe browsers nu omgaan met validatie dan met de CSS-standaard.

Ik moet eerlijk zeggen dat ik de oplossing uit mijn post helemaal niet slecht vind. Niet in alle gevallen is het bruikbaar misschien, maar de direct on focus feedback vind ik vaak prima. Waarom zou een gebruiker eerst uit het veld moeten gaan voor hij die feedback krijgt?

[Bosmonster]

geert1 schreef op donderdag 13 oktober 2011 @ 11:22:
Ik vraag me ten zeerste af of formulier-validatie met CSS zou moeten worden opgelost.

Dit. Het hele idee van validatie in de html5 standaard verwerken is gekkenwerk. Dit is niet iets dat door de opmaaktaal geregeld dient te worden.

Daarnaast ben je dan afhankelijk van crossbrowser implementaties, waar je in dit soort gevallen absoluut niet afhankelijk van wilt zijn. Je wilt niet dat mensen door een browser-bug ineens geen e-mailadres meer in kunnen vullen oid.

M.a.w. html5-validatie gewoon lekker links laten liggen. Extra veldtypen en controls zijn welkom, maar blocking-validatie moeten ze gewoon vanaf blijven. Je kunt in html nooit de logica weergeven die je nodig hebt. Daar heb je een taal voor zoals javascript.

Zo heb je ook het probleem dat je velden die onzichtbaar zijn ook gevalideerd worden, terwijl je die pas wilt valideren als ze zichtbaar worden bijvoorbeeld. Validatie kun je vooralsnog niet aan/uitzetten, of je hebt weer alsnog javascript nodig, etc. Het wordt een zooitje wat ze nu aan het proberen zijn.

Waarom zou een gebruiker eerst uit het veld moeten gaan voor hij die feedback krijgt?

Omdat je mensen niet wilt straffen met een foutmelding op het moment dat ze nog moeten beginnen met invullen

[ Voor 36% gewijzigd door Bosmonster op 13-10-2011 13:07 ]

[OkkE]

Bosmonster schreef op donderdag 13 oktober 2011 @ 13:00:
Dit. Het hele idee van validatie in de html5 standaard verwerken is gekkenwerk. Dit is niet iets dat door de opmaaktaal geregeld dient te worden.

Je kunt je inderdaad afvragen of dit niet te veel behavior is voor een opmaak taal. Aan de andere kant; ik denk dat browsers een hoop validaties beter en sneller kunnen dan Javascript. En back-end validatie moet je sowieso blijven doen.

Daarnaast ben je dan afhankelijk van crossbrowser implementaties, waar je in dit soort gevallen absoluut niet afhankelijk van wilt zijn. Je wilt niet dat mensen door een browser-bug ineens geen e-mailadres meer in kunnen vullen oid.

Dit vind ik een zwak argument. Er is nu ook kans op CSS bugs waardoor een link niet klikbaar is, een element niet zichtbaar is. Ook Javascript heeft zo zijn bugs.

M.a.w. html5-validatie gewoon lekker links laten liggen. Extra veldtypen en controls zijn welkom, maar blocking-validatie moeten ze gewoon vanaf blijven. Je kunt in html nooit de logica weergeven die je nodig hebt. Daar heb je een taal voor zoals javascript.

Ik geef toe dat de HTML5/CSS3 validatie niet in elke situatie een vervanger kan zijn voor Javascript validatie. Maar om het nu direct als overbodig/onzin af te doen, gaat mij ook wat te ver.

Laten we type=email als voorbeeld nemen. Jij weet ook wat voor bijna onmogelijke regEx er nodig is in Javascript, om op alle mogelijke opties te checken. Ik denk dat een browser dat (iig in theorie) een stuk beter kan; plus de browser update, bijvoorbeeld wanneer de regels veranderen (éâï toelaten).

Zo heb je ook het probleem dat je velden die onzichtbaar zijn ook gevalideerd worden, terwijl je die pas wilt valideren als ze zichtbaar worden bijvoorbeeld. Validatie kun je vooralsnog niet aan/uitzetten, of je hebt weer alsnog javascript nodig, etc. Het wordt een zooitje wat ze nu aan het proberen zijn.

Het is inderdaad niet in elke situatie perfect, misschien wordt het nooit perfect. Maar ik zie zeker wel potentie in HTML5/CSS3 validatie. Dingen die je met Javascript toont, kun je met Javascript dan ook van rules/required/etc voorzien; niet altijd uiteraard, wel in sommige gevallen.

Omdat je mensen niet wilt straffen met een foutmelding op het moment dat ze nog moeten beginnen met invullen

Foutmelding is natuurlijk een ruim begrip. Een lichtroze background of een andere kleur border / font vind ik niet zo zeer een foutmelding als meer een aanwijzing. Het is niet in elke situatie geschikt, maar voor sommige wel.

Het zou wel netjes zijn als browsers het aanpassen, dat die :invalid pas iets doet bij onBlur. Misschien is het een "bug" misschien ook "working as intended". Who know.

[Bosmonster]

Laten we type=email als voorbeeld nemen. Jij weet ook wat voor bijna onmogelijke regEx er nodig is in Javascript, om op alle mogelijke opties te checken. Ik denk dat een browser dat (iig in theorie) een stuk beter kan; plus de browser update, bijvoorbeeld wanneer de regels veranderen (éâï toelaten).

Dat is dus precies een mooi voorbeeld van het probleem. Nu worden dat soort tekens niet toegelaten... De browser gaat dus de regels bepalen ipv de developer. Zolang er 1% gebruikers met een brakke browser rondsurfen, met een dergelijke bug (op zn minst de komende 10 jaar+ dus zeg maar) blijven dat soort dingen onbruikbaar.

Het zou wel netjes zijn als browsers het aanpassen, dat die :invalid pas iets doet bij onBlur. Misschien is het een "bug" misschien ook "working as intended". Who know.

Working as intended.

Het is overigens ook niet dat ik niet zou willen dat er meer velden en controls bijkomen, waarin ook bepaalde restricties kunnen worden gebouwd. Zoals een number-field, e-mailfield of slider, etc.

Het gaat om het feit dat de werkelijke validatie en het feit of het formulier wordt gesubmit of niet door de opmaak wordt bepaald, wat redelijk absurd is. Dit is behavior-logica die niet daar thuishoort.

[Zoefff]

De discussie is interessant, maar geeft a) geen antwoord op mijn vragen en b) ik geef ook nergens aan dat ik de HTML5 mechanismen als werkelijke validatie van de formulieren wil gebruiken?

Het enige wat ik wil is de styling aanpassen aan de hand van de status van de input velden. Of deze status nu door de browser op :invalid wordt gezet of dat ik dat zelf met javascript doe, doet er volgens mij niet zo veel toe in de probleemstelling.

Los daarvan denk ik wel dat je als ontwikkelaar ook de handvaten moet aanpakken die in b.v. HTML5 worden aangeboden. De uitgebreide set aan validatie mogelijkheden en extra controls zijn prima te gebruiken voor een basis van je totale validatie van het formulier. Zeker als je weet dat je hier gebruik van kan maken (denk aan iOS, Android platformen), maar ook in combinatie met een nette cross-browser afhandeling waarbij je de javascript oplossing zodanig kan aanpassen dat deze inspringt voor browsers die minder van de HTML5 basis kunnen afhandelen.

[OkkE]

Bosmonster schreef op donderdag 13 oktober 2011 @ 14:29:
Dat is dus precies een mooi voorbeeld van het probleem. Nu worden dat soort tekens niet toegelaten... De browser gaat dus de regels bepalen ipv de developer. Zolang er 1% gebruikers met een brakke browser rondsurfen, met een dergelijke bug (op zn minst de komende 10 jaar+ dus zeg maar) blijven dat soort dingen onbruikbaar.

Klopt, het type=email kan problemen opleveren met mensen die niet updaten (en in de praktijk gebeurd dat helaas).

Het gaat om het feit dat de werkelijke validatie en het feit of het formulier wordt gesubmit of niet door de opmaak wordt bepaald, wat redelijk absurd is. Dit is behavior-logica die niet daar thuishoort.

Of validatie door HTML5 moet gebeuren of door Javascript, dat is denk ik niet zo zwart/wit; ik vind ieder geval niet dat we de browser voor alle validatie altijd moeten afschrijven. Dat een formulier niet submit als de input niet klopt, is soms onhandig inderdaad. Een attribuut als no-validate is misschien handig; de nieuwe url en email types hebben tenslotte wel toegevoegde waarde, o.a. op mobile.

Zoefff schreef op donderdag 13 oktober 2011 @ 15:43:
De discussie is interessant, maar geeft a) geen antwoord op mijn vragen en b) ik geef ook nergens aan dat ik de HTML5 mechanismen als werkelijke validatie van de formulieren wil gebruiken?

Het enige wat ik wil is de styling aanpassen aan de hand van de status van de input velden. Of deze status nu door de browser op :invalid wordt gezet of dat ik dat zelf met javascript doe, doet er volgens mij niet zo veel toe in de probleemstelling.

Ik denk dat je al antwoord hebt op je vraag: als je alleen CSS gebruikt kan je niet voorkomen dat de input direct onFocus al die :invalid stijl krijgt. Je zal dus Javascript moeten gebruiken om pas een stijl toe te voegen wanneer er iets in de input is ingevuld.

[Bosmonster]

Wat je eventueel nog kunt doen is zodra een element van het formulier wordt gefocused een class aan dat formulier hangen. Dan kun je die in je css gebruiken om te zorgen dat foutmeldingen pas getoond worden als er op z'n minst een veld is gefocused.

[ Voor 3% gewijzigd door Bosmonster op 13-10-2011 23:37 ]

[Zoefff]

Als je het voor focus only doet kan het ook nog wel met input:focus:invalid, maar zoals ik in m'n startpost aangeef heb ik een soortgelijke oplossing gekozen waarbij de foutmelding pas getoond wordt al een veld veranderd (onBlur dus). Doet vooralsnog z'n ding goed, al ben ik stiekem een beetje teleurgesteld dat ik de styling niet met alleen CSS kan doen.

Gelukkig heeft CSS al wel eerder voor teleurstellingen gezorgd, ik ben er inmiddels aan gewend

[Bosmonster]

Misschien omdat je een experimentele feature aan het gebruiken bent die nog helemaal niet af is

[ Voor 127% gewijzigd door Bosmonster op 13-10-2011 23:48 . Reden: Maar wat ingekort ]

[Zoefff]

Hehe, point taken

[mcDavid]

Volgens mij is de :invalid minder nuttig dan de :valid selector.

Die laatste kun je gebruiken om bijv. een vinkje achter een goed-ingevulde input te zetten. Dat is veel vriendelijker dan gelijk foutmeldingen strooien. De echte validatie doe je pas bij de submit, dan pas maak je velden die niet goed zijn rood of whatever.