You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Inkspan bundles offline Korean, Japanese, Simplified/Traditional Chinese, Vietnamese, and Latin typography, but bundled fonts alone do not establish reliable multilingual input or mobile support. Enterprise and public-sector buyers need an explicit, evidence-backed browser/device/input-method support matrix rather than a general multilingual claim inferred from typography.
Protected main is the only shipped-source authority. Draft #201 is the existing standalone-editor source owner for composition/read-only/controlled-value semantics; stacked Draft #380 is the existing browser-harness/spec/config owner for multilingual input assurance. Their mutable heads, bases, checks and lifecycle state must be refetched live before action rather than copied into this issue.
Current ownership and already-covered active-PR scope
Do not create competing writers for these boundaries:
Draft fix(data-integrity): keep controlled value sync atomic #201 owns production CwlEditor composition behavior. Its active-PR contract drains a local composition before edit authority is revoked and defers controlled host value replacement during composition until composition ends, applying only the latest host value.
Draft test(input): add multilingual browser input baseline #380 owns browser harness/spec/config evidence only. Its active-PR contract makes committed *.browser.spec.ts journeys discoverable by Chromium, Firefox and WebKit and exercises synthetic multilingual/CJK/grapheme composition, native-form serialization, active-composition teardown/remount, read-only clipboard, touch/pointer/focus geometry and reflow behavior. It does not re-own fix(data-integrity): keep controlled value sync atomic #201 production source.
Those active-PR behaviors are not protected-main shipped truth until their dependency-ordered stack integrates under then-live governance.
Standards basis
W3C Input Events Level 2 defines composition-related beforeinput / input behavior and remains a Working Draft: https://www.w3.org/TR/input-events-2/
WCAG 2.2 SC 2.5.7 applies where Inkspan owns drag interactions and requires an appropriate non-drag alternative unless an exception applies.
These references define standards context; they are not evidence that a specific Inkspan source generation passes the requirement.
Remaining product contract
Maintain an accepted ADR and public support statement that explicitly covers:
composition lifecycle ownership and observable callback behavior;
treatment of intermediate composition text in onChange, serialization, autosave candidates and collaboration updates;
controlled-value updates during composition;
undo/redo grouping for committed composition text;
remote collaboration updates near a local composition range;
focus/selection behavior when toolbar controls or dialogs are activated;
touch/pen toolbar operation, selection, scrolling and image/table controls;
supported desktop/mobile browser and physical-device/input-method profiles;
fully tested, periodically tested, emulated-only, known-limited and unsupported classifications.
Preserve browser/TipTap/ProseMirror composition semantics where they are authoritative rather than introducing an incompatible custom text model.
Remaining executable assurance
Real input-method semantics
Use committed synthetic phrases and deterministic expected documents for at least Korean 2-set Hangul, Japanese kana/kanji conversion, Simplified/Traditional Chinese phonetic candidate selection, Vietnamese diacritics, mixed Latin text, emoji, combining marks, variation selectors and adjacent grapheme clusters.
Where browser automation cannot faithfully drive the OS candidate UI, do not fabricate IME proof from synthetic DOM events. Keep synthetic composition coverage as component/browser contract evidence and add a documented authorized physical-device or remote-device lane for the support claim itself.
Exercise supported composition in paragraphs, headings, list items, table cells, links, marks, code blocks where supported and around inline images.
Transaction and lifecycle interactions
Cover at minimum:
composition start/update/end without loss, duplication or reordering;
controlled value refresh during and after composition;
autosave coalescing plus strong-revision capture without pairing an intermediate document with the wrong validator;
undo/redo before, during and after committed composition;
toolbar/dialog interaction while composing;
host read-only transition and unmount/remount;
remote Yjs insertion/deletion near the local composition range under host-owned provider authority;
paste/drop and safe-link/image policies adjacent to composition;
SSR hydration and native-form serialization;
stale revision restore/conflict behavior.
No test may treat DOM presence of intermediate composition text as evidence of durable save, collaboration acknowledgement, authorization or persistence success.
Browser, mobile and accessibility assurance
Preserve exact packed-package desktop Chromium/Firefox/WebKit evidence for applicable buyer journeys.
Add accepted mobile viewport/touch/pointer journeys for Chromium and WebKit without representing emulation as physical-device IME proof.
Before claiming iOS Safari or Android Chrome support, retain periodic authorized real-device evidence with OS/browser/input-method/device-or-runner/package hash/fixture hash/exact source identity.
Keep production text, user dictionaries, tenant content, credentials and private keyboard telemetry out of artifacts.
Verify toolbar/dialog/table/image/review controls remain operable without hover and under narrow viewport, zoom/reflow and virtual-keyboard conditions.
Meet WCAG 2.2 SC 2.5.8 target-size/spacing or retain exact exception evidence; where Inkspan owns drag behavior, meet SC 2.5.7 or document the applicable exception.
Keyboard, touch, switch and screen-reader interaction must not be mutually exclusive.
Acceptance criteria
Close only after the resulting exact protected generation proves all applicable requirements:
a published support matrix distinguishes fully tested, periodically tested, emulated-only, known-limited and unsupported profiles;
committed multilingual fixtures reach the expected canonical document without lost, duplicated, reordered or prematurely persisted text;
composition plus autosave/revision evidence cannot associate an intermediate/stale document with the wrong strong validator;
supported collaboration-near-composition behavior is deterministic or fails visibly without silent re-anchoring;
undo/redo behavior for supported language/input paths is documented and tested;
mobile/touch journeys prove target-size/spacing, focus, orientation, zoom/reflow and no-hover behavior;
physical iOS/Android support claims are backed by authorized real-device evidence rather than Playwright emulation alone;
applicable exact coverage, public API documentation, package, browser, accessibility, security, SAST and governance gates pass on the exact protected lineage.
Ownership / lifecycle boundary
Priority: P1 product correctness and accessibility. Work may proceed while stable-release acceptance #118 is open, but README/support claims must not broaden beyond exact protected evidence.
Before any #201/#380 lifecycle action or this issue's closure, refetch protected main, exact parent/child heads and live bases, ancestry/mergeability, changed paths/active writers, live rules/permissions, formal reviews/threads, and every applicable repository/central workflow job with actual checkout/source identity. Pending, queued, skipped-required, cancelled, absent, neutral, failed, stale, predecessor, status-only, model-only, wrong-checkout, synthetic-source-only, undiscovered-test or emulation-only evidence is non-passing for a claim that requires more.
Do not self-approve, transfer parent/predecessor evidence, weaken gates, create a competing production/browser writer, force-push/destructively rebase, invent physical-device evidence, or represent active-PR behavior as protected-main shipped truth.
Buyer-visible product gap
Inkspan bundles offline Korean, Japanese, Simplified/Traditional Chinese, Vietnamese, and Latin typography, but bundled fonts alone do not establish reliable multilingual input or mobile support. Enterprise and public-sector buyers need an explicit, evidence-backed browser/device/input-method support matrix rather than a general multilingual claim inferred from typography.
Protected
mainis the only shipped-source authority. Draft #201 is the existing standalone-editor source owner for composition/read-only/controlled-value semantics; stacked Draft #380 is the existing browser-harness/spec/config owner for multilingual input assurance. Their mutable heads, bases, checks and lifecycle state must be refetched live before action rather than copied into this issue.Current ownership and already-covered active-PR scope
Do not create competing writers for these boundaries:
CwlEditorcomposition behavior. Its active-PR contract drains a local composition before edit authority is revoked and defers controlled hostvaluereplacement during composition until composition ends, applying only the latest host value.*.browser.spec.tsjourneys discoverable by Chromium, Firefox and WebKit and exercises synthetic multilingual/CJK/grapheme composition, native-form serialization, active-composition teardown/remount, read-only clipboard, touch/pointer/focus geometry and reflow behavior. It does not re-own fix(data-integrity): keep controlled value sync atomic #201 production source.Those active-PR behaviors are not protected-main shipped truth until their dependency-ordered stack integrates under then-live governance.
Standards basis
beforeinput/inputbehavior and remains a Working Draft: https://www.w3.org/TR/input-events-2/These references define standards context; they are not evidence that a specific Inkspan source generation passes the requirement.
Remaining product contract
Maintain an accepted ADR and public support statement that explicitly covers:
onChange, serialization, autosave candidates and collaboration updates;Preserve browser/TipTap/ProseMirror composition semantics where they are authoritative rather than introducing an incompatible custom text model.
Remaining executable assurance
Real input-method semantics
Use committed synthetic phrases and deterministic expected documents for at least Korean 2-set Hangul, Japanese kana/kanji conversion, Simplified/Traditional Chinese phonetic candidate selection, Vietnamese diacritics, mixed Latin text, emoji, combining marks, variation selectors and adjacent grapheme clusters.
Where browser automation cannot faithfully drive the OS candidate UI, do not fabricate IME proof from synthetic DOM events. Keep synthetic composition coverage as component/browser contract evidence and add a documented authorized physical-device or remote-device lane for the support claim itself.
Exercise supported composition in paragraphs, headings, list items, table cells, links, marks, code blocks where supported and around inline images.
Transaction and lifecycle interactions
Cover at minimum:
valuerefresh during and after composition;No test may treat DOM presence of intermediate composition text as evidence of durable save, collaboration acknowledgement, authorization or persistence success.
Browser, mobile and accessibility assurance
Acceptance criteria
Close only after the resulting exact protected generation proves all applicable requirements:
Ownership / lifecycle boundary
Priority: P1 product correctness and accessibility. Work may proceed while stable-release acceptance #118 is open, but README/support claims must not broaden beyond exact protected evidence.
Before any #201/#380 lifecycle action or this issue's closure, refetch protected main, exact parent/child heads and live bases, ancestry/mergeability, changed paths/active writers, live rules/permissions, formal reviews/threads, and every applicable repository/central workflow job with actual checkout/source identity. Pending, queued, skipped-required, cancelled, absent, neutral, failed, stale, predecessor, status-only, model-only, wrong-checkout, synthetic-source-only, undiscovered-test or emulation-only evidence is non-passing for a claim that requires more.
Do not self-approve, transfer parent/predecessor evidence, weaken gates, create a competing production/browser writer, force-push/destructively rebase, invent physical-device evidence, or represent active-PR behavior as protected-main shipped truth.