Chapter 22: Text Input Types & Attributes

readonly vs disabled Attributes

The access control matrix: Focusability, keyboard navigation, `FormData` serialization, and semantic user intent.

LEARNING OBJECTIVES ⌵

Differentiate between readonly and disabled across all 8 architectural behavior dimensions.
Understand the form submission lifecycle: why disabled fields are omitted from FormData while readonly fields are transmitted.
Recognize which HTML input types support readonly versus which silently ignore it per the WHATWG spec.
Style locked form states using the :disabled, :enabled, :read-only, and :read-write CSS pseudo-classes.

🎬 INTERACTIVE VISUAL PIPELINE Core Architecture Simulation

🌐

1. Input

Directives & Tags

⚙️

2. Parse

Tokenizer & AST

🌳

3. Layout

Box Model & Flow

🎨

4. Render

GPU Paint & Composite

PHASE 1: INPUT & DIRECTIVES

Browser receives declarative markup stream, parsing tag tokens and initializing component state.

📖 The Mental Model & Story (Intuitive Foundation)

Imagine walking into a history museum:

The Museum Display Case (readonly): Inside a clear glass display case sits a pristine historical manuscript. You can walk right up to the glass, read every word, shine your flashlight on it, take a photo with your phone, and copy the text down into your notebook. However, you cannot reach in with a pen and edit the ink. The document remains a valid, active part of the exhibit.
The Out-of-Order Vending Machine (disabled): In the hallway, a vending machine has a large yellow tape strip across it reading "Out of Service". You cannot insert coins, pressing the buttons does nothing, the machine lights are off, and the inventory system completely ignores it during daily transactions.

+------------------------------------+    +------------------------------------+
|       READONLY (Museum Glass)      |    |       DISABLED (Out of Order)      |
+------------------------------------+    +------------------------------------+
| - Focusable via Keyboard (Tab)     |    | - Skipped by Keyboard (No Tab)     |
| - Text can be highlighted & copied |    | - Text cannot be selected/copied   |
| - Submits to server in FormData    |    | - OMITTED completely from FormData |
| - Participates in validation       |    | - Skipped by validation engine     |
+------------------------------------+    +------------------------------------+

Choosing between readonly and disabled is a crucial architectural decision that impacts keyboard navigation, screen readers, and backend payload construction.

Technical Deep Dive & Specifications

The Comprehensive 8-Dimension Access Control Matrix

Dimension	`readonly` State	`disabled` State
1. Primary Purpose	Value is locked/immutable, but remains relevant data	Control is inactive/irrelevant in current UI state
2. Keyboard Focus (`Tab`)	✅ Focusable (Users can Tab to it)	❌ Non-Focusable (Browser skips it)
3. Text Selection & Copy	✅ Yes (Users can highlight & copy text)	❌ No / Limited (Treated as inactive text)
4. Form Submission (`FormData`)	✅ Submitted (Name & value serialized)	❌ Omitted (Ignored during submission)
5. DOM Event Firing	✅ Fires `focus`, `blur`, `click`, `keydown`	❌ Suppresses mouse & keyboard events
6. Constraint Validation	✅ Evaluated by constraint validation	❌ Barred from constraint validation
7. Screen Reader Feedback	Read as "Read-only, edit text"	Read as "Dimmed / Disabled"
8. Applicable Input Types	`text`, `search`, `url`, `tel`, `email`, `password`, `date`, `number`, `<textarea>`	ALL form controls without exception

                       EVALUATING LOCKED FORM FIELDS
                                     |
                Does the server need this field on submit?
                                   /   \
                             Yes  /     \  No
                                 /       \
                                v         v
             Should user be able to       Use disabled
             read, tab to, and copy it?   (Omitted from submission)
                            /   \
                      Yes  /     \  No (Hidden token)
                          v       v
                    Use readonly  Use <input type="hidden">
                    (Submitted)   (Submitted invisibly)

The Input Type Applicability Trap

A common trap is attempting to put readonly on checkboxes, radio buttons, or file pickers.

[!WARNING] According to the WHATWG specification, the readonly attribute has no effect on type="checkbox", type="radio", type="file", type="range", type="color", type="button", or <select>!

A checkbox with readonly can still be toggled by the user in standard browsers! To lock a checkbox or select menu, you must use disabled (or prevent toggle via JavaScript).

CSS Styling: `:read-only` vs `:disabled`

Modern CSS provides clean pseudo-classes to style these states semantically:

/* Styling disabled inputs */
input:disabled {
  background-color: #f1f5f9;
  color: #94a3b8;
  border-color: #cbd5e1;
  cursor: not-allowed;
}

/* Styling readonly inputs */
input:read-only {
  background-color: #f8fafc;
  color: #334155;
  border-color: #e2e8f0;
  cursor: default;
}

/* Target standard editable inputs */
input:read-write {
  background-color: #ffffff;
}

💻 Interactive Code Playground

Starter Code

Line-by-Line Code Breakdown

