Het gebruik van de maxlength attribute
Ik heb een eigen contactformulier en om gebruikers geen overbodige info te laten invoeren, maak ik voor mijn inputs gebruik van de maxlength attribute. Alles wordt ook in een database opgeslagen, dat is mede de reden van deze restrictie. Ik weet overigens dat bots dit omzeilen.
Voor een wachtwoord- of datumveld zou een maxlength handig kunnen zijn, maar ik vraag me nu af of het voor de overige inputs überhaupt zinvol is.. ik twijfel nu. Graag jullie mening?
Groeten, Guido
Een datumveld laat je iemand idealiter niet handmatig invullen, ik zou dan gebruik maken van een datepicker ofzo. Als je niet wilt dat iemand fouten kan maken, geef hem/haar daartoe dan ook niet de gelegenheid.
maxlength gaat volgens mij, correct me if I'm wrong, over het aantal karakters, maar een karakter kan bestaan uit meerdere bytes. Ik zou dus theoretisch karakters in kunnen voeren die 4x de toegestane (geheugen)lengte hebben. En dit kan dan weer van invloed zijn hoeveel informatie je kwijt kunt in een database-kolom.
En dan tellen browsers ook verschillend. Dit artikel heb ik snel gevonden, verder niet gecontroleerd, en is inmiddels wat gedateerd, wellicht is dit inmiddels al gerepareerd/achterhaald.
Voorlopige conclusie: met maxlength kun je een indicatie geven hoe lang invoer mag zijn, maar hoe lang de invoer dan daadwerkelijk is kan (sterk) variëren en mogelijk de maxlength overstijgen.
Ik zou dit ook per invoerveld bekijken. Als er logische restricties zijn (couponcode, getal tussen 0 en 100 et cetera) dan is een maxlength zeker op zijn plaats.
Gewijzigd op 03/04/2019 17:43:43 door Thomas van den Heuvel
Bedankt voor je reactie.
Ik heb reguliere inputs, zoals naam, e-mailadres, onderwerp, etc.
Jaren geleden had ik het idee dat het geen kwaad kon om wat restricties te geven voor deze inputs, maar ondertussen twijfel ik zelf dus ook erg aan het nut ervan, in deze gevallen dan.
Voor datum gebruik ik idd een datepicker, maar dacht dat dit icm maxlength=10 (dd-mm-jaar) geen kwaad kan.
Guido
Guido - op 03/04/2019 18:27:51:
Voor datum gebruik ik idd een datepicker, maar dacht dat dit icm maxlength=10 (dd-mm-jaar) geen kwaad kan.
Meh, dat (vaste) patroon impliceert ook een (vaste) lengte. Ik zou dan eerder kijken of het patroon voldoet. Ik hoop trouwens dat je het opslaat als yyyy-mm-dd, en niet als dd-mm-yyyy :).
Guido - op 03/04/2019 17:21:31:
Voor een wachtwoord- of datumveld zou een maxlength handig kunnen zijn, maar ik vraag me nu af of het voor de overige inputs überhaupt zinvol is.. ik twijfel nu. Graag jullie mening?
Huh, bedoel je dit nu andersom: "voor een wachtwoord- of datumveld GEEN maxlength"? Of bedoel je werkelijk dat je voor bijvoorbeeld een naam of e-mail veld de noodzaak van een maxlength niet ziet? Juist bij echt vrije velden (naam, adres, e-mail) is het handig om de gebruiker te laten weten hoeveel ruimte ie heeft. Zeker omdat in de huidige opmaak vaak alle velden even breed zijn (maar niet in de database).
En dan controleer je dit nog een keer server-side (voor de browser die verkeert telt, of voor de bot die je probeert te foppen). Pas als alles correct is sla je het op, en als het niet past geef je feedback en laat je het de gebruiker aanpassen (in plaats van maar gewoon de database de "rest" er af te laten trimmen).
Rob, ik maak hieruit op dat je het dus wél zinvol vindt om een maxlength op "vrije velden" te zetten?
Guido
Wat je hooguit nog zou kunnen doen is de maxlength weglaten, maar zelf via javascript een lengte check doen (en dan dus een melding of andere terugkoppeling als de invoer te lang wordt). Dat geeft de gebruiker de kans om toch even door te typen, en dan ergens anders (bijvoorbeeld aan het begin) te gaan schrappen (zoals Twitter dat bijvoorbeeld doet).
Mijn hoofdreden is dat er niet (te) veel content (tekst) wordt gestuurd naar de DB, maar door de maxlength vang ik dat natuurlijk niet geheel af. Ik zou daarom een combinatie van een maxlength en mb_substr kunnen gebruiken. En dan een hele ruime waarde nemen zodat alleen extreme invoer afgevangen wordt. Dus dat de gemiddelde gebruiker er helemaal niets van merkt. Iedereen blij.. dacht ik zo. Idee?
Guido
En wat neem je dan "heel ruim", die mb_substr of die maxlength? En waarom^2: waarom zou je die twee laten verschillen? De limiet is de limiet. Daar kun je maar beter meteen duidelijk in zijn.
Er is weinig op tegen om tekst die je alleen zelf gebruikt op te slaan in een VARCHAR(255). Dat verandert wanneer je moet aanwerken tegen de API's en andere systemen van derden: dan kun je ineens aanlopen tegen limieten die uit de lucht lijken gegrepen, zoals 95 karakters voor een straatnaam en 24 karakters voor een plaatsnaam.
Bedankt voor het meedenken.
Besloten om een ruime maxlength te gebruiken zodat er geen hele blokken tekst door gebruikers vh formulier gestuurd (kunnen) worden. Gebruik van mb_substr ga ik niet doen, kan bovendien tot verwarring leiden (afgekapte tekst). Wou dat in eerste instantie alleen gebruiken om content van bots af te kappen na een x aantal karakters.
Guido