The Gold Standard of Websites | Preserving Editors’ Work When a Save Uses an Outdated Version

A save can succeed at the server while still producing the wrong result for the people editing. The service has accepted a complete document, but that document may accidentally remove a change made after the editor opened it.

Imagine a fictional notice with three fields: start time 09:00, room Blue, and admission free. Ana and Bo both open this notice. Ana changes the time to 09:30 and saves. Bo changes the room to Green in the older copy and then saves that complete copy.

If the second save replaces the current notice without checking its starting point, the resulting notice says 09:00 and Green. Bo intended to change the room, yet the operation also restored the old time. Ana’s work is lost from the current document even though neither editor asked to delete it.

The important evidence is the sequence of states and operations. A screenshot of the final page cannot show which edit disappeared or why. Likewise, two successful save messages do not prove that both intentions survived.

Start the investigation with a concrete question: which content did each editor see, what did each intend to change, and what was actually stored? That separates a concurrency problem from a typing error, an incorrect fact or a delayed public display.

Contents · Next chapter

An editor’s screen contains a working copy. The server holds a current stored version. These can diverge while a person is reading, thinking or writing. Neither copy automatically tells the whole story.

For the first exercise, call the shared starting document B, the local proposed document L, and the latest server document R. The letters mean base, local and remote. They are learning labels, not a required implementation format.

The base tells us what the editor started from. The local copy tells us what that editor proposes. The remote copy tells us what is currently stored. A useful review needs all three relationships, especially when another editor has changed something in the meantime.

If you compare only L and R, you can see that they differ, but not always which differences were deliberate new changes. The base helps distinguish Bo’s room correction from the unchanged old time still present in Bo’s copy.

A website may store this information in revisions, an editing session or a different suitable mechanism. The reader-facing task remains the same: protect the person’s proposed work and show enough context to resolve the mismatch.

Do not describe an unsaved local copy as already published. A clear interface distinguishes work on this device, a stored draft, an accepted revision and the public page when those states are different.

Contents · Previous chapter · Next chapter

Write the original example as a timeline before discussing any header or database feature. This keeps the mechanism understandable to an editor as well as a developer.

The final state contains Bo’s intended room change and an unintended time reversal. Calling the result last save wins describes the replacement rule. It does not establish that the last saver had the best information or intended to overrule the earlier change.

Now change the order. If Bo saves Green first and Ana later saves her whole copy, the final page can say 09:30 and Blue. The same design now loses Bo’s room correction. The problem follows the overlap, not a particular person’s carelessness.

An independent check compares the final result with the stated intentions. A result preserving both compatible changes would say 09:30 and Green. That target helps us evaluate a proposed solution without assuming that every automatic combination is always appropriate.

Contents · Previous chapter · Next chapter

A conditional save says, in effect, apply this proposed replacement only if the current representation still matches the one I started from. If another accepted change has made that starting version outdated, the condition fails.

HTTP provides a standard mechanism through entity tags and the If-Match request header. RFC 9110, section 13.1.1 defines this precondition and its use in preventing accidental overwrites. An entity tag is a validator for a representation, not the editor’s judgment about its quality.

In our fictional service, the original notice has a strong tag called notice-a. Ana and Bo both receive that tag with the same base content. Ana submits her proposal with the condition that notice-a is still current. It is, so the service accepts her change and issues a new tag, notice-b.

Bo’s proposal still carries notice-a. When it reaches the service, notice-b is current. The mismatch prevents the old-based replacement. Ana’s accepted time remains in place while Bo’s room correction remains available for review.

This example uses readable tag names to make the sequence visible. Real tags are opaque values supplied by the service. A client should preserve and return the relevant value rather than infer its meaning, generate a replacement from a local clock, or assume that alphabetically later tags mean newer content.

Contents · Previous chapter · Next chapter

Checking the current version and then saving later is not enough if another change can slip between those two actions. The comparison must govern the actual change at the point where it is committed.

Imagine Bo first asks whether notice-a is current and receives yes. Before Bo’s replacement is applied, Ana saves and creates notice-b. If Bo’s later write does not enforce the condition again, the earlier check has not protected Ana’s work.