Line 37 (<input ... value="USR-99482-TX" readonly>): Marks the account identifier as non-editable while keeping it focusable via Tab and copyable to the clipboard.
Line 43 (<input ... value="Inactive Data" disabled>): Completely disables the control, barring it from keyboard navigation and event handling.
Line 57–67 (new FormData(form)): Inspects the browser's native submission dataset. Notice that readonly_val is included in the payload, whereas disabled_val is excluded.

Expected Browser Render Output

SYS: ACTIVE

HULL: 98%

CORE: STABLE

NET: ONLINE

HTML STARSHIP CODE TERMINAL playground.html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Readonly vs Disabled Submission Lab</title>
  <style>
    body { font-family: system-ui, -apple-system, sans-serif; line-height: 1.5; padding: 2rem; max-width: 650px; margin: 0 auto; }
    .form-group { margin-bottom: 1.25rem; }
    label { display: block; font-weight: 600; margin-bottom: 0.35rem; }
    input[type="text"] {
      width: 100%;
      box-sizing: border-box;
      padding: 0.6rem 0.8rem;
      font-size: 1rem;
      border: 1.5px solid #94a3b8;
      border-radius: 6px;
    }
    
    /* Semantic pseudo-class styling */
    input:read-only { background-color: #f1f5f9; border-color: #cbd5e1; cursor: default; }
    input:disabled { background-color: #e2e8f0; color: #94a3b8; border-color: #cbd5e1; cursor: not-allowed; }
    
    .status-panel { background: #0f172a; color: #f8fafc; padding: 1.25rem; border-radius: 6px; font-family: monospace; font-size: 0.85rem; margin-top: 1.5rem; }
    button { background: #2563eb; color: white; border: none; padding: 0.65rem 1.25rem; font-weight: 600; border-radius: 6px; cursor: pointer; }
  </style>
</head>
<body>
  <h1>Access Control Comparison</h1>
  <p>Try pressing <kbd>Tab</kbd> to navigate through the fields, and test what serializes on submit:</p>

<form id="demo-form">
    
    <div class="form-group">
      <label for="f-edit">1. Editable Field</label>
      <input type="text" id="f-edit" name="editable_val" value="You can edit me">
    </div>

<div class="form-group">
      <label for="f-ro">2. Readonly Field (<code>readonly</code>)</label>
      <input type="text" id="f-ro" name="readonly_val" value="USR-99482-TX" readonly>
    </div>

<div class="form-group">
      <label for="f-dis">3. Disabled Field (<code>disabled</code>)</label>
      <input type="text" id="f-dis" name="disabled_val" value="Inactive Data" disabled>
    </div>

<button type="submit">Inspect Form Payload</button>
  </form>

<div class="status-panel" id="payload-output">
    Click 'Inspect Form Payload' to see serialized FormData...
  </div>

form.addEventListener('submit', (e) => {
      e.preventDefault();
      const formData = new FormData(form);
      const entries = Array.from(formData.entries());

html += '<br><em>Notice that "disabled_val" was completely dropped from serialization!</em>';
      output.innerHTML = html;
    });
  </script>
</body>
</html>

LIVE RENDER & DIAGNOSTICS CORE TEMP: 45°C

INSPECTING DOM: VALID

TAGS: SCANNING...

Access Control Comparison

1. Editable Field
[ You can edit me                            ]

2. Readonly Field (readonly)
[ USR-99482-TX                               ]

3. Disabled Field (disabled)
[ Inactive Data                              ]

[ Inspect Form Payload ]

Serialized FormData Payload (Submitted to Server):
✓ editable_val = "You can edit me"
✓ readonly_val = "USR-99482-TX"

Notice that "disabled_val" was completely dropped from serialization!

🏋️ Hands-On Exercise

🎯 The Challenge: Build a Customer Account Editor

Instructions:

Create a user profile form with three fields:
- Account UUID: Must be locked so the user cannot edit it, but the user must be able to copy the UUID to clipboard, and it must be submitted with the form.
- Display Name: Fully editable text field.
- Save Changes Button: Initially disabled.
When the user changes their Display Name (making it different from initial value), dynamically enable the Save button (saveBtn.disabled = false).
If the user clears their edit or restores the original name, disable the Save button again.

🏁 Starter Code Sandbox

SYS: ACTIVE

HULL: 98%

CORE: STABLE

NET: ONLINE

STARTER CODE SANDBOX exercise.html

LIVE RENDER & DIAGNOSTICS CORE TEMP: 45°C

INSPECTING DOM: VALID

TAGS: SCANNING...

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Account Editor Challenge</title>
  <style>
    body { font-family: system-ui, -apple-system, sans-serif; padding: 2rem; max-width: 500px; margin: 0 auto; }
    .field { margin-bottom: 1.25rem; }
    label { display: block; font-weight: 600; margin-bottom: 0.35rem; color: #0f172a; }
    input {
      width: 100%;
      box-sizing: border-box;
      padding: 0.65rem 0.8rem;
      border: 1.5px solid #94a3b8;
      border-radius: 6px;
      font-size: 1rem;
    }
    input:read-only {
      background: #f8fafc;
      color: #475569;
      border-color: #cbd5e1;
      font-family: monospace;
    }
    button {
      background: #2563eb;
      color: white;
      border: none;
      padding: 0.75rem 1.5rem;
      font-size: 1rem;
      font-weight: 600;
      border-radius: 6px;
      cursor: pointer;
    }
    button:disabled {
      background: #94a3b8;
      cursor: not-allowed;
      opacity: 0.7;
    }
  </style>
</head>
<body>
  <h1>Account Settings</h1>

  <form id="acc-form" action="/update-profile" method="POST">
    <div class="field">
      <label for="acc-uuid">Account Identifier (Immutable)</label>
      <input type="text" id="acc-uuid" name="account_id" value="acc_9837f4a-89bc" readonly>
    </div>

    <div class="field">
      <label for="acc-name">Display Name</label>
      <input type="text" id="acc-name" name="display_name" value="Linus Torvalds">
    </div>

    <button type="submit" id="save-btn" disabled>Save Changes</button>
  </form>

  <script>
    const nameInput = document.getElementById('acc-name');
    const saveBtn = document.getElementById('save-btn');

    nameInput.addEventListener('input', () => {
      const isDirty = nameInput.value.trim() !== nameInput.defaultValue;
      saveBtn.disabled = !isDirty;
    });
  </script>
</body>
</html>

Why this works:

readonly ensures the Account Identifier cannot be tampered with by typing, while still permitting copy-pasting and transmitting account_id with the POST request.
saveBtn.disabled = true prevents accidental duplicate submissions when no data has been changed.

⚠️ Common Pitfalls

Disabling Fields Expecting Them to Submit: Disabling an input (disabled) prevents its name and value from being sent to the backend. If you want a user to see locked data that still submits, use readonly.
Using readonly on Checkboxes or Radios: As per the HTML specification, readonly does not apply to <input type="checkbox"> or <select>. Users can still toggle them. Use disabled (or JavaScript preventDefault()) instead.
Making Everything disabled and Destroying Keyboard Access: Disabled fields cannot receive focus via the Tab key. If a user needs to review or copy locked reference numbers (like order tracking IDs or license keys), use readonly so keyboard and screen reader users can navigate to them.

💡 Pro Tips

Backend Validation of Locked Fields: Never trust incoming readonly values on the server. A malicious user can open DevTools, remove the readonly attribute in two seconds, and submit arbitrary payload strings. Always verify permissions on the server endpoint.
Semantic CSS with :read-only: Target inputs with :read-only rather than input[readonly] in your stylesheets so you automatically catch non-editable inputs across different browser rendering engines.

📌 Key Takeaways

readonly locks content while maintaining keyboard focus, clipboard copying, and FormData submission.
disabled deactivates the control, removing it from tab navigation, suppressing events, and omitting it from FormData.
readonly applies only to text-like inputs and <textarea>; it is ignored by checkboxes, radios, range sliders, and select menus.
Use :read-only and :read-write to create clean, semantic styling without brittle attribute selectors.
Client-side locked attributes are UX conveniences, not security boundaries; always validate on the server.
--

⭐ LEARN: HTML 🌟 ⚔️ QUIZ BATTLE ARENA // ACTIVE

? Question 1 / 3

What happens to an `<input type="text" name="coupon" value="SAVE20" disabled>` when its parent form is submitted natively?

Topic: HTML Fundamentals

? Question 2 / 3

Which of the following elements will IGNORE the `readonly` attribute, allowing users to still alter its state?

Topic: HTML Fundamentals

? Question 3 / 3

If a user needs to be able to tab to a reference ID, highlight it, and copy it to their clipboard, but must NOT edit it or lose it during form submission, which attribute should you use?

Topic: HTML Fundamentals

👨‍🚀 CADET FLIGHT DOSSIER

CADET EXPLORER

📖 The Mental Model & Story (Intuitive Foundation)

Technical Deep Dive & Specifications

The Comprehensive 8-Dimension Access Control Matrix

The Input Type Applicability Trap

CSS Styling: :read-only vs :disabled

💻 Interactive Code Playground

Starter Code

Line-by-Line Code Breakdown

Expected Browser Render Output

🏋️ Hands-On Exercise

🎯 The Challenge: Build a Customer Account Editor

🏁 Starter Code Sandbox

⚠️ Common Pitfalls

💡 Pro Tips

📌 Key Takeaways

What happens to an <input type="text" name="coupon" value="SAVE20" disabled> when its parent form is submitted natively?

Which of the following elements will IGNORE the readonly attribute, allowing users to still alter its state?

If a user needs to be able to tab to a reference ID, highlight it, and copy it to their clipboard, but must NOT edit it or lose it during form submission, which attribute should you use?

CSS Styling: `:read-only` vs `:disabled`

What happens to an `<input type="text" name="coupon" value="SAVE20" disabled>` when its parent form is submitted natively?

Which of the following elements will IGNORE the `readonly` attribute, allowing users to still alter its state?