Build on durable web standards
Choose a support policy, progressive enhancement and a repeatable compatibility review.
A Rails application can improve as browsers advance without repeatedly replacing its front end. Start with server-rendered HTML, ordinary links and forms, and a clear support policy. Adopt capabilities where they remove application code, improve accessibility or make a real task faster.
This four-part series connects standards, device computation, offline storage and synchronization. A useful base experience supports carefully measured enhancements. A specification, a browser implementation and a dependable production feature are different stages.
Use Baseline to start a decision
Baseline calls a feature newly available when it becomes interoperable across its core browser set; widely available follows 30 months later. Those labels are more precise than “modern.” The set covers Chrome and Firefox on desktop and Android, Edge on desktop, and Safari on macOS and iOS.
Older releases, embedded webviews, assistive technologies and browsers outside that set need separate consideration. MDN explains Baseline’s limits. A green badge cannot establish that your editor works with a particular screen reader.
Keep a dated adoption record: exact feature and options, compatibility reference, required user environments, intended benefit and fallback. Broad API names can conceal uneven support for individual methods. The Interop project is another signal: vendors improve selected areas against shared Web Platform Tests. A focus area invites investigation; it does not promise that every deployed browser already passes.
Write a support policy around tasks
“Supports modern browsers” leaves too many decisions to the next bug report. Name essential tasks and the environments where they must succeed. For our field-report example, reading assigned material, editing a report and submitting it are essential; animation and local previews are optional. Offline editing is a separately advertised capability, not something a first visit can assume.
Record minimum browser versions, relevant embedded browsers and representative assistive-technology combinations. Use actual audience information when available; missing analytics does not prove a group does not exist. Decide explicitly whether an unsupported environment gets a read-only page, an online form or a clear limitation.
Review the policy on a predictable schedule and when dependencies or target devices change. Raising the minimum version needs a reason and a migration plan. Optional features may advance faster when their absence leaves the task intact.
Prefer existing browser behavior
An ordinary link supports navigation, copying a destination, opening another tab and browser history. A button represents an action. Labeled inputs give the browser and assistive technology information about a field. These are valuable application components before a JavaScript framework enters the picture.
For optional explanatory content, consider details and summary. The HTML standard defines their relationship. They are not universal replacements for tabs or menus. Native controls still need appropriate names, readable styles, visible focus and testing.
W3C’s ARIA guidance explains why putting a role on a generic element does not supply keyboard behavior. Choose appropriate HTML to reduce the behavior you must implement. Let CSS handle responsive arrangement rather than introducing measurement loops without a demonstrated need.
Make enhancement reversible
Suppose field reports already arrive as an HTML list. A grid can improve presentation without changing records or reading order. This simplified CSS is illustrative, not an executed application example:
.directory { display: block; }
.directory > * { margin-bottom: 1rem; }
@supports (display: grid) and
(grid-template-columns: repeat(auto-fit, minmax(12rem, 1fr))) and
(gap: 1rem) {
.directory {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(12rem, 1fr));
gap: 1rem;
}
.directory > * { margin-bottom: 0; min-width: 0; }
}The minimum column width still needs testing against the actual container, long content and enlarged text; use the base list where the container cannot accommodate it. A CSS feature query checks specified declarations. It does not certify layout or accessibility. In particular, testing only display: grid would not guard every other function used inside the block.
For JavaScript, detect the capability rather than guessing from the browser name. Handle failure after detection: scripts may fail to load, permission may be denied, and operations may reject. Keep the ordinary action available until the enhancement is ready. A failed preview should still leave a working form and server-rendered result.
Keep Rails responsible for the application
Rails remains the home for authorization, shared persistence, validation and HTML rendering. Its JavaScript guide describes Turbo and import maps for improving navigation and delivering JavaScript without requiring a separate client application. Choose a bundler when dependency or build requirements justify it.
Begin the editor with a Rails form whose error response preserves input. Add a small controller for a live preview, while keeping server validation authoritative. Test the plain form path independently. Local drafts and synchronization, covered later, add deliberate capabilities rather than silently replacing that contract.
Put measurable gates before release
- Essential journeys succeed with enhancements unavailable, including blocked scripts and denied capability requests.
- Check keyboard navigation, focus, labels, error announcements, enlarged text and relevant screen readers.
- Run affected journeys across the supported browser matrix and a representative modest phone.
- Keep transfer size, responsiveness and task completion within agreed budgets.
- Disable an enhancement without losing user work.
Core Web Vitals provides reference targets: LCP no more than 2.5 seconds, INP no more than 200 milliseconds and CLS no more than 0.1, assessed at the 75th percentile with mobile and desktop considered separately. These are targets, not measured results for this site. Add task measures such as draft recovery time and failed submissions.
Roll out to a small audience when practical, compare failures and completion times, and record the release, compatibility evidence, checks and rollback method in a dated changelog. Continuous standards adoption becomes manageable when each change has a concrete benefit, supported base, small implementation and a way to tell whether it helped.
Companion guide: Government accessibility, standards and Ruby connects accessibility requirements with design systems, Rails libraries and service-level assessment.