The fictional service therefore treats matching the expected version and accepting the replacement as one protected decision. Another writer cannot change the relevant stored representation between a successful comparison and the corresponding update. The exact technical implementation depends on the service.

This is a useful boundary between browser behaviour and server responsibility. Refreshing the editor more frequently can reduce how often people work from old content. It cannot, by itself, remove the final race between a read and a write.

The existing database transactions guide develops the underlying concurrency mechanisms and their guarantees. This lesson follows the website author’s experience: a version check is useful only when the service actually makes the requested change conditional on it.

For a learner, insert an extra writer between every separate check and save in the proposed timeline. If that writer can still be silently overwritten, the design has left a gap in the protection.

Contents · Previous chapter · Next chapter

A detected conflict should give the editor a route forward. A technical error code alone does not explain what happened to the content they just wrote or what they should do next.

In our fictional interface, the message says that the page changed after it was opened, the proposed changes have not replaced the current page, and the local work is still available in the editor. It then offers a comparison with the latest version. Those statements must match the service’s actual storage behaviour.

MDN's If-Match reference explains the usual 412 Precondition Failed response when the condition does not match. The human-facing message should translate that state into a useful next action, rather than expect an editor to know the protocol.

Preserving a draft also needs an honest scope. Kept in this tab differs from saved on the server. A website should not promise recovery after a browser crash unless that recovery is genuinely supported and checked. Where work has only local protection, say so clearly.

Avoid an automatic page reload that replaces the editor’s text before it can be recovered. A service can detect an outdated version correctly and still fail the person by destroying the proposal during recovery. Test both the server result and the editor’s retained work.

Contents · Previous chapter · Next chapter

Return to Bo’s interrupted room correction. The base B says 09:00 and Blue. Bo’s local L says 09:00 and Green. The remote R, after Ana’s save, says 09:30 and Blue.

Comparing B with L reveals Bo’s intended change: Blue became Green. Comparing B with R reveals the intervening change: 09:00 became 09:30. The unchanged old time in L should not automatically be interpreted as Bo’s deliberate request to restore 09:00.

The candidate result preserves both changes. It should still be reviewed for meaning and any surrounding requirements. A three-way comparison identifies edits; it does not know whether Green is suitable at 09:30 or whether the event details are factually correct.

For a small document, a clear field-by-field comparison may be enough. For a long article, the interface may need section-level context, highlighted changes and a readable way to move between them. The appropriate presentation depends on the editor’s task and the content’s structure.

Ask another learner to explain why the old local time was retained in the proposal. If they call every local difference from the current version an intentional override, return to the base comparison.

Contents · Previous chapter · Next chapter

Now change the case. Ana changes the time from 09:00 to 09:30, while Bo changes the time from 09:00 to 10:00. The base-to-local and base-to-remote comparisons both identify a change to the same field, with different proposed results.

There is no general rule that the later message, longer text or newer device clock identifies the correct time. The service should preserve both proposals and ask the appropriate editor to resolve the meaning using the relevant event information.

A good conflict view shows the base and the two changes clearly. It should not hide one proposal behind an apparently finished combined document. The person making the decision needs to understand what would be kept and what would be replaced.

Sometimes both editors changed a field to the same value. That may permit a straightforward combination, but the application still needs to preserve the correct current state and version relationship. A matching string does not establish that every other field or side effect agrees.

For a learner exercise, provide three variants: different fields, the same field with the same new value, and the same field with different new values. Ask what can be combined mechanically and what needs a factual decision. Then ask what wider constraints could still make even the mechanically compatible result unsuitable.

The aim is controlled resolution, not turning every overlap into a large manual investigation.

Contents · Previous chapter · Next chapter

Different fields can combine into a result that violates a real constraint. This is why a clean textual merge is not a complete correctness check.

Suppose the base notice says Room Blue at 09:00. Ana changes the time to 09:30 because Blue becomes available then. Bo changes the room to Green because Green is available at 09:00. A mechanical field merge yields Green at 09:30.

The text changes do not overlap, but imagine that the supplied booking record says Green closes at 09:15. The combined result is now invalid. Each editor’s original proposal may have been reasonable against a different assumption; the merged pair still needs the booking constraint checked.

