Repository navigation
Block focus when a note is selected can feel too much like spotlight mode #72860
Description
While testing the Notes feature, I kept feeling like I was stuck in Spotlight Mode. I checked the options for my editor, but that mode was not enabled. This is likely being made worse by #72858
confusion-with-spotlight-mode.mov
The current way a block is highlighted when an attached note is focused feels perfect for when spotlight mode is enabled, but otherwise it doesn't quite feel right. Many times the surrounding context for a given block is important. But with the surrounding content faded out, it's impossible to consider the block in context.
For example, maybe a note mentions that "this paragraph should probably be moved before or combined with the previous one." In this case, you need to be able to actually read the preceding block.
Activity
Mamaduka commentedon Oct 31, 2025
It's a temporary Spotlight mode.
cc @jasmussen
jasmussen commentedon Oct 31, 2025
Good one, and I would agree that this one and #72858 feel very related. The spotlight mode is important to visually connect a note with its related block. This is less critical to have in the most common test cases of a document, but try it with a complex pattern, for example a gallery with 9 small squares, then comment on the second one from the left, suddenly it becomes extra important to be absolutely sure the relationship between your note and the selected block.
Let's walk through the trunk behavior so we can discuss when it's the right time to apply it:
Given the above, I feel like we are very conservative with applying spotlight given its importance. I'd honestly apply it also to the case when you are adding a comment (1 and 2). But let me know if this captures the matrix of cases, and what your thoughts are.
Edit: pressed a ⌘Enter combo that posted my comment early and unfinished.
t-hamano commentedon Oct 31, 2025
This behavior was fixed in #72870, and the blocks are now spotlighted.
6b8d86429cae69bc7c01287b9a0775d4.mp4
[-]Block focus when a note is selected can feels too much like spotlight mode[/-][+]Block focus when a note is selected can feel too much like spotlight mode[/+]desrosj commentedon Oct 31, 2025
Thanks for pointing that out. It makes a lot of sense that the block needs to be indicated as active somehow, especially with how common it is to have nested blocks.
Stepping back, I've been trying to open issues of two types:
For this one, I would say summarize my stance as:
jeffpaul commentedon Nov 3, 2025
Worth noting that in Google Docs they apply a yellow-ish highlight around content when selecting a comment, which I don't think we'd want to do something quite that... obvious... in the editor.
However, I think there might be a bit of a compromise between the concerns/confusion that @desrosj is calling out here and the purposeful design that @jasmussen is describing where perhaps we utilize the blue block outline when selecting the block's respective note.
This already happens when using the editor's List view where hovering over different blocks in the List View applies the blue outline around the respective block. When similarly hovering over notes in the notes sidebar or the floating notes view, the respective block gets the blue block outline treatment as well.
However, its the spotlight mode treatment that gets applied to the respective block when clicking a specific note in the notes sidebar or the floating notes view. Since we're not applying spotlight mode when clicking a block in the List View, perhaps we also do not apply spotlight mode when clicking a block in the notes sidebar or the floating notes view?
Screen.Recording.2025-11-02.at.9.08.15.PM.mov
t-hamano commentedon Nov 3, 2025
As I recall, previously, notes were simply stacked one on top of the other in order, and their positions didn't align with the blocks. This spotlight feature was proposed to clearly show the relationship between the blocks and the notes.
However, now, with the floating sidebar, the connection between the blocks and notes is much stronger.
Perhaps this spotlight feature can now be removed. What do you think?
jasmussen commentedon Nov 3, 2025
The instinct is entirely valid. And it's one of the reasons in future iterations of this feature, the selection is clearly marked on the block itself. The gaze at the future I summarized here suggests for text higlights, the specific passage of text is marked (
<mark>), with active and inactive states. Those mockups also suggest a blue overlay for non-text blocks. That of course assumes inline text selection is possible to comment on, which it won't be in the near term, but the first iteration of block notes suggested in that case to mark all the text of the paragraph:Notably this style is not a blue block outlined, so as to not conflate the feature with block selection or focus. In that sense, an overlay would be next in line, the main challenge there is that it simply doesn't work that well with text blocks.
In any case, those are the instincts for visually delineating which blocks have notes. Let me know if that makes sense.
joedolson commentedon Nov 3, 2025
I second that this issue really needs improvement. As @desrosj mentions, when you're making comments that are relative to other content, it's crucial that the other content is readable and contextually available.
I'd really rather see the active block highlighted (like @jasmussen mentions) than see the other blocks diminished.
I don't think that the floating comments is sufficient to remove need for visual highlighting; while that is helpful, for low-vision users using screen magnifiers it won't be significantly relevant.
15 remaining items
adamsilverstein commentedon Jul 15, 2026
Thanks for clarifying - that makes perfect sense to me. I don't mind the spotlight mode and your defense of it is helpful.
The extra spotlight highlighting gets a little more complicated when we allow selections that span multiple blocks, but I think its doable. I started working on this enhancement in
adamsilverstein commentedon Jul 20, 2026
@desrosj Please review the comment above from @jasmussen. His suggestion is that this is working as expected. What do you think?
joedolson commentedon Jul 20, 2026
I still think that while there is a need for highlighting the relevant block, this is not the best mechanism for it. As I said in my first comment, I think this fails to consider the need to be able to read other blocks while authoring a comment. If your comment is on a specific paragraph, but requires reference to other blocks, you need to be able to see and read those blocks, as well. For that reason, I think that the highlighting needs to change to keep the clarity about which item is being commented on, but without removing access to other content.
adamsilverstein commentedon Jul 20, 2026
You make a compelling point. I see we have both the spotlight effect of dimming other blocks and a blue outline for the selected block. I will work on a PR that keeps the blue outline and removes the spotlight effect (dimming) so we can review it to see if that is enough.
Somewhat related: since we enabled inline selection in this release, we now have another highlight mechanism: the colored highlighting:
(the color is keyed to the user Avatar color as well.)
I wonder if we should highlight the entire block when a note is at the block level (as if the user had selected the entire block)? I can work on a PR to try that.
I checked the behavior in Google docs:
result: the nearest word was selected and my comment is on that selection.
adamsilverstein commentedon Jul 20, 2026
I posted a PR that drops the background, keeping only the outline:
adamsilverstein commentedon Aug 5, 2026
Removing this from the 7.1 board since we didn't land on the right solution yet; we can revisit for 7.2.
Notes: lock in that selecting a note does not dim the canvas