[Experimental] Notes: Support partial text selection notes #74852
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Mamaduka
added
[Type] Experimental
|
Size Change: -160 B (-0.01%) Total Size: 3 MB
ℹ️ View Unchanged
|
Mamaduka
force-pushed
the
try/inline-text-notes
branch
from
b0d2ea4 to
39f5b84
Compare
Contributor
|
Thanks for working on this! I'm very happy to know that we can achieve basic functionality with just the annotation package and less code. I think one of the advantage to use annotation is that texts with notes can be partially overlapped. With the Format API, this behavior should not be possible: 
I think this may be confusing. This is because the second and subsequent notes are treated as replies to the parent note, and it is not clear which text the note is in response to. 
One idea I have is to add new metadata to distinguish inline notes from block notes, for example: <!-- wp:paragraph {"metadata":{"noteId":1, "selectionNoteIds":[2,3,4]}} -->
<p>Hello World</p>
<!-- /wp:paragraph -->The dropdown UI might look something like this: 
Let's get more feedback from folks about whether this approach is doable. |
Member
|
Annotations are meant to be continually re-evaluated. A use case is spelling or tone checking and stuff like that. I'm not sure if it's a good fit for notes. If we're currently anchoring block notes to blocks, then we should probably also anchor inline notes to the text? |
Member
Author
Requested design feedback in the issue - #59445 (comment). Using the parent-child system makes it easy to maintain the relationship between notes. Depending on the design, it can change. @ellatrix, I think a big plus for annotation format is that we don't store markup in the DB, and it won't be displayed on the front. Avoiding extra markup was mentioned a couple of times in the tracking issue, though I'm not sure if we can. Another problem I can think of with permanent markup is that, when collaboration features ship and we introduce inline suggestions, we might have to change our approach to inline notes again, making old markup obsolete. As I mentioned in the description, this PR is mainly an experiment. I wanted to get something out with the Annotations API and see what you folks think about :) |
Contributor
This is what I originally used to implement partial text selection notes in "asblocks". I run into a lot of issues though, things like needing to keep the "pointers" (start, end...) of each annotation in sync when the user make changes... IMO it results in an implementation that is too complex. I agree that not storing markup in the DB is a pro of this approach but I have found the props of the alternative approach to be stronger:
For its downsides (DB storage), a simple |
Member
|
The thing is also that we already went down the path of storing comment IDs in the block comment (in the same db post). I don't think it's ideal, but there's no great alternatives other than maybe storing a Yjs edit. Stripping the block comments is pretty similar. You're right that we should think about suggestions before committing to an approach. Not sure what's best there. Maybe the thing you comment on would be replaced by the content you comment (certain comment type or meta). When you only want to add content, we could store an empty span at the location to insert. |
Member
|
@Mamaduka - thanks for working on this! 🎉 On the topic of placement and storage, have we considered the suggestion from @westonruter to use something like xpath? One challenge with the current approach of storing the note id on the block is that makes adding a note a content change that requires a post save to be stored. Leading to bugs like notes not being saved for new unsaved posts (#72717). One other note: when we implement this we should probably update the floating logic to ensure notes float next to the top of the selected next, not the top of the block as in the current approach. |
Member
Some more inspiration would be text fragments, where the text span is included in the reference, with optional prefix and suffix. This essentially would opt for substring references instead of numeric indices. The problem remains for how to keep such referenced updated as the underlying text changes (or blocks are added, removed, and re-ordered). |
Contributor
|
Noting that I shared some designs, for your consideration, here: #59445 (comment) |
Member
Author
|
@adamsilverstein, @westonruter, I'm not very familiar with XPath/XPointers. IIRC, you could use them in Puppetter for targeting elements, but that's the end of my experience. I think both will have similar problems as @youknowriad described above. We'll have to update/sync references when the selected text changes, which would also require saving, so I don't think that would resolve the issues mentioned in #72717. We'll just have a problem with different content types being out of sync or not saved. |
Member
Thanks for the link, I didn't realize that was a standard. That approach seems better than xpath for this use case.
I agree there is quite a bit of added complexity to this approach, perhaps there is a hybrid approach where block attributes link to the notes, but notes themselves contain the Text-fragment link. On clear advantage of not storing note ids in blocks would be eliminating the issues we currently have with block duplication, syndication and splitting.
One way around this would be to expand the noteId stored in block meta to an array, enabling multiple linked notes per block. |
Mamaduka
force-pushed
the
try/inline-text-notes
branch
from
39f5b84 to
757d8cc
Compare
Member
I think this is actually fine as-is, and I believe is also how Google Docs handles this scenario, as the comment can (though I agree may not) still relate to the overall selection of text so I don't think it would make sense to remove the inline comment if text within the selection were to change. |
Member
Author
|
@jeffpaul, I think you found a different bug 😄 If you remove parts of the marked text, save the content, and then refresh the page, the issue becomes visible. P.S. I'm working on an alt PR that uses RichText formats, and hope to have it read soon for initial feedback. ScreenshotCleanShot.2026-02-02.at.18.47.24.mp4 |
Mamaduka
force-pushed
the
try/inline-text-notes
branch
from
757d8cc to
43785b2
Compare
This was referenced Feb 2, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Related #59445.
Important
This is an exploration PR for the technical side of this feature and doesn't include anything from design specs.
PR tests the ability to add notes for partial selections within a block's rich text fields. This works without adding content markers to the DB (see annotations package).
How?
@wordpress/annotationspackage.Challenges
Testing Instructions
Testing Instructions for Keyboard
Same.
Screenshots or screencast
CleanShot.2026-01-22.at.16.08.32.mp4