Skip to content

De-risk the html{zoom} layout dependency (Safari verification + fallback/guard) #70

Description

@BorisTyshkevich

Part of #68 (Roadmap to 1.0.0) — release-blocker.

Problem

The whole UI depends on html { zoom: var(--zoom) } (src/styles.css:3, factor 1.2). Because zoom does not divide viewport units and getBoundingClientRect() is post-zoom, the app hand-corrects everywhere: zoomScale() in src/ui/dom.js, the calc(... / var(--zoom)) viewport panels, and pointer-mapping in editor.js / results.js / schema-detail.js / splitters.js / chart-data.js. There is no @supports (zoom: 1) feature detection and no fallback (no @supports in the stylesheet). On any engine that ignores zoom or diverges in how it interacts with rects/viewport units, the UI renders at the wrong scale and every pointer/caret/drag computation is wrong — a hard failure, not graceful degradation.

zoom is non-standard: Chrome/Edge always supported it, Firefox added it in 2024 (~v126), WebKit/Safari supports it but with known rect/viewport divergences — exactly the seams this app corrects.

Ask

  • Verify behavior on WebKit/Safari (depends on the WebKit-e2e issue).
  • Either confirm it's correct everywhere, or add a guard: @supports feature-detection with a documented fallback, or move to a non-zoom scaling approach (e.g. rem/root-font scaling or a transform wrapper) if Safari diverges.
  • At minimum, fail loudly / degrade gracefully rather than silently mis-scaling on an unsupported engine.

Acceptance

  • Confirmed correct on all engines in the support matrix, OR a feature-guard/fallback is in place.
  • No silent wrong-scale / wrong-pointer state on an engine that doesn't honor zoom.
  • npm test + e2e green; per-file coverage gate holds.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions