Question
Does 1.0 reorder the DOM, and what breaks when it does?
Pinegrow reorders. webtweak explicitly does not - the README defers it, and CONTEXT.md records "No structural DOM reordering" as a scope decision. A serious competitor probably has to close that gap, so this ticket decides whether 1.0 does, and what has to change for it to be possible at all.
The collision that makes this a decision rather than a feature.
fingerprint() in overlay/overlay.js is called from save(), not at the moment of the edit - it walks the live DOM when the batch is serialised. Two of the signals it captures are positional:
siblingIndex() returns the element's 0-based position among siblings sharing its tag and classes.selector is an nth-of-type path, which reconcile/SKILL.md describes as "the least trustworthy signal" and restricts to a last-resort tiebreaker.
If a session contains a reorder, save() fingerprints the reordered DOM, while reconcile resolves those fingerprints against source still in the original order. Restyle the second .card, move it above the first, save: the style patch now describes a different element. Reconcile locates something, applies cleanly, and the change lands on the wrong element with nothing to flag it.
So a structural edit is the first edit type that mutates the identity every other patch is built from. Nothing in the Patch model has ever done that.
Resolve:
- Whether 1.0 reorders at all, and if so whether it is sibling-only (move up / move down) or arbitrary reparenting. These are very different problems.
- What a
Patch is when the change is structural. The current shape is a fingerprint plus property/value changes plus an optional media map, and none of those express "this element moved". The shape-creation patch (op: "create" with an anchor) is the only existing precedent for a non-declaration patch and is worth reading as prior art.
- How the
Fingerprint survives its own subject being moved. Options include capturing fingerprints at edit time rather than save time, ordering a batch so structural patches resolve last, computing fingerprints against the pre-edit DOM, or dropping positional signals entirely for batches containing a reorder.
- What happens to a batch that mixes a reorder with restyles of the same element or its siblings. Is that ordering guaranteed, refused, or split into two batches?
- Whether reconcile can even apply it. Reordering rewrites the HTML file, not the stylesheet, which is a write target neither back end has today.
Relationship to the rest of the map. This and Does Tailwind get its own writer are the same question in different clothes: both write to HTML rather than CSS, both break the property/value Patch shape, and both need a Fingerprint that tolerates its subject being mutated. Resolve them with each other in view, or the HTML writer gets designed twice.
Blocked on What the deterministic writer does when it cannot be sure, because the policy for an unresolvable fingerprint has to exist before deciding what to do with one that has been deliberately invalidated.
Graduated from the map's Not yet specified section, where it was recorded as "whether 1.0 closes the structural-reordering gap".
Question
Does 1.0 reorder the DOM, and what breaks when it does?
Pinegrow reorders. webtweak explicitly does not - the README defers it, and
CONTEXT.mdrecords "No structural DOM reordering" as a scope decision. A serious competitor probably has to close that gap, so this ticket decides whether 1.0 does, and what has to change for it to be possible at all.The collision that makes this a decision rather than a feature.
fingerprint()inoverlay/overlay.jsis called fromsave(), not at the moment of the edit - it walks the live DOM when the batch is serialised. Two of the signals it captures are positional:siblingIndex()returns the element's 0-based position among siblings sharing its tag and classes.selectoris annth-of-typepath, whichreconcile/SKILL.mddescribes as "the least trustworthy signal" and restricts to a last-resort tiebreaker.If a session contains a reorder,
save()fingerprints the reordered DOM, while reconcile resolves those fingerprints against source still in the original order. Restyle the second.card, move it above the first, save: the style patch now describes a different element. Reconcile locates something, applies cleanly, and the change lands on the wrong element with nothing to flag it.So a structural edit is the first edit type that mutates the identity every other patch is built from. Nothing in the Patch model has ever done that.
Resolve:
Patchis when the change is structural. The current shape is a fingerprint plus property/valuechangesplus an optionalmediamap, and none of those express "this element moved". The shape-creation patch (op: "create"with ananchor) is the only existing precedent for a non-declaration patch and is worth reading as prior art.Fingerprintsurvives its own subject being moved. Options include capturing fingerprints at edit time rather than save time, ordering a batch so structural patches resolve last, computing fingerprints against the pre-edit DOM, or dropping positional signals entirely for batches containing a reorder.Relationship to the rest of the map. This and Does Tailwind get its own writer are the same question in different clothes: both write to HTML rather than CSS, both break the property/value Patch shape, and both need a Fingerprint that tolerates its subject being mutated. Resolve them with each other in view, or the HTML writer gets designed twice.
Blocked on What the deterministic writer does when it cannot be sure, because the policy for an unresolvable fingerprint has to exist before deciding what to do with one that has been deliberately invalidated.
Graduated from the map's Not yet specified section, where it was recorded as "whether 1.0 closes the structural-reordering gap".