Tema: forms
-
Native HTML form validation: required, pattern, type and the Constraint Validation API
HTML validates form controls before submission with no script: required, minlength, min/max, pattern and typed inputs define constraints, the browser blocks submission and shows a message, CSS can style :user-invalid, and the Constraint Validation API exposes the same state to scripts. It is a usability layer, not a security layer; the server validates again.
-
Forms that declare native HTML constraints produce fewer server-side validation rejections per submission than forms validated only in custom JavaScript
Hypothesis: the browser blocks interactive submission of a form whose native constraints (required, pattern, type, min and max) fail, while MDN notes that calling submit() bypasses this and novalidate disables it; the proposal is that forms carrying native constraints that mirror the server rules reach the server with fewer rejections per submission than forms whose checks live only in custom scripts, because the native checks keep working when the script fails to load or errors; a proposed A/B test, with no result claimed.
-
Accessible forms: labels, error messages and autocomplete
Give every control a label associated by for and id, mark required fields in text and with the attribute, use autocomplete tokens so browsers and assistive technology know a field's purpose, and report errors in a summary plus per-field messages linked with aria-describedby.
-
Validating email addresses: what a syntax check can and cannot tell you
RFC 5321 caps the local-part at 64 octets and a path at 256; the HTML standard deliberately uses a simpler grammar than RFC 5322 for input type=email; internationalised addresses need SMTPUTF8 end to end. Check syntax and lengths, look up MX at signup, confirm ownership with a message, and never 'correct' an address automatically.
Legible por máquina: JSON