Login - Jit4All

A user wants to cancel a subscription, but the cancellation page only offers a button labeled "Submit feedback first." The user has a clear goal, stopping the subscription, but the browser has no action called cancel. Why does an avatar capable of representing a person's banking, shopping, and socializing online have no way to perform an action as simple as canceling something directly?

The browser's entire vocabulary of actions is small and fixed: follow a link, type into a field, submit a form, and a small number of related browser-level actions such as going back. There is no action called cancel. There is only ever a link or a form somewhere on a page that a server has chosen to wire up to do something the server calls canceling. If no link or form on the page performs that specific action, the avatar has no move that does it either, no matter how clearly the user's goal is expressed elsewhere, such as in a typed support message.

Every single thing a browser does on a user's behalf reduces to a small number of actions: following a link, typing into a field, submitting a form, and a handful of browser-level actions such as going back or reloading.

A link's destination, and a form's destination and method, are decided entirely by whoever wrote the page's HTML, not by the browser. The browser only ever carries out exactly what a link or a form was built to do.

Typing into a field does nothing on its own until that value is actually submitted, as part of a form, to some destination the page itself defined.

A user's broader goal, such as canceling a subscription or finding a cheaper flight, has to be translated, by whoever built the page, into one of these specific actions before the browser has any way to carry it out at all.

This small, fixed vocabulary is exactly what makes a browser able to represent a user across every kind of website, from banking to shopping to social media, without needing a different, custom action for every different goal a user might have.

<a href="/account/upgrade">Upgrade plan</a>

<form action="/account/cancel" method="post">
   <button type="submit">Cancel subscription</button>
</form>

<form action="/search" method="get">
   <input type="text" name="q">
   <button type="submit">Search</button>
</form>

Clicking the link sends a request for exactly /account/upgrade. Nothing about clicking it lets the browser add, remove, or guess at any further detail, it asks for that one address, exactly as written.

Clicking the cancel button submits the form to /account/cancel using method="post". The word "Cancel" on the button is only a label for a person to read. The actual action performed is submitting this form to this address, nothing more specific than that.

Typing into the search field by itself sends nothing anywhere. Only clicking the search button, which submits the form, turns that typed text into part of an actual request.

The search form uses method="get", which places the typed value into the address itself, while the cancel form uses method="post", which does not. This single difference in one attribute decides where the submitted value ends up, not anything about what the buttons are labeled.

Every one of these three elements, the link and the two forms, is wired to one specific destination by whoever wrote this exact page. The same browser, on a different page with no such cancel form present anywhere, would have no way at all to perform an equivalent action.

A button reading "Cancel subscription" performs the action of submitting this exact form to this exact address, nothing more specific. If that one form happened to be wired to a different address entirely, clicking the same labeled button would perform a completely different action with the exact same label still showing.

If no link or form on a page is wired to perform some specific action, such as canceling, the browser has no way to perform that action, regardless of how clearly the user's goal is expressed anywhere else, including in a typed support message that a person, not the browser, would have to read and act on separately.

Text typed into a field sits only in the browser, doing nothing at all, until a form containing that field is actually submitted. A user who types a full search term and then never clicks submit has sent nothing to any server whatsoever.

A form using method="get" places its submitted values directly into the resulting address, visible in the address bar and in browser history. The exact same fields submitted with method="post" place those values somewhere not visible in the address at all, which matters specifically for anything sensitive.

A banking site's transfer button and a social media site's post button are, to the browser itself, the exact same kind of action, submitting a form to an address. The browser has no special-case understanding of banking or socializing, only of links, fields, and forms.

When an AI tool describes a user flow, three things are worth checking. First, does it distinguish between a button's visible label and the actual link or form action it is wired to. Second, does a form submitting anything sensitive, such as a password, use method="post" rather than method="get". Third, does it correctly treat typing alone as not sending anything until an actual submit happens.

Change the cancel form's method from post to get, submit it, and look at what appears in the address bar afterward that did not appear before.

Write a second link, with a different label but the exact same href as the upgrade link, and explain why both perform the identical action despite different wording.

Type a search term into the search field, then reload the page without clicking submit, and confirm nothing about the typed term was ever sent anywhere.

Find a real page that has a clear user goal with no link or form to match it directly, and describe what the user actually has to do instead.

Rewrite the cancel form so its button is labeled "Submit feedback first" instead, while keeping the exact same action attribute, and explain why the actual behavior has not changed at all.

Assuming a button's label describes the action it performs, rather than only being text a person reads, with the real action set entirely by the underlying link or form.

Submitting sensitive information, such as a password, through a form using method=get, placing that value into the visible address instead of out of sight.

Believing a user's broader goal is automatically achievable on any page, when it is only achievable if some specific link or form on that exact page was built to perform it.

Treating every website's buttons as having some special, built-in understanding of their purpose, rather than all reducing to the same small set of link and form actions underneath.

You can now name the small, fixed set of actions a browser is actually capable of performing on a user's behalf, and explain why a clearly expressed goal still requires a matching link or form somewhere on the page before the browser has any way to act on it. You can also tell apart a button's label from its real, underlying action, and explain why GET and POST send submitted values to two genuinely different places.