Keep the constraint explicit: the selected room must be available for the complete event interval. Checking only its opening instant may miss the same problem if the session continues after closing. The content’s meaning determines what validation is needed.

A version condition on the notice alone does not necessarily protect a separate booking record that can change independently. The service needs an appropriate design for those related resources and responsibilities. Do not claim that one header guarantees every fact across the whole application.

The independent check is therefore semantic as well as structural. Read the resulting notice as a visitor would, then compare its claims with the actual governing information. Preserving edits is necessary; publishing a coherent result is the next task.

Contents · Previous chapter · Next chapter

After Bo reviews the latest notice and prepares a candidate preserving 09:30 and Green, the next save should be based on the current version used in that review. It should not simply repeat the rejected replacement with the old condition removed.

In the fictional sequence, Bo reviews notice-b and submits the combined candidate conditional on notice-b still being current. If nobody else changes the notice, the save can be accepted and a new current version created.

If another editor changes it first, the condition fails again. That can be frustrating, but silently overriding the newer work would defeat the protection. The service should preserve the reviewed proposal and support another proportionate comparison.

Do not solve repeated conflicts with an invisible retry loop that keeps fetching the latest tag and attaching it to the unchanged old document. That would turn a version guard into a formality while continuing to overwrite intervening changes.

A deliberate overwrite may be an authorised decision in some systems. It should be presented honestly, with enough context to understand which current changes will be replaced. Ordinary recovery should make preserving compatible work the understandable path, rather than forcing the editor to choose between losing their draft and erasing someone else’s work.

For a learner, point to the exact base used for each save attempt. If they cannot identify it, the proposal’s relationship to the current content is still unclear.

Contents · Previous chapter · Next chapter

A failed condition and an uncertain network response are different states. In the first, the service reports that the supplied precondition prevented the replacement. In the second, the client may not know whether a request reached the service or whether the response returned.

Imagine Ana’s save was accepted, but the connection dropped before the acknowledgement reached her editor. The server holds the new content while her screen still says that the outcome is uncertain. Repeating a save without checking can create confusing messages or additional effects in systems whose operations do more than replace text.

The service should reconcile the actual saved state using its documented operation and version behaviour. It may need request identity, revision records or another appropriate mechanism. Version checking and retry identity solve related but different questions: did the representation change, and is this the same attempted operation?

RFC 9110 permits a success response in certain cases where a requested change appears already applied despite a failed precondition. That exception is not permission for a client to assume success whenever it loses contact. The application still needs enough evidence to describe the result accurately.

For the editor, the practical message should distinguish not accepted from not yet confirmed. Keep the proposed work available until the state is resolved. A reassuring message is useful only when it corresponds to what the service actually knows.

Contents · Previous chapter · Next chapter

A website may allow changes through a visual editor, an import tool, an API, an administrator screen and an automated task. A version-aware editor cannot protect the current content from a separate writing route that ignores the relevant condition.

In our fictional service, Ana and Bo use conditional saves. A nightly importer then replaces the notice from an older spreadsheet without the same protection. Their collaboration can still be overwritten. The final service behaviour depends on every route capable of changing the same content.

This does not mean all routes must use identical interfaces. They need compatible guarantees about the shared resource and a clear policy for deliberate replacements. A controlled import can be appropriate, but its source, scope and effect should be understood rather than hidden behind a generic success message.

Test an ordinary edit against each relevant competing writer. Confirm whether the expected version is checked at the actual update and what happens when it is stale. Include metadata if the operation can replace it along with the body.

Also distinguish content revisions from display delays. A public cache might temporarily show an older page even after a protected save succeeded. That is a separate observation requiring its own check; it should not be confused with evidence that the stored update was lost.

The useful question is end to end: can any authorised path silently replace newer relevant work under the service’s stated rules?

Contents · Previous chapter · Next chapter

A recovery interface should explain what changed, what remains saved and what action is available. It should preserve readable labels and clear focus behaviour as well as the text itself.

For example, a comparison might label three panels starting version, your proposed changes and current saved version. The editor can review the candidate result before confirming it. Avoid relying only on red and green highlighting to distinguish deletion and addition; text and structure should carry the meaning too.

