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
Copy file name to clipboardExpand all lines: spec/SPEC.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,10 +36,10 @@ The FDD container enforces a **Layered Signature Model** inside the `<fdd-contai
36
36
37
37
## 3. The "Self-Saving" Mechanism (Persistence)
38
38
39
-
An `.fdd` file acts as its own state database. Updates to the DOM natively sync back to the originating `.fdd` file on disk via the File System Access API.
39
+
An `.fdd` file acts as its own state database. Updates to the DOM natively sync back to the originating `.fdd` file on disk relying on unified persistence strategies.
40
40
41
-
*When the `.fdd` parser binds a `<textarea name="user-notes.followUp" autosave>` to the local state, a subsequent user edit triggers a local file-write request.
42
-
* The `.fdd` spec advocates for browser vendors to support a "Auto-Save Trust" permission (*"Allow this document to update itself"*).
41
+
***Primary Strategy (File System Access API):** The `.fdd` parser bounds interactive changes to an explicit write-lock approval prompt on execution. If granted, mutable components actively rewrite the local file.
42
+
***Universal Fallback (The Save Pattern):** Because native write-locks are routinely restricted (e.g., Linux sandbox environments), the FDD specification standardizes a uniform "Save Updates" interface. When active edits mutate the DOM, a persistent prompt alerts the user. Committing the save leverages ambient URI hooks to default the OS download to exactly match the originating `.fdd`'s filename and route.
43
43
44
44
## 4. No-JS Security Model
45
45
Since executable scripts are blocked, interactions scale through:
0 commit comments