@beyondwork/docx-react-component 1.0.0 → 1.0.1

package/docs/xlsx-react/spreadsheet-editor-ux-guide.md

@@ -1,520 +0,0 @@
-# SpreadsheetEditor UX Guide
-
-## Interpretation of the problem
-
-You want an implementation-ready, repo-ready UX guide for a React-based spreadsheet editor that round-trips modern Excel workbooks reliably: import `.xlsx` (as an OOXML/Open Packaging Conventions package), edit against a runtime-owned canonical workbook state, export back to a package that reopens in recent Excel environments without repair prompts or silent loss of content that Excel considers supported.
-
-This guide has to be honest about v1 scope boundaries. Anything that cannot be safely supported end-to-end (import → runtime edit → export → reopen) must be explicitly classified and surfaced to the user as preserve-only or unsupported-fatal, with an explicit response model (preserve, lock, warn, block, fail) and zero silent dropping. Markup/parts you don’t understand still must be preserved as package artifacts, and the UI must remain a projection of runtime state rather than a React-owned workbook.
-
-The UX must treat spreadsheets as spreadsheets (grid-first, selection semantics, formula inspection vs edit friction, comments/notes navigation, sheet tabs), not as “rich text with cells.” It must also acknowledge Excel’s real-world constraints (limits, naming rules) and the fact that Excel behavior can diverge from the base standard or rely on extensions, so you need to distinguish normative specs from observed Excel behavior and gate export trust accordingly.
-
-## Research plan
-
-I approached this by splitting “correctness” into three layers and using primary/official references wherever possible.
-
-First, establish the normative substrate: `.xlsx` as an Open Packaging Conventions (OPC) package and the SpreadsheetML part graph model (parts, content types, relationships).
-
-Second, map “Excel reality” on top: Microsoft’s published extensions and implementation notes (what Excel adds/extends and where observed behavior varies from the underlying spec), with special attention to areas that commonly trigger Excel repair flows (calc chain/calculation properties, worksheet properties, drawings, etc.).
-
-Third, convert those constraints into UX posture: a grid-centric interaction model, explicit health/trust surfaces, keyboard/accessibility posture aligned with ARIA grid guidance, and a demo/harness model that exercises round-trip gates through realistic fixtures.
-
-## Findings
-
-**Normative substrate: `.xlsx` is an OPC package, not “some XML files.”** OPC defines a package as a container of “parts” connected by relationships, with content types declared and enforced; this is the base model used by Office Open XML file formats.
-
-**SpreadsheetML structure is relationship-driven, and the minimum workbook is still a graph.** A SpreadsheetML document includes a `workbook.xml` that references worksheets via relationship IDs, with each worksheet stored in its own part; and real workbooks commonly include other parts (tables, chartsheets, pivot table definitions, etc.).
-
-**Compatibility requires respect for markup compatibility and extensibility.** OOXML’s markup compatibility mechanisms exist specifically so producers can include newer/unknown vocabularies while allowing consumers with different feature sets to interoperate (e.g., ignorable namespaces, alternate content). This is the formal basis for a “preserve unknown markup” stance rather than “parse what we know and drop the rest.”
-
-**Excel behavior is not just the ISO/ECMA baseline; it also relies on extensions and implementation-defined details.** Microsoft publishes (a) extension specifications for `.xlsx` and (b) implementation notes describing how Office implements and varies from ISO/IEC 29500, explicitly calling out that Office can extend or deviate and that those notes are updated.
-
-**Comments vs notes is a real UX fault line in modern Excel environments.** Excel distinguishes threaded “Comments” (discussion model) from “Notes” (legacy comment model), which affects how you should present annotation features and what you can honestly claim to support in v1.
-
-**Excel has explicit repair/recovery flows that you can treat as the user-visible failure mode for bad exports.** Microsoft documents “Open and Repair” and recovery strategies for corrupted workbooks, which is effectively your compatibility bar: if your export triggers repair prompts, you failed the “host is the standard” requirement.
-
-**Hard constraints affect UX and validation (limits and naming rules).** Excel’s published workbook/worksheet limits are not theoretical; they bound what “safe mode” and “large workbook posture” should mean in practice.
-Worksheet names also have explicit constraints (non-empty, length, forbidden characters), and violating these is a common generator of “unreadable content / repair” scenarios in real ecosystems.
-
-**Calculation state is a common source of round-trip landmines.** The SpreadsheetML model includes calculation properties (e.g., `calcPr`) and an optional calculation chain part (`calcChain.xml`) that records last calculation order; libraries and Excel can react badly to inconsistencies (missing referenced parts, stale chain, etc.).
-Additionally, Microsoft’s implementation notes explicitly document places where Excel uses defaults or behaviors not fully pinned down by the base standard (example: defaults in calculation properties).
-
-**Keyboard and accessibility posture for a web spreadsheet is not optional; ARIA grid guidance is the baseline.** W3C’s ARIA Authoring Practices provide explicit keyboard interaction expectations for grid patterns; if you want a credible “Excel-like” editor on the web, this guidance should shape focus management and navigation semantics.
-
-## Recommended design / decisions
-
-The UX guide below is built around a few non-negotiable decisions that follow directly from the standards/behavior findings and your framing constraints.
-
-The editor must expose a calm “trust and health” contract, because Excel’s native failure mode for structural issues is “repair/remove content,” which users correctly interpret as “data loss risk.” That means: always show whether the session can export safely, and why; never bury preserve-only/blocked/fatal states inside a console log or a tiny badge.
-
-The product should treat “package preservation” as a first-class UX concept: preserved-but-not-editable objects must be visible as objects with identity (not as scary red errors), and edits that would invalidate preserved structures must either be blocked or downgraded to preserve-only with an explicit warning, never silently applied. This is aligned with the OOXML/OPC reality that a workbook is a relationship graph and with markup compatibility’s explicit interoperability intent.
-
-Grid-first UX should be enforced structurally: the grid is the primary visual focus; toolbars and review chrome are secondary and must not turn into a ribbon clone. The formula bar needs to exist (even in v1) because spreadsheets have a persistent tension between “inspect the formula/value” and “edit the formula/value,” and relying solely on inline edit tends to collapse those modes into confusion. This should be framed as explicit “inspect vs edit” modes rather than pretending they’re the same thing.
-
-Accessibility and keyboard support need to be designed, not patched. A spreadsheet grid is fundamentally a grid widget with heavy keyboard navigation; ARIA grid practices should drive the core navigation and focus model from day one, even if some Excel shortcuts are out of scope initially.
-
-Finally, v1 must be honest about calculations and complex features. If you are not implementing a full Excel calc engine, you should not claim “formula correctness.” The UX should clearly communicate what is being shown (stored values vs computed values) and how export will behave (e.g., “recalculate on open” posture) while avoiding any approach that produces workbooks Excel will “repair.”
-
-## Risks and open questions
-
-The biggest product risk is **accidentally shipping “looks fine in our editor, repairs in Excel.”** Excel’s repair tooling exists specifically because small structural mistakes in parts/relationships/calculation state/drawings can make a workbook partially unreadable, leading to removed records or user prompts. Your UX must assume that any such event destroys trust, regardless of how good the web UI felt.
-
-The second major risk is **formula and value truthfulness.** If you edit formula strings but do not compute results, you will be showing either stale cached values or blank results. You can mitigate with a recalc-on-open posture, but you must ensure calculation properties are coherent and you don’t create/retain calc chains in an inconsistent way.
-
-A third risk is **comment model mismatch (Notes vs threaded Comments).** If you partially support one model and accidentally mutate the other’s underlying structure, you can break how Excel interprets the annotations. This is a classic “preserve-only unless fully supported” boundary.
-
-A fourth risk is **Strict vs Transitional and “real world” OOXML variance.** Tooling (including SDKs and producers) can map or normalize namespaces and structures; the ecosystem reality is messy. Your preservation layer needs to be robust to variance and your UX needs to clearly say what you validated vs what you merely preserved.
-
-Open questions you should explicitly decide before “v1 stable UX”:
-- Whether v1 supports any editable form of filters/tables/frozen panes versus preserve-only indicators (these features are common in real workbooks, and the UX must not surprise users either way).
-- Whether v1 supports threaded Comments, Notes, both as preserve-only, or one editable and one preserve-only; and what “review surfaces” mean in that choice.
-- What your official “large workbook safe mode” triggers are, and which interactions are disabled or degraded in that mode (because Excel’s limits and typical workbook scale vary wildly, and web performance failure modes are brutal).
-
-## Concrete deliverable in the requested format
-
-```md
-# SpreadsheetEditor UX Guide
-
-Status: Draft (non-production posture)
-Last updated: 2026-03-28
-Audience: Product + Engineering (editor runtime, UI, QA, certification review)
-
-This document defines the canonical UX for SpreadsheetEditor: an embeddable React component that edits Excel-compatible workbooks through a runtime-owned canonical state. The UI is a projection of runtime state. All changes happen via commands → transactions → commit.
-
-This is not a promise of “full Excel in the browser.” It is a promise of honesty, preservation, and export trust.
-
----
-
-## Purpose
-
-SpreadsheetEditor exists to:
-- Allow safe, high-confidence edits to XLSX workbooks in a web host without breaking Excel reopen behavior.
-- Provide a grid-first editing experience that respects spreadsheet interaction semantics (selection, ranges, formulas, sheets).
-- Preserve unsupported content as package artifacts with explicit user-facing health/trust signaling.
-- Offer one embeddable React component with a typed public API, where React does not own workbook truth.
-
-Non-goals:
-- Building a ribbon clone.
-- Implementing the full Excel calculation engine in v1.
-- Claiming fidelity for features that cannot round-trip safely.
-
----
-
-## Product posture and v1 support boundaries
-
-### Support levels (must be explicit in UI and API)
-- Supported: Import → edit → export → reopen is covered by automated + manual gates.
-- Preserve-only: Imported and preserved byte-for-byte (or semantically preserved) but not edited; shown in UX as “present but not editable here.”
-- Locked: Data is editable only where allowed (e.g., protection, policy). UX blocks prohibited edits with explanation.
-- Blocked: Operation is not allowed because it risks breaking the file or violating policy; user can still inspect and export unchanged.
-- Fatal: File cannot be safely loaded into runtime (or cannot be exported) without risking corruption; editor refuses or enters read-only “recovery view.”
-
-### Export trust posture
-Export is never “just a download button.”
-Export is a trust contract:
-- If export is allowed, the editor states what it guarantees (and what it does not).
-- If export is blocked, the editor states exactly why and what the user can do (if anything).
-
-### v1 honesty defaults
-Unless explicitly listed as Supported, treat workbook features as Preserve-only.
-If a feature is common and risky (charts/pivots/drawings/macros/protection variants), default to Preserve-only or Locked until proven safe.
-
----
-
-## UX layers and internal interfaces
-
-### Host framing layer (owned by the embedding app)
-Responsibilities:
-- Routing, navigation, and file/session selection.
-- Auth, tenancy, and policy (what is allowed to be edited/exported).
-- Storage/IO: loading bytes, saving bytes, versioning, collaboration orchestration (if any).
-- Displaying global banners/modals that are not editor-specific (e.g., org-wide incident banners).
-
-Host must treat SpreadsheetEditor as a pure component:
-- The host provides a file (bytes/stream) and receives events, commands, and exported bytes.
-- The host does not mutate the workbook directly.
-
-### Editor layer (SpreadsheetEditor component)
-Responsibilities:
-- Parse/load into runtime canonical workbook state (or refuse with Fatal).
-- Maintain canonical state (runtime-owned), including preservation registry for unknown parts.
-- Project state into UI view models.
-- Offer command API and transaction model.
-- Provide health/trust surfaces and export gating.
-
-### Routes (for demo harness / workspace shell)
-Suggested harness routes:
-- /spreadsheet                (library / session list)
-- /spreadsheet/:fixtureId     (opens a known fixture workbook)
-- /spreadsheet/:docId         (opens a host-provided document id)
-- /spreadsheet/:docId/compare (optional: compare last export vs original)
-
-Routes are harness-only. The shipped product is a single embeddable component.
-
----
-
-## Screen anatomy
-
-The editor UI is intentionally simple and grid-centric.
-
-Recommended layout:
-
-[Top bar]
-- File name + save/export status
-- Health/Trust chip (calm, always visible)
-- Minimal primary actions (Undo/Redo, Export)
-
-[Formula zone]
-- Name box (active cell reference, e.g., A1) + optional range size indicator
-- Formula bar (view/edit formula/value)
-- Function hint / validation messages (inline, unobtrusive)
-
-[Main zone]
-- Grid (primary focus)
-  - Row headers
-  - Column headers
-  - Cell canvas (virtualized)
-- Sheet tabs (bottom)
-- Optional right side panel (secondary)
-  - Comments/Notes
-  - Health report
-  - Preserve-only inventory
-
-[Bottom status bar]
-- Selection summary (count/sum/avg if implemented)
-- Mode indicators (Edit mode, Safe mode, Read-only, Filter present, etc.)
-
-Rules:
-- Grid is always the visual priority.
-- Side panels never steal the center; they can collapse.
-- Warnings are calm and actionable, not alarming unless truly fatal.
-
----
-
-## Session inventory
-
-A “session” is the unit the host and editor talk about. The session model must be visible in the UI (status, health) and explicit in the API.
-
-Session includes:
-- Source: file id, filename, extension, last loaded timestamp
-- Workbook identity: package fingerprint (hash), internal workbook id (runtime)
-- Editability: read/write, policy locks, protection locks
-- Health state: aggregated level + list of issues
-- Preserve-only inventory: counts by feature type (e.g., charts, pivots, drawings)
-- Performance mode: normal vs Safe mode, and why
-- Dirty state: pending changes vs committed changes, last commit id
-- Export plan: whether export is allowed; if allowed, export warnings and known changes
-- Diagnostics bundle id (optional): for support and reproducibility
-
----
-
-## Interaction rules
-
-### Focus and modality
-The editor has two primary modes:
-- Navigate/select mode: arrow keys move the active cell; shift extends selection; grid is in control.
-- Edit mode: typing edits the cell content (inline) or formula bar content (explicit), with clear entry/exit.
-
-Rules:
-- There is always exactly one active cell.
-- There is at most one primary selection (a range).
-- A selection can be:
-  - Single cell
-  - Range
-  - Entire row(s)
-  - Entire column(s)
-  - Entire sheet (optional; usually via corner cell)
-
-### Selection behavior
-- Click cell: active cell set, selection = that cell.
-- Drag: selection expands to rectangle range.
-- Shift+click: expands selection to rectangle between active cell anchor and target.
-- Ctrl/Cmd+click: v1 default is “replace selection” (multi-range selection is optional and must be explicit if supported).
-- Header click:
-  - Row header selects row.
-  - Column header selects column.
-- Sheet tab click selects sheet; preserves last active cell per sheet.
-
-Selection must never mutate the workbook. Selection only updates view state.
-
-### Copy/paste behavior (v1 safe default)
-- Copy/paste inside the editor is supported for values + basic formulas + basic formats (only if formats are Supported).
-- Pasting external content (from system clipboard) is “best effort” and must never:
-  - silently drop data
-  - create invalid workbook state
-If paste cannot be represented safely, block with explanation and offer to paste as plain text.
-
-### Undo/redo
-Undo/redo is command-driven:
-- Every edit command yields an undoable transaction.
-- UI must show that undo/redo affects workbook state, not just the UI.
-
----
-
-## Toolbar principles
-
-Design principles:
-- Minimal, task-oriented, not a ribbon.
-- Default to “common spreadsheet edits,” not formatting power-user operations.
-- The toolbar is context-aware but not context-exploding.
-
-Recommended v1 toolbar groups:
-- Edit: Undo, Redo
-- Insert: Row, Column (only if safe)
-- Format (optional v1): Bold, Italic, Number format (very small subset)
-- Data (optional v1): Sort (simple), Filter indicator (edit may be out of scope)
-- Review: Comments/Notes panel toggle, Health panel toggle
-- Export: Export button with trust status (and dropdown for “export with warnings” only if needed)
-
-Rules:
-- Any action that could break preserve-only content must either be blocked or must upgrade the health state with explicit warning before commit.
-
----
-
-## Grid and formula bar behavior
-
-### Grid is primary editing surface
-- Single-click selects.
-- Double-click enters inline edit.
-- Typing when in navigate mode starts inline edit (unless policy blocks).
-
-Inline editor:
-- Shows raw formula text if the cell has a formula.
-- Shows displayed value if the cell is a value cell.
-- Provides lightweight validation feedback (e.g., “Invalid reference” as warn, not as hard fail, unless it breaks export).
-
-### Formula bar is primary inspection + precise edit surface
-Formula bar supports:
-- Always-visible display of the active cell’s raw content:
-  - If formula: show formula text.
-  - If value: show value representation (string/number/date formatting depends on Supported formatting).
-- Explicit edit mode:
-  - Enter starts editing the formula bar content.
-  - Escape cancels edits.
-  - Commit occurs on Enter, with clear visual confirmation.
-
-Tradeoff posture:
-- Inline edit is fast.
-- Formula bar edit is precise and better for long formulas.
-UX must make it clear which one you’re doing.
-
-### Inspect vs edit “conflict” rule
-When the user is inspecting a formula (e.g., a read-only preview state), do not auto-enter edit mode. Require explicit action (double-click or Enter) to edit. This prevents accidental edits during audit/review use.
-
----
-
-## Comments, review, and health surfaces
-
-### Comments/Notes panel
-A single panel that can show:
-- Threaded Comments (if Supported or Preserve-only view)
-- Notes (legacy) (if Supported or Preserve-only view)
-v1 may support:
-- Read-only list + navigation (scroll to anchor cell)
-- Add/edit only for the comment type that round-trips safely
-
-Navigation:
-- Next/previous comment traversal jumps active cell.
-- Panel clearly labels whether comments are editable or preserve-only.
-
-### Health / Trust panel (always available)
-The Health panel is the user-facing representation of your preservation + export contract.
-
-It must list:
-- Issues grouped by severity: Preserve-only, Locked, Warn, Blocked, Fatal.
-- For each issue:
-  - What it is (plain language)
-  - Where it is (sheet/cell/object)
-  - What the editor will do (preserve/lock/warn/block/fail)
-  - Whether export is allowed and what will happen in Excel
-
-Calm tone rules:
-- Preserve-only is not an error. It’s “present, unchanged.”
-- Warn is “may change behavior,” not “you broke it.”
-- Block/Fatal are rare and must be specific.
-
-### Preserve-only inventory surface
-Non-cell features (charts, pivots, images, drawings, external links, advanced tables, advanced protection, etc.) should appear as inventory items with:
-- Type
-- Count
-- Location (sheet)
-- Behavior: Preserved unchanged; not editable here
-- Risk: whether certain edits could invalidate them (if known)
-
-Do not render fake versions of these objects in v1. Use placeholders and honesty.
-
----
-
-## Warning, preserve-only, blocked, and fatal states
-
-### State definitions (UX contract)
-- Preserve-only:
-  - UI: neutral info badge + panel entry.
-  - Behavior: preserved through export unchanged as long as edits do not require rewriting those parts.
-- Locked:
-  - UI: lock icon in relevant surfaces; editing actions disabled with explanation.
-  - Behavior: protect workbook integrity and policy compliance.
-- Warn:
-  - UI: yellow/calming indicator + details on demand.
-  - Behavior: allow edits but surface tradeoffs; export allowed with warning note.
-- Blocked:
-  - UI: action disabled; explicit reason and alternative (if any).
-  - Behavior: prevent unsafe edit/export transitions.
-- Fatal:
-  - UI: refuse to enter edit session OR open in “recovery view” (read-only) with diagnostics.
-  - Behavior: no export unless “export unchanged” is proven safe.
-
-### Export gating rules (v1)
-- Allowed:
-  - Supported + Preserve-only issues only.
-- Allowed with warnings:
-  - Warn issues present but not known to trigger repair; still requires explicit acknowledgment in UI.
-- Blocked:
-  - Any blocked or fatal export issues.
-- Fail:
-  - Export attempt produces invalid package; must be treated as a bug with a diagnostics bundle.
-
----
-
-## Keyboard and accessibility posture
-
-Baseline posture:
-- Keyboard-first navigation must be usable.
-- Screen reader semantics must be coherent.
-
-Minimum keyboard set:
-- Arrow keys: move active cell
-- Shift+arrows: expand selection
-- Enter: move down (navigate mode) / commit (edit mode)
-- Tab: move right (navigate mode), with sheet boundary behavior defined
-- F2 (optional) or Enter: enter edit mode
-- Escape: exit edit mode / dismiss panels
-- Ctrl/Cmd+C/V/X: copy/paste/cut (subject to safety rules)
-- Ctrl/Cmd+Z/Y: undo/redo
-
-Accessibility requirements:
-- Grid uses an ARIA grid strategy with stable focus rules (“roving” focus, not thousands of tabbable cells).
-- Active cell is always announced.
-- Selection changes are announced in a throttled, non-spammy way.
-- High contrast + zoom must not break selection affordances.
-
-Out of scope in v1 unless proven:
-- Full Excel shortcut compatibility
-- Complex screen-reader formula auditing workflows
-
----
-
-## Large workbook safe mode
-
-Safe mode exists to prevent browser death spirals and to preserve trust.
-
-Trigger examples (implementation-defined):
-- Extremely large sheet dimensions or used-range sizes
-- Too many styles/conditional formats
-- Huge shared string tables
-- Complex objects inventory beyond rendering budget
-
-Safe mode UX:
-- Persistent indicator: “Safe mode (performance)”
-- Clear list of disabled/limited interactions:
-  - e.g., limited formatting, limited multi-sheet operations, disabled external paste, reduced reflow
-- No surprise: The user should know what’s limited before they run into it.
-
-Safe mode is not “read-only.” It is “reduced capability with safe export.”
-
----
-
-## Demo / harness framing
-
-The demo harness is part of the product’s credibility. It should behave like a workspace shell and expose health/trust clearly.
-
-Harness requirements:
-- Fixture library (bundled workbooks) that cover:
-  - clean/supported workbooks
-  - preserve-only heavy workbooks (charts/pivots/images)
-  - calculation-heavy workbooks (formulas)
-  - protection-locked workbooks
-  - large-workbook safe mode triggers
-- Each fixture page shows:
-  - “What this proves” statement
-  - Expected health state
-  - Expected export result (reopen gates)
-- Export from harness stores:
-  - original bytes
-  - exported bytes
-  - diff summary (parts changed)
-  - “opened in Excel” manual checklist results (tracked by QA)
-
----
-
-## Mapping to the final component
-
-SpreadsheetEditor (React component) mapping rules:
-- The React component owns rendering + input dispatch.
-- The runtime owns:
-  - canonical workbook state
-  - preservation registry
-  - transaction log
-  - validation and export pipeline
-
-Public API principles:
-- Typed commands, not ad-hoc callbacks.
-- Events are observable, not mutation hooks.
-- Host can:
-  - load bytes
-  - subscribe to session state + health
-  - issue commands (edit cell, insert row, etc.)
-  - request export
-  - receive structured results (success + warnings or blocked/fatal)
-
-Required API surface (conceptual):
-- load(inputBytes, options) -> session
-- getStateSnapshot() -> { viewModel, health, inventory }
-- dispatch(command) -> transactionResult
-- export(options) -> { bytes | blocked | fatal, report }
-- on(eventType, handler) / subscribe(selector)
-
----
-
-## Review checklist (v1 readiness gates)
-
-UX gates:
-- Grid remains primary focus; toolbars/panels don’t overwhelm.
-- Health/Trust is always visible and understandable.
-- Preserve-only content is visible, calm, and non-panicking.
-- Blocked/fatal states are explicit and actionable.
-- Safe mode messaging is persistent and honest.
-- Keyboard navigation is usable; focus never gets lost.
-
-Architecture gates (UX-relevant):
-- UI never mutates workbook directly; all changes are command→transaction→commit.
-- Unsupported content is never silently dropped.
-- Export is gated by health state, not by “it probably works.”
-
-Compatibility gates:
-- Exported files reopen in recent Excel environments without repair prompts for all Supported fixtures.
-- Preserve-only fixtures reopen with preserved content present and unchanged (as defined by the fixture expectations).
-- Any repair prompt in Supported fixtures is a release blocker.
-
-Documentation gates:
-- Each supported feature has:
-  - definition
-  - known failure modes
-  - preserve-only fallback rule
-- Each preserve-only feature has:
-  - visible UX surfacing
-  - “what this means” explanation
-```
-
-## Sources
-
-publishes ECMA-376 (Office Open XML file formats), describing OOXML vocabularies and packaging as a standard reference point for producers/consumers.
-
-/ publish ISO/IEC 29500-2 (Open Packaging Conventions), defining the package/parts/relationships model that underlies `.xlsx` as an OPC container.
-
-provides official Open Specifications for Excel’s `.xlsx` extensions and Office implementation notes, which are crucial for distinguishing spec-level correctness from “Excel correctness” (what Excel actually writes, reads, and varies).
-
-Microsoft’s Open XML SDK documentation provides authoritative implementation-oriented descriptions of SpreadsheetML structure, worksheet relationships, markup compatibility concepts, and calculation chain concepts used by ecosystem tooling.
-
-Microsoft Support documentation establishes real-world Excel constraints and failure modes that should directly shape validation, UX gating, and “export trust posture,” including workbook repair flows, worksheet naming rules, and workbook limits.
-
-ARIA Authoring Practices (APG) provides the baseline keyboard interaction guidance for grid widgets, which should shape spreadsheet navigation/focus models in a web UI.