Pattern: multi-column detail form

Requested delivery date — the days you cannot pick

This grid starts its week on Monday (ISO 8601), which suits a European buyer. Where the week starts is a property of your data, not a setting on the component — see calendar for why the framework ships no data-week-start, and generate the month accordingly.

The plain <input type="date"> above is right for order date — any day is valid, and the native picker is already good. A requested delivery date is a different question: the dock is shut at weekends and closed for the company shutdown on the 7th, so some days are not offers. Those days are real <button disabled>s, so the constraint is enforced by the control rather than by a validation message after the fact — and each carries a visually-hidden reason, because a day that is merely greyed out tells a screen-reader user nothing. This is the one thing a native date input cannot express: a set of marked days.

Variant: field-per-row layout (master-data maintenance)

Some one-record edits read better as a table than a form — master-data maintenance, the SM30 case: a back-office user opens one vendor and corrects a handful of fields (a name typo, a credit limit, a date), a few times a week, with each field given the input its type deserves. One row per field, still one record, still this pattern — not the editable grid, which is many ROWS, one record per row.

One Save at the bottom, not one per row. These rows are the FIELDS OF ONE RECORD, not a list of records — a Save per field means six requests for one logical edit, a Cancel that undoes a third of what the user changed, and, measured on the first version of this variant, a button sitting 228px from the field it saves in an actions column taking 37% of the table. Per-row Save belongs to the editable grid, where each row really is a record. Seamless (--seamless) on every field, including money — a screen where some fields read as text and others as boxes tells the user the boxed ones are editable and the rest are not, backwards from the truth. Zero new CSS: the data table with data-row-edit, ordinary typed inputs — the page's own line items table above stays plain (no dirty tracking, by this page's own design); this variant is the one place on the page that wires initRowEdit().

Anatomy

1. Sections — real <fieldset>s (.bo-form-section); the legend is the group's accessible name, so a screen reader announces "Header, group" before the fields.
2. Rows — .bo-form-row is an auto-fit grid, so columns collapse by available width with no breakpoint to maintain.
3. Line items — a plain table here (one seamless numeric cell per row, no dirty tracking, kept simple for this page's own scope); nest the fully-wired editable grid — data-row-edit, per-row dirty state independent of the header fields — where line items need Save/Cancel of their own.
4. Delivery calendar — calendar for the one field whose valid days are constrained; closed and holiday days are disabled submit buttons, not styling.
5. Action bar — sticky .bo-form-actions; the framework sets scroll-padding-block-end so focus never lands under it.
6. Field-per-row variant (below) — inline editing on <th scope="row"> labels instead of fieldsets, for the master-data case where the record IS the table.

Data contract

Server-side validation is the contract behind aria-invalid: re-render with the user's values, never a blank form, and point aria-describedby at the message. Pair with the validation summary when more than two fields can fail at once.

States

Keyboard walkthrough & print

1. Tab runs header fields → line items → action bar; the sticky bar never hides the focused field.
2. Inside line items, each cell is a real control — focus IS edit (see editable grid).
3. Enter in a text field submits the form natively; keep Save as the form's submit button so that stays true.
4. After a failed save, move focus to the first invalid field — the browser does this for native validation; do it yourself for server errors.

Print: the print layer drops the action bar and renders fields as values, so a printed edit screen reads as a document rather than a form.

Components used

complexity 2 of 4

• Forms
• Editable grid
• Validation summary
• Calendar
• Inline editing
• Money