webdevpuneet.com

Related Snippets

85 in Tables category
40–45 of 60

Table Inline Cell Validation

Print-Optimized Table View

Nested JSON to Table Mapper

Table Loading / Empty / Error States

Table Row Right-Click Context Menu

Table Export Menu (CSV/JSON/Print)

Table Inline Cell Validation — Real Per-Column Validators (HTML CSS JS)

Table Inline Cell Validation · Tables · Plain HTML, CSS & JS · Live preview

CategoryTables
TagsData TablesForms & Validation

Copy & paste

Source Code

<div class="tcv-wrap">
  <div class="tcv-bar">
    <h3>Add order line</h3>
    <button type="button" class="tcv-save" id="tcvSave">Save row</button>
  </div>
  <table class="tcv-table">
    <thead><tr><th>Product</th><th>Email</th><th>Quantity</th><th>Discount %</th></tr></thead>
    <tbody>
      <tr id="tcvRow">
        <td class="tcv-cell" data-field="product">
          <input class="tcv-input" data-field="product" placeholder="Required">
          <span class="tcv-err" id="err-product"></span>
        </td>
        <td class="tcv-cell" data-field="email">
          <input class="tcv-input" data-field="email" placeholder="[email protected]">
          <span class="tcv-err" id="err-email"></span>
        </td>
        <td class="tcv-cell" data-field="qty">
          <input class="tcv-input" data-field="qty" placeholder="e.g. 12">
          <span class="tcv-err" id="err-qty"></span>
        </td>
        <td class="tcv-cell" data-field="discount">
          <input class="tcv-input" data-field="discount" placeholder="0–100">
          <span class="tcv-err" id="err-discount"></span>
        </td>
      </tr>
    </tbody>
  </table>
  <div class="tcv-status" id="tcvStatus" hidden></div>
  <div class="tcv-log" id="tcvLog"></div>
</div>

Extend with AI

Take This Snippet Further With AI

The AI prompt for this one is for Patreon supporters ($3 a month), along with a site with no ads. Supporters enter the passcode once and it is remembered in this browser.

· Become a supporter

What's included

Features

Real per-column validators
A dedicated function per field genuinely inspects the value and returns a pass/fail message.
Regex email validation
A real pattern check, not just a non-empty check.
Positive-integer quantity check
Number.isInteger plus a positivity check rejects decimals, negatives, and text.
Optional-but-bounded fields
Discount is optional when empty but must be 0–100 when filled in.
Inline error tooltip
A positioned message beneath the invalid input states the exact reason it failed.
Live and blur validation
Errors clear the instant a value becomes valid while typing.
Genuinely blocked save
Save only pushes data into savedRows when every cell in the row passes.
Real captured data
Valid rows are pushed into a real array and rendered into a running log.

About this UI Snippet

Table Inline Cell Validation — Genuine Per-Column Rules That Block Saving

Screenshot of the Table Inline Cell Validation snippet rendered live

An editable table cell that accepts anything typed into it isn't actually editable data entry — it's a text box pretending to be a form. This snippet builds real per-column validation for an editable table row in plain HTML, CSS, and vanilla JavaScript: a dedicated validator function per field, a red outline and an inline error tooltip on invalid cells, and a Save action that's genuinely blocked until every cell in the row passes.

A real validator function per column

The VALIDATORS object maps each field name to a function that inspects the actual current value and returns an error message string (or an empty string when valid). product checks non-empty; email runs a real regex (/^[^\s@]+@[^\s@]+\.[^\s@]+$/) against the trimmed value; qty parses the value as a number and checks Number.isInteger(n) && n > 0; discount is optional but, if filled in, must parse to a number between 0 and 100. None of these are decorative — each genuinely inspects the live input value and computes a real pass/fail result, so typing "abc" into the quantity cell or "not-an-email" into the email cell is caught by actual logic, not styling alone.

Inline error tooltip, not just a red border

