Disabled vs Readonly Product Fields in Export Inquiry Forms: Keeping the Model Visible and the Submission Complete
Author
A decision guide for export-website teams that pre-fill a product model or specification into an inquiry form. It separates the submission behavior of the disabled attribute from the readonly attribute, identifies the control types where readonly does not apply, and places both behind the server-side validation obligation that actually protects the inquiry data. Worked examples are labelled hypothetical; no customer values, prices or rankings are asserted.
The decision in front of you
A buyer lands on a product page, opens the inquiry form, and the product model is already filled in. The buyer should be able to read which model they are asking about. The buyer should not casually rewrite it into a different model, because the sales team will quote against whatever arrives. And the value still has to arrive with the submission.
That combination produces two distinct failure modes, and they are easy to confuse because both look like a locked field on screen.
The first failure is silent data loss. The field looks correct to the buyer, the form submits without an error, and the product model is simply absent from what the server receives. The second failure is a false sense of protection: the field looks locked, but the value is trivially changeable in the browser, so the sales team receives a model the buyer chose rather than the one the page displayed.
The attribute choice is what separates these outcomes. The Boolean disabled attribute, when present, makes the element not mutable, focusable, or even submitted with the form. The readonly attribute behaves differently on the submission side: read-only controls can still function and are still focusable, whereas disabled controls cannot receive focus and are not submitted with the form.
This article is a decision guide, not a definition list. It works through what each attribute does to the submission, where readonly does not apply at all, and what the server must do regardless of which attribute you pick.
What disabled actually does to the submission
The disabled attribute is often reached for because it produces the clearest visual signal: the control is greyed out and the buyer cannot click into it. That visual result is real, but it is a side effect of a much stronger behavior.
A disabled control is not submitted with the form at all. It also does not participate in constraint validation, and browsers typically grey it out and stop it receiving browsing events such as mouse clicks or focus-related events.
For an export inquiry form, that changes what the field is. A disabled product-model field is a display element, not a data carrier. Whatever the buyer sees there will not appear in the request the server receives. If the model must reach the sales inbox, something else has to carry it: a hidden field holding the same value, a server-side lookup keyed to the page or product, or a readonly control that is still submitted.
There is a second consequence that catches teams later. Because a disabled field cannot have its value changed, required does not have any effect on inputs with the disabled attribute also specified, and most other attributes such as pattern have no effect until the control is enabled.
Hypothetical scenario for illustration only; it does not describe a real client, test or observed outcome. An exporter pre-fills the model number into a disabled text input on the RFQ form, marks it required for good measure, and tests the form by submitting it. The confirmation page appears, the sales team receives the inquiry, and the model line is blank. Nothing errored, because nothing was wrong from the browser’s point of view: the field was never part of the submission. The fix is not to remove disabled and let buyers edit the model; it is to decide which element actually carries the value.
The disabled attribute is documented on MDN’s disabled attribute reference, which is the source for the submission and validation behavior described above.
What readonly actually does — and what it does not
The readonly attribute is the closer match for the product-model case, because it blocks editing without removing the field from the submission. The Boolean readonly attribute, when present, makes the element not mutable, meaning the user cannot edit the control.
The contrast with disabled is the part that matters for the inquiry path. Read-only controls can still function and are still focusable, whereas disabled controls cannot receive focus and are not submitted with the form.
Readonly also interacts with validation in a way that surprises people. Because a read-only field cannot have its value changed by a user interaction, required does not have any effect on inputs with the readonly attribute also specified.
The boundary that matters most is what readonly is not. It is a browser UI restriction, not a security control. The only way to modify dynamically the value of the readonly attribute is through a script, which means the restriction lives entirely in the page the buyer’s browser is running. A buyer who opens developer tools, or who submits a crafted request directly to the form endpoint, is not constrained by it. Readonly does not prevent tampering, and treating it as if it did is the mistake this section exists to prevent.
MDN’s readonly attribute reference documents the supported control types and the script-only dynamic modification described here.
When readonly is the wrong tool: select, checkbox and other unsupported types
Readonly is not a general-purpose lock. It applies to a specific family of controls, and outside that family it does nothing at all.
The readonly attribute is supported by textual form controls, including input elements of type text, search, tel, url, email, password, date, month, week, time, datetime-local, number, and textarea.
It is not relevant to all other elements, including select and button, and it does not apply to non-textual input elements including hidden, range, color, checkbox, radio, file, submit, image, reset and button.
The practical consequence is blunt: a variant dropdown cannot be locked with readonly. Adding the attribute to a select element produces no visible change and no behavioral change, so the field stays fully editable while the team believes it is protected. The same applies to a configuration checkbox or a radio group.
For those control types the realistic options are narrower. One is disabled, which locks the control but removes it from the submission, so the value has to be carried elsewhere. The other is to stop using an editable control for the locked value at all: present the variant as plain read-only text for the buyer, and submit the value through a hidden field or a server-side lookup. The second option avoids both the submission-loss problem and the unsupported-attribute problem.
Hypothetical scenario for illustration only; it does not describe a real client, test or observed outcome. An exporter’s RFQ form offers a dropdown of product variants, pre-selected from the page the buyer came from. The team adds readonly to the select, tests it in one browser, sees the dropdown still works, and assumes the attribute is simply cosmetic. A buyer changes the variant before submitting, and the sales team quotes a configuration the page never offered. The dropdown was never locked; readonly had no effect on it.
The supported and unsupported control lists above follow MDN’s readonly attribute reference.
The server is the only place the product model is actually trusted
Everything discussed so far happens in the buyer’s browser. The attribute choice determines what the buyer sees and what the form sends, but it does not determine what the business accepts, because the submitted request is data the business receives rather than a control it owns.
Input validation checks whether data meets an application’s requirements before the application uses it, and it reduces the risk of malformed data, invalid business operations, and excessive resource consumption.
Client-only checks are a common pitfall: validate on the server even when the browser checks the same fields, because client-side validation is bypassable and should be used for immediate feedback.
For a product-model field, the validation has to go beyond confirming that a string arrived. Validate both syntax (the expected type and format) and semantics (whether the value makes sense for the operation), including consistency between related fields.
Where the model is chosen from a fixed set, enforce exact membership in the allowed set, including values submitted from drop-down menus.
The handling rule is equally specific. Reject invalid requests with a clear error; do not continue with partially validated data, and bind only intended input fields to application objects.
Applied to this field, that means the server should confirm the submitted model is one the business actually sells, and that it is consistent with the rest of the inquiry — the quantity, the destination market, the configuration options the buyer selected. A model that is a well-formed string but not a model in the catalog is exactly the case the allowlist check exists to catch.
This article states the validation obligation; it does not provide a secure-backend guarantee or a specific implementation. The exact server stack, framework validators and data model are customer-specific and are not supplied here.
OWASP’s Input Validation Cheat Sheet is the source for the validation rules above.
A workable pattern for the product-model field
Choose the display and submission pattern that fits the actual control, rather than adding a second carrier to every field.
Show the product model as a readonly textual control, or as plain read-only text, so the buyer can read it and cannot casually edit it. A readonly text input that is enabled and part of the form submits its own value, so it can serve as both the display and the carrier. A separate hidden field or a server-side lookup is an alternative carrier, not a mandatory companion to every readonly control.
If the model is a fixed choice from a dropdown, do not rely on readonly on the select. Use a hidden field for the submitted value and a read-only display for the buyer, because readonly does not apply to select elements.
Do not rely on disabled for a value that must be submitted. If disabled is used for visual reasons, pair it with a hidden field carrying the same value, because a disabled control is not submitted with the form.
On the server, validate the submitted model against the allowed set and against the rest of the inquiry before it reaches the sales inbox. Note that required has no effect on disabled or readonly inputs, so requiredness for these fields has to be enforced on the server rather than in the browser.
Hypothetical scenario for illustration only; it does not describe a real client, test or observed outcome. An exporter implements the pattern: the product page renders the model as read-only text, the form carries the model in a hidden field, and the server checks the submitted model against the catalog before routing the inquiry. A buyer edits the hidden field to a model the company does not sell. The server rejects the request with a clear error rather than forwarding a quote request for a nonexistent product. The browser-side restriction did not stop the edit; the server-side check did.
The exact field names, product identifiers and server stack are customer-specific and are not supplied here; the pattern describes the division of responsibility, not a specific implementation.
What this article does not claim
Readonly does not prevent tampering. It is a browser UI restriction, and the only way to modify dynamically the value of the readonly attribute is through a script.
No secure-backend guarantee is provided. The server-validation obligation is stated, not a specific implementation, and client-side validation is bypassable regardless of which attribute is used.
No specific product identifiers, field names, prices or timelines are asserted.
For the wider inquiry-form picture, see the related notes on website lead forms and field routing, and on technical drawing upload design for RFQ forms.
Comments (0)
No comments yet. Be the first!