Don’t let the browser do anything that has some relevance to the database (like generating IDs). Very bad idea. People will use this to send trash data just to see what happens.

Let it send the text, then split into elements, preferably by line endings, you may or may not get those <p> tags. Then let the controller generate ID’s for them.

But all in all this sounds complicated and I would just do what most other forums do in similar situations quotes within the answering text:

This is one approach I have found, but I was hoping to either get some feedback or alternative ways to accomplish <Nix>

Maybe add the name of the quoted user. Maybe a “parent” link that shows the original text (similar to Reddit).

I think your concept of having unique IDs per paragraph, with the comments stored separately, is pretty solid. But, like you mention, you are stuck with the problems of users editing their posts.

If you have the revision history of the posts maybe the comments could stay with a particular revision.

You could use a diff tool or a Levenshtein distance calculation to help you decide what happens with a comment. You still have to deal with the questions: Should the comment still stay if a paragraph has been edited? Should the comment be deleted if the paragraph is deleted? etc. But having the work done by a diff tool for example may simplify things for you as it should be able to simply tell you if a line is added, deleted, or modified.

Keeping it simple, if you don’t know what has happened to an edited text either delete the comments or convert them from a comment on a specific paragraph to a comment on the whole post (if this is possible).

This algorithm that I recommend depends on maintaining the data model for the operations in your database and using that model to generate the interfaces and the links in the reading mode of the document, rather than allowing direct editing of the main document. A link-based approach in the rendered (not editing) view allows someone to participate in the comment workflow without actually letting them edit the main document directly; you can just use textareas or input fields in the popover or new page-based form for these interactions. I’ve used this approach for department-wide reviews.

Clicking on a paragraph may not be an obvious behavior for new users. When you generate the id for a comment-worthy component (be it paragraph, list item, blockquote, or such), consider adding a superscripted link at the end with a clear label or icon that invites clicking for interaction. Then either pop over a window with your form, or open a new page (depending on accessibility preferences) to accept that input, keyed to that generated id. You’ll have to index that stored comment by the document id and the corresponding component id.

For rendering the comments, when a component has a new comment, you can add a new “see comments”-style link following that original “comment here” link; again, this added link can either pop up a window with the dialog (since it could be one or more contributors) keyed to that component, or link to endnote-style comments displayed conventionally beneath the document. Extra credit for adding disposition controls within each component’s group of comments that track how you have used or dismissed the suggestions!

How do you keep all this review interfacing separate from the clean document content itself? For HTML source, I’d keep just the id/name attribute on the components themselves and add the review links at display time based on walking the document tree and applying the links into the DOM before the rendition. I typically have an XML-based source so I use an XSLT template to recognize these nodes and add the markup during the conversion into the HTML result tree. Either way, your original source remains free of comment/review markup except when it is in a view that you intend to allow commenting in. You can turn off this added step when the review is over or when commenting is closed.