A separate mobile form can look cleaner while quietly losing a field that exists on desktop. Two implementations can also drift in validation and saving. The archived request was to retain the same data and editing functions while adapting the screen. I reconstructed that principle as this small independent HTML and CSS example. It contains no customer implementation and does not reproduce the original ERP's device review. Its purpose is to make the single-input-tree approach inspectable and reusable.
Changing width should not create new inputs
The example contains one table with two synthetic items and quantity and note fields. CSS specifies a conventional table at wider widths and a card arrangement at smaller widths. There is no viewport-dependent form creation or copying of values. Each input identifier, name and event connection appears once in the document. A change in presentation therefore does not require a second representation of the entered data.
That structure does not solve every mobile problem. Keyboard space, long validation messages, popup positioning and focus movement need their own review. It does provide a starting point for avoiding omitted fields in a separate mobile save function. An owner reading a status overview and a member of staff editing a document may also need different information orders. Sharing records should not mean forcing every role to read an identical arrangement.
Keep the relationship between headings and controls
When column headings become less visible on a narrow screen, isolated values can lose their meaning. The example places visual quantity and note labels inside each card and connects each input to both its row and column heading identifiers. That structure aims to explain which item's quantity a person is editing. If field names or headings change, the associated references need to change with them rather than becoming unrelated copied text.
Adding labels does not establish an accessibility result. A changed table presentation still needs review with the relevant assistive technology. The static checker verifies that referenced labels exist and that identifiers are unique. It does not exercise a screen reader, keyboard navigation, printing or a phone keyboard. The module deliberately states the difference between a source contract that has been checked and actual use that still needs examination.
Explore the implementation
Independent example core source
:root { color-scheme: light; font-family: system-ui, sans-serif; color: #18342c; background: #f2f4ee; }
* { box-sizing: border-box; }
body { margin: 0; padding: 20px; }
main { max-width: 940px; margin: auto; }
h1 { font-size: clamp(1.5rem, 4vw, 2.2rem); }
p { line-height: 1.65; }
.table-wrap { max-width: 100%; overflow-x: auto; }
.work-table { width: 100%; border-collapse: collapse; background: white; }
.work-table caption { text-align: left; padding: 14px 0; font-weight: 700; }
.work-table th, .work-table td { padding: 12px; border-bottom: 1px solid #cad3c8; text-align: left; vertical-align: top; overflow-wrap: anywhere; }
.work-table thead { background: #e0e8dc; }
.work-table input { width: 100%; min-width: 0; min-height: 44px; padding: 8px; border: 1px solid #82988b; border-radius: 6px; font: inherit; font-size: 16px; color: inherit; }
.work-table input:focus-visible, button:focus-visible { outline: 3px solid #a75024; outline-offset: 3px; }
button { min-height: 44px; padding: 10px 18px; border: 0; border-radius: 8px; font: inherit; color: white; background: #214f3c; margin-top: 16px; }
.mobile-label { display: none; }
pre { white-space: pre-wrap; overflow-wrap: anywhere; padding: 12px; background: white; }
@media (max-width: 700px) {
body { padding: 12px; }
.work-table { display: block; background: transparent; }
.work-table caption { display: block; }
.work-table thead { position: absolute; width: 1px; height: 1px; padding: 0; overflow: hidden; clip-path: inset(50%); white-space: nowrap; }
.work-table tbody { display: grid; gap: 12px; }
.work-table tr { display: grid; grid-template-columns: minmax(0,1fr); padding: 8px; background: white; border: 1px solid #cad3c8; border-radius: 10px; }
.work-table td, .work-table tbody th { display: block; border: 0; min-width: 0; padding: 8px; }
.mobile-label { display: block; font-weight: 600; font-size: .875rem; margin-bottom: 6px; }
}
@media print {
body { background: white; }
button, #result, .demo-note { display: none; }
}
Inspect local values without pretending to save them
The example's button reads the current values from the same form and prints JSON below it. It does not calculate amounts, confirm documents, persist data or send a request. This provides a small integration point for inspecting the field relationship. A real application should retain its existing server validation and save path. The demo action must not be labeled as operational saving: showing a value locally is not evidence that a database has retained it.
Output is assigned as text, so an entered note is not executed as HTML. The files require no downloaded dependency or remote asset. Extract them together and open the example HTML to inspect the structure. Nine static field and label checks, plus JavaScript syntax validation, passed for this publication. Following the user's instruction, browser screen review was not required or performed. Those source checks should not be presented as a substitute for checking the interface before operational use.
A card layout is not appropriate for every table
Cost and settlement comparisons may rely on looking across several columns at once. Cards can make those relationships harder to read. Merged headings, extensive numeric comparisons and related totals may work better with horizontal scrolling or a separate summary. This example is limited to straightforward headings and row-based editing. Reusability means explaining its conditions and configurable parts, rather than promising an automatic conversion of every business table.
Before adoption, list the original fields and save payload. Prepare a case editing the same item at desktop and phone widths. Check field retention, entered values, visible errors and whether an action fires exactly once. Which functions to remove or add is a business decision, but a smaller screen should not silently remove a required fact. All supplied files are synthetic and contain neither company records nor code copied from the original application. Keep the receiving program's business rules and perform the browser and device checks appropriate to its users.