W3C WAI’s Error Suggestion explanation describes providing known correction suggestions for detected input errors within its stated scope. The original recovery pattern here applies the broader reader-first idea that an unsuccessful action needs an understandable next step. It is not a claim that one conflict screen establishes accessibility conformance.

Test the task with appropriate methods and representative ways of navigating. Can the person discover the conflict, reach the comparison, preserve their proposal, choose a resolution and understand the result? A developer seeing the error in a console does not answer those questions.

Keep the options proportionate. A short notice may need a simple comparison. A long document may need section navigation and a clear final review. The interface should help the person recover their intended change without demanding that they understand every implementation detail beneath the save.

Contents · Previous chapter · Next chapter

Website content often contains more than plain paragraphs. Headings, tables, image descriptions, references and section anchors can carry meaning or behaviour. A merge that preserves visible words while breaking those relationships can still damage the page.

Suppose Ana adds a new chapter with an anchor, while Bo updates a contents list in an older copy. A combined document needs the chapter and a correct link to it. Keeping both text fragments without checking the destination can leave the navigation misleading.

Likewise, a table correction must preserve the association between headers and values. An image description should still match the intended image. A copied block wrapper may contain attributes that the editor expects to remain consistent with its saved markup.

Use the content model appropriate to the system rather than treating every document as an undifferentiated string. A text comparison can help reveal changes, but the final review must check the resulting structure and supported editing behaviour.

The existing section-link continuity guide owns the deeper problem of bookmarks, chapter moves and splits. Here it is a connected final check after resolving overlapping edits.

For a learner’s exercise, merge one paragraph correction and one contents update, then follow every affected link. Ask whether the result works for the reader and remains understandable to the next editor, rather than stopping when the comparison tool reports no textual conflict.

Contents · Previous chapter · Next chapter

After a resolution is accepted, retrieve the actual stored content through the appropriate service path. Compare it with the reviewed candidate and check the relevant metadata. A successful response is useful evidence, but the resulting state is what the next reader and editor will use.

For Ana and Bo’s compatible edits, verify 09:30, Green and free admission. Also verify that unrelated text remains present. An incomplete replacement can preserve the two changed fields while accidentally deleting a paragraph that nobody intended to remove.

Then check the public presentation when publication is part of the task. A stored draft, an accepted published revision and a visitor’s displayed page are distinct states. Describe which one has actually been verified.

Keep a proportionate revision record identifying the base, accepted result and material resolution. This supports later correction if the factual choice turns out to be wrong. Do not treat revision history as a substitute for preventing avoidable overwrites; recovery from a lost change can still cost time and trust.

An independent reviewer can work from the stated intentions rather than the implementation. Ask whether both compatible corrections survived and whether the result makes sense. That check is valuable because it can detect a technically successful save that preserved the wrong proposal.

The final evidence should answer a human question: can both editors recognise what was kept, and can the visitor rely on the resulting notice within its stated scope?

Contents · Previous chapter · Next chapter

Begin with a fictional workshop page whose base says start 14:00, capacity 20 and room Oak. Editor C changes capacity to 24. Editor D changes the room to Pine. C saves first, creating a new version.

D then submits a complete replacement based on the old page. Under an unconditional replacement, what final values would appear? Which accepted change would be lost? Under a correctly enforced conditional save, what happens to D’s first attempt?

Next, build the candidate from the three versions. Preserve C’s capacity correction and D’s room correction. State which current version should be the base for the next save attempt.

Now add a constraint from the supplied room record: Oak holds 24 people, but Pine holds at most 18. Does a clean field-by-field merge produce an acceptable page? Explain what must be resolved before publishing the workshop details.

Finally, consider another writer changing the start time to 14:30 after D reviews the current page but before D’s next save reaches the service. What should the condition do? Why would fetching the newest tag and attaching it to an unchanged older document be insufficient?

Answer in states and reasons, not only status codes. The task tests whether you can preserve editing intentions, maintain the version relationship and detect a meaning-level conflict that text separation alone cannot solve.

Contents · Previous chapter · Next chapter

Under unconditional replacement, D’s old-based complete page says 14:00, capacity 20 and room Pine. C’s accepted capacity 24 disappears. D intended a room change, but the full replacement also carried an outdated capacity.

Under the fictional conditional service, D’s first attempt is rejected because its expected base is no longer current. The candidate that preserves both textual intentions says 14:00, capacity 24 and Pine. Its next save must depend on the current version D actually reviewed.

However, Pine’s supplied limit is 18. The candidate’s capacity 24 is incompatible with that room. The appropriate editor must resolve the factual plan, such as choosing a suitable room or revising the capacity through the real event process. The exercise does not establish which option is preferable.

If another writer changes the time after D’s review, the next condition should prevent D’s stale replacement. Fetching only a fresh validator without reviewing and integrating the changed content would remove the evidence connecting the proposal to its base.

The learning outcome is a complete explanation: detect the outdated version, preserve the proposal, resolve the actual meaning, and check the resulting state.

Contents · Previous chapter · Next chapter

The repair route uses a two-field paper notice and two editors. Let both work from the same starting copy, then simulate whole-document replacement. Seeing one correction vanish often makes the problem clearer than beginning with protocol terminology.

The stabilisation route adds version labels, a conditional acceptance rule and three-way comparison. Ask learners to identify the base for every attempt and the exact point where the service accepts or rejects it. Then add a third writer between review and save.

The extension route introduces related resources, uncertain acknowledgements, structured content and competing write paths. Keep each guarantee specific. A single representation validator should not be presented as protection against every external change or every kind of duplicated action.

For a maintenance review, use fictional content in an appropriate test environment. Reproduce a bounded sequence, record the expected result, inspect the stored state and test the recovery experience. Avoid experimenting on live shared work merely to demonstrate that it can be overwritten.

Students should leave able to explain the relationship between a draft, its base and the current saved page. Developers and service owners should also identify which parts their implementation guarantees and which still depend on review. That shared vocabulary makes collaboration easier when a save is interrupted or rejected.

Contents · Previous chapter · Next chapter

Does an outdated version mean the editor did something wrong?

No. Content can change while someone is working normally. The service should anticipate that ordinary overlap and provide a useful recovery path.

Does refreshing just before saving solve the problem?

It can reduce staleness but leaves a race if another change can occur before the write. The condition must govern the actual update.

Does an ETag identify who is correct?

No. It identifies a representation for validation. It does not establish factual accuracy, authority or the right resolution of a disagreement.

Can any ETag be used with If-Match?

If-Match uses strong comparison; a weak validator does not satisfy that comparison. Use the service’s documented supported mechanism rather than inventing a substitute.

Are different-field edits always safe to combine?

No. The room-and-time and room-and-capacity examples show constraints that cross field boundaries. Review the meaning of the candidate result.

Should every 412 trigger an automatic retry?

No. Preserve the proposal and reconcile the relevant current state. Blindly attaching a fresh validator to old content can overwrite the very changes the condition was meant to protect.

Does revision history make conflict prevention unnecessary?

No. History may help recover work, but recovery can still be difficult. Prevention, clear recovery and final-state verification serve different purposes.

Contents · Previous chapter · Next chapter

Reader tasks and durable content

Return to the Websites root for the full service journey. Use Keeping Section Links Meaningful When Chapters Move for navigation continuity after a merge. Content Accessibility Governance Services connects publishing responsibilities with checked updates.

Technical mechanisms and recovery

Database Transactions, Atomicity, Isolation and Concurrency develops the underlying write guarantees. Accessible Online Form Design Services examines completable interactions and clear feedback. Accessible Website Maintenance Services develops continuing verification.

Primary documentation and learning transfer

RFC 9110, section 13.1.1, MDN's If-Match reference, the historical W3C Editing the Web note, and WAI's Error Suggestion explanation were checked on 22 October 2026. The W3C editing document is a 1999 discussion note; the current protocol explanation here follows RFC 9110. All page states, proposed interfaces and exercises are original teaching models, not a tested implementation or a conformance claim.

Continue into Education: learning that transfers into life and How X Works. A dependable save preserves more than bytes: it gives people a clear way to keep, reconcile and verify the work they intended to contribute.

Contents · Previous chapter · Return to Websites