Start with a disposable notice
On the host Mac, open a copy of the HTML file in SubEthaEdit. Keep the maintained project file outside this first exercise. Use a small fictional notice whose expected changes are easy to recognize:
<!doctype html>
<html lang="en">
<meta charset="utf-8">
<title>Workshop collection</title>
<h1>Equipment collection</h1>
<p>Collect at the courtyard desk on Thursday.</p>
<p>Bring your booking reference.</p>
</html>
Agree on the edit before inviting the other person. In this exercise, the host changes “Thursday” to “Friday,” and the participant changes “courtyard desk” to “main reception.” The final sentence should be:
Collect at the main reception on Friday.
This fixture lets you detect a disconnected session or a second, unrelated copy without using private client text.
Invite a participant and verify access
Use the application's document-sharing controls to invite the second SubEthaEdit user. Its official collaboration description covers local-network connections, participant invitations, permission changes, and following another person's position in the document. It also distinguishes local-network use from internet sharing, where its described setup requires port forwarding.
Begin on the same permitted local network. If a remote participant cannot connect, inspect that connection path. Have both participants open the native application and keep the connection available throughout the exercise; a browser preview link serves a different purpose.
Before making substantive changes, have the participant select the sentence and confirm the host sees the activity. Check the participant's current permission and whether editing is allowed. If someone should only observe, adjust their access and verify the result with that participant rather than relying on the invitation's wording.
Make separate edits, then compare the joined sentence
Have the host change the day first. Once both people see “Friday,” the participant changes the collection point. Read the whole sentence aloud or copy it into your conversation. That catches an accidental deletion that change highlighting alone can miss.
SubEthaEdit documents change highlighting and following participants. Use those features to locate a change, then inspect the resulting HTML structure. Colored text identifies activity; it does not establish that tags remain balanced or the notice makes sense.
For a real editing session, divide the work by identifiable sections: one person corrects the collection instructions while another checks the contact paragraph. If both need to rewrite the same sentence, agree on the wording before continuing to type. Concurrent editing does not resolve a disagreement about the content.
Save and reopen the source that will be maintained
Choose one person to own the final file path. After both edits are visible, that person saves the agreed document and reopens it from disk. Confirm the combined sentence survives reopening. If another participant saves a copy, identify it as a separate copy; matching windows during the session do not prove every disk file has been updated.
Then inspect the HTML in the application's documented live web preview or your normal browser. The official site describes preview reloads when referenced CSS or JavaScript files are saved, but those dependencies still need their own files and correct paths. Sharing the notice text does not establish that a participant also has the project's images or stylesheets.
Close the editing session with a clear handoff
Record the maintained filename, the agreed wording, and who will move it through the project's usual review or publication process. End or restrict the shared session when collaborative editing is finished.
If the next person only needs to review a rendered page and reply, collaboration outside your usual tools covers that different task. Keep the editable source handoff explicit so a reading copy does not become an accidental second master file.