An invalid cell gets both a red input outline (.tcv-invalid .tcv-input) *and* a small speech-bubble-style message positioned directly beneath the offending input, showing the exact validator's message ("Enter a valid email address," "Quantity must be a positive whole number"). Color alone doesn't tell a user *why* a cell is wrong; the message does — and because it's populated by the validator's actual return value, the message always matches the real reason the cell failed.

Validated on input and blur, re-validated at save

Every input validates live as the user types (so the error clears the moment the value becomes correct) and again on blur. Clicking "Save row" runs validateAll() across every cell regardless of which was last touched, and only pushes the row into savedRows if every single validator passes — an invalid row is genuinely never accepted; the save function returns early and leaves the invalid cells highlighted rather than silently proceeding.

Real data on success, not a fake confirmation

A successfully validated row is pushed into a real savedRows array and rendered into a running log below the form, with a live count. This closes the loop: validation isn't a UI-only gate that then does nothing — passing it results in the row's data genuinely being captured, exactly the way a real save-to-server call would only fire after the same validation passed.

Extending to more columns or rules

Because every column's rule lives in one small function keyed by field name, adding a new validated column is one new VALIDATORS entry plus a matching cell and error span — no changes to validateField, validateAll, or the save handler. Pair this with an editable table for the broader inline-editing pattern, or a data table once validated rows need to live in a larger, sortable dataset.

Step by step

How to Use

  1. 1
    Paste HTML, CSS, and JSAn editable row renders with Product, Email, Quantity, and Discount % cells.
  2. 2
    Leave a field empty and click SaveRequired cells outline red with an inline error tooltip; the row is not saved.
  3. 3
    Type an invalid emailThe email cell fails its regex check and shows "Enter a valid email address."
  4. 4
    Type a negative or decimal quantityThe quantity cell fails its integer-and-positive check.
  5. 5
    Fix every cell and click SaveOnce all validators pass, the row is captured and appended to the log below.
  6. 6
    Add another ruleAdd a new key to VALIDATORS and a matching cell/error span for a new validated column.

Real-world uses

Common Use Cases

Bulk data entry grids
Validate spreadsheet-style row entry in bulk data entry grids, with a dedicated function per column genuinely inspecting each value.
Order and invoice line entry
Catch bad quantities or discounts using Number.isInteger plus a positivity check, as in an invoice line items table.
CRM and contact imports
Validate emails inline with a real pattern before saving, showing red outlines and an inline error tooltip.
Editable admin panels
Block a save on any row with errors, extending a plain editable table with real validation rules.
Optional bounded fields
Treat discount as optional when empty but required to be between 0 and 100 when filled, reusing the validator pattern for onboarding forms.
Related: Inline Add Row to Table
See the Inline Add Row to Table for a related tables pattern worth pairing with this one.

Got questions?

Frequently Asked Questions

They genuinely check it. Each entry in VALIDATORS is a function that receives the live input value and computes a real result — the email validator runs an actual regex test, the quantity validator calls Number.isInteger on the parsed value and checks it's greater than zero. The red outline and error message only appear because that function's return value was a non-empty error string, not because of any hardcoded styling rule.

No. Clicking Save row calls validateAll(), which runs every column's validator against its current value and returns false if any one fails. The save handler checks that return value and returns early without touching savedRows if it's false — so an invalid row genuinely never gets appended to the saved data or the log, it isn't just visually blocked.

Its validator returns no error for an empty value (since discounts aren't required), but if the user does type something, it must parse as a number between 0 and 100 — a non-numeric value or one outside that range still fails. This models a common real-world rule: a field can be optional while still needing to be well-formed whenever it is provided.

Exactly what the failing validator returned — "Product name is required," "Enter a valid email address," "Quantity must be a positive whole number," or "Discount must be a number from 0 to 100." Because the tooltip's text is set directly from the validator's return value, it always matches the real reason that specific cell is invalid rather than a generic "invalid input" message.

Keep the VALIDATORS map exactly as plain functions, store each field's current value and error message in component state, run the relevant validator on input/blur/save, and bind the invalid class and error text to that state. The validator functions themselves are framework-agnostic and don't need to change.