Jan Mikoláš
Glossary
Web form
A form turns user intent into a structured application request. A well-designed form is understandable, works with a keyboard, and does not mistake the convenience of client-side validation for server-side data protection.
Short definition
A set of controls for entering and securely submitting data.
The foundation is a form element containing controls such as input, select, textarea, and button. Each field should have a meaningful name, value, and visible label. On submission, the browser creates an HTTP request according to the action and method attributes; the application receives the data and decides whether to accept it, reject it, or ask for a correction.
A form is neither merely a graphical panel nor only a JavaScript component. Native HTML provides familiar keyboard controls, autofill, and basic validation. This layer improves usability, but the server must always verify validity, CSRF protection, user identity, and permission to perform the action.
The problem it solves
It collects data and turns it into an unambiguous application action.
Forms are used for everything from search to sensitive account changes. Their design affects error rates, security, and whether users can return to work in progress.
- sign-in, registration, password changes, and user account settings
- an e-commerce order: contact information, address, shipping, payment, and acceptance of terms
- filtering a list of orders or products through URL parameters
- administration of products, inventory movements, and permissions in an internal system
- uploading an attachment, submitting a support request, and confirming an irreversible action
Practical example
An email field with a label and an error connected for assistive technologies
The label remains visible after the field is filled, so users know what value it expects. The error is textual, has its own identifier, and the aria-describedby attribute connects it to the input. The required attribute provides native guidance, but the server must check the email again and must not return technical details to users.
In production, the server also inserts a CSRF token into a hidden field. It is neither a secret intended for the URL nor a replacement for authorization: it protects a stateful browser request against forgery from another website.
HTML
<form action="/checkout/contact" method="post">
<input type="hidden" name="_token" value="{csrf-token-ze-serveru}">
<label for="email">E-mail pro potvrzení objednávky</label>
<input id="email" name="email" type="email" required
aria-describedby="email-error">
<p id="email-error" role="alert">Zadejte e-mail ve správném tvaru.</p>
<button type="submit">Pokračovat k dopravě</button>
</form>How it works
From an entered value to a confirmed change on the server
The client can provide immediate help with data entry, but the server retains the decision to accept the data.
- The user recognises the field’s purpose A label, guidance, a suitable input type, and logical order explain which value the form expects. A placeholder can add an example but should never be the only label.
- The browser constructs a request On submission, it transfers name and value pairs. GET is suitable for shareable, safe filtering; POST is generally used for state changes or information that should not form part of the URL.
- The server verifies the context It first checks the session or token, CSRF protection, permissions, and expected tenant. A value from the form never proves who may perform the action.
- The server validates the data It checks types, ranges, required values, relationships to other data, and business rules. A client-side check can be bypassed or may not run at all.
- The application returns the result On success, it confirms the next step or redirects to a safe URL. On error, it preserves safe values, identifies the problem beside the relevant field, and does not communicate the error through colour alone.
Important related concepts
Each form feature serves a different purpose.
A comprehensible form distinguishes technical request parameters, input guidance, and protective controls.
Label and placeholder
A label names a control and remains available. A placeholder is brief supplementary guidance that disappears during typing and may not have sufficient contrast.
GET and POST
GET puts parameters in the URL and is suitable for searches or filters. POST carries data in the request body and is used for changes, although by itself it does not hide sensitive information from the server.
Client-side and server-side validation
The browser can flag a missing field sooner. Only the server, however, validates untrusted data against current rules, concurrency, and permissions.
Disabled and readonly
A readonly field can generally be submitted, while a disabled field is normally excluded from form data. Neither attribute is a security control; a request can be constructed manually.
Idempotency and duplicate submission
For an order or payment, the design must anticipate a double-click, page refresh, and network retry. The button can be visually disabled during submission, but the server contract must prevent actual duplication.
Benefits and limitations
Good forms reduce errors but do not remove the need for server-side rules.
Benefits
- native HTML gives users and browsers predictable controls
- clear labels and errors shorten the path to correcting values
- progressive enhancement provides a functional foundation without JavaScript
- a unified server flow simplifies security checks and action audits
Risks and common mistakes
- using a placeholder as the only label or showing an error only in red
- relying on HTML required or JavaScript as the only validation
- using GET for sensitive data, tokens, or changes to business state
- an empty error message with no connection to the field and no focus movement to the problem
- trusting a disabled field, an upload MIME type, or a client-supplied tenant ID
Practical use
Placing an order should be quick but controlled.
In checkout, extensive data should be divided into comprehensible steps: contact, delivery, payment, and order review. Each step needs a clear name, must preserve safe values already entered, and should explain what needs correction after an error. The price, currency, and shipping summary is ultimately recalculated on the server, not taken from values sent by the browser.
Background submission, automatic draft saving, or a confirmation dialog may be useful in an internal administration interface. These layers must not remove standard submission, a clear action state, or protection against duplicate saves. A sensitive change needs server-side authorization for the object, even if the user can see the form in the interface.
What to consider
A checklist for a form that protects both users and data.
Testing should cover an ordinary browser, keyboard-only operation, and an unsuccessful server response.
- associate every input with a visible label and a meaningful name
- display a textual error beside the specific field and identify it for assistive technologies
- validate types, ranges, business rules, the CSRF token, and permissions on the server
- do not put tokens, passwords, or personal data in the query string or ordinary logs
- test Tab, Enter, visible focus, zoom, mobile width, duplicate submission, and network errors
Common questions
Web forms in practice
Does a placeholder replace a form label?
No. A placeholder disappears after entry, may have low contrast, and does not reliably name a field. Use a visible label and a placeholder only for a brief example.
When should I choose GET and when POST?
GET is suitable for safe, shareable filters and searches. POST is suitable for state changes. Sensitive data does not belong in a URL even when using POST; the server must protect transport with HTTPS and handle data correctly.
Is validation in JavaScript enough?
No. JavaScript improves convenience, but it can be disabled or the request sent by another client. The server always validates again, and only it can decide safely whether to write the data.
Is a disabled field a security control?
No. Disabled affects browser controls and the field is usually not submitted. An attacker can construct a custom request, so permissions and permitted values must be checked on the server.
How I approach user flows in practice
I design forms as part of a secure and comprehensible user journey.
In e-commerce and internal systems, I connect an accessible interface with validation, authorization, and reliable server-side processing of changes.