Session 8: Forms, Validation & Dynamic UI

Before writing a line of JavaScript, use what HTML gives you for free. The `required` attribute makes a field mandatory. `type="email"` checks for a plausible email address. `minlength` and `maxlength` bound the length, `min` and `max` bound numbers, and `pattern` accepts a regular expression for anything more specific. The browser then blocks submission and shows a message, in the user's own language, with no code from you.

This is not a shortcut — it is the correct first layer. Built-in validation works with assistive technology, works without JavaScript, and is consistent with what people already know from every other form on the web. Writing custom validation instead of using these attributes means rebuilding something that already exists and doing it worse.

Then know its limit: client-side validation is for the user's convenience, not for security. Anything a browser enforces can be bypassed by anyone who wants to bypass it, because it runs on their machine. Real validation must also happen on the server, wherever the data goes. Client-side validation makes the experience good; server-side validation makes the data safe. They are not alternatives.

Custom validation exists for cases HTML cannot express — 'the two passwords must match', 'this date must be after that one', 'at least one of these must be filled'. The structure is a function that takes a value and returns either nothing or a message, called at the right moment, with the message displayed next to the field.

When to validate matters more than the logic. Validating on every keystroke shouts at someone halfway through typing an email address — '@' is invalid until they finish. The pattern that works is to validate on blur (when they leave the field) and then re-validate on input once a field has been flagged, so the error clears the moment it is fixed. And never validate on page load, which greets people with a wall of red before they have typed anything.

Then the submit path: prevent the default, validate everything, and if anything fails, focus the first invalid field so a keyboard or screen reader user is taken to it rather than left to find it. Announce the error count in a way assistive technology will read, using a live region, so the message is not only visual.

An error message has one job: tell the person what to do. 'Invalid input' fails completely. 'Enter an email address, like [email protected]' succeeds. Name the field, say what is wrong, and give the shape of a correct answer where that is useful. This is a writing task as much as a technical one, and it is where most forms are genuinely poor.

Show it in the right place — next to the field, not at the top of the page or in an alert box that has to be dismissed. Connect it with `aria-describedby` so it is announced with the input, and mark the field `aria-invalid` so its state is available to assistive technology rather than only indicated by colour.

Then do not rely on colour alone. A red border means nothing to a colour-blind user and nothing to anyone who cannot see the screen. Pair it with text and an icon. And clear the error the moment it is fixed — a message that stays after the problem is solved teaches people to ignore your messages entirely.

A modal is an overlay that demands attention, and it is easy to build badly. The requirements: it must be closable by a visible button, by the Escape key, and by clicking the backdrop — because a dialog nobody can escape is a trap. Then focus management: move focus into the modal when it opens, keep it inside while it is open, and return focus to the element that opened it when it closes. Skip that and a keyboard user is left somewhere unrelated.

The modern way to get most of this for free is the `<dialog>` element, which handles focus, Escape and the backdrop natively. Where you build one by hand, you need `role="dialog"`, `aria-modal="true"`, a labelled title, and focus trapping — real work, which is why the native element is the better starting point.

Then the judgement call: use modals sparingly. They interrupt, and an interrupting interface is a worse one. For most confirmations a message in the page is enough; for most forms a page is better. A modal is right when the task genuinely must be finished or abandoned before anything else continues, and wrong almost everywhere else.

Rendering a list from data — rather than writing each item by hand — is the step from a static page to an application. The pattern is always the same: take the data, map it to markup, insert it once. Building a string of HTML and assigning it in one operation is far faster than creating and appending a hundred elements individually.

The critical rule is that data-driven content must still be safe. Interpolating user data into an HTML string and assigning it with `innerHTML` is exactly the cross-site scripting hole from the last session, only larger, because now every item in the list is an injection point. Either escape the values before interpolating, or build elements with `createElement` and set their content with `textContent`.

Then empty and error states, which everyone forgets. What does the list show when there is no data? 'No items yet' is a design; a blank area is a bug the user cannot distinguish from a broken page. The same applies to loading — a brief 'Loading…' tells someone the page is working rather than stuck, which on a slow connection is most of the time.