Close the text attributes menu automatically if the mouse leaves it

As already described in a Bug Report, I dislike that the text attributes menu stays open even if the mouse lefts it.

WHAT DO YOU RECOMMEND?

The text attributes menu should automatically vanish when the mouse leaves it.
(To avoid unintended vanishing, there could be some clearance around the box, for example 20 to 40 pixels.)

HOW COULD IT BE DONE?

See above.

REAL WORLD USE CASES

Less friction!
For example, there is one case with that I’m confronted every day:
I use many accounts for AI generation every day. To login there, I need to copy and paste first the username (one line in an Anytype Page) and after pasting that into the browser, I come back to Anytype to select & copy the password (the line below).
I do that all repeatedly every day, around 30-40 times.

But: because the text attributes menu stays open, it covers the line below the username, the password.
Therefore I need to click that box away. Again and again.
– Sounds not like a big deal, but it is a small friction that sucks over time.

And not only for the described scenario:
Also for the normal work with that box does it matter. For example, when I mark a text fragment and set it to bold, or italic etc. – I can give the text fragment multiple attributes one after the other; yes, that’s good!
But the job is clearly done when I move the mouse far enough out of the text attributes box!
Why does it stay open? What’s the need for the additional click to get rid of it?

That click causes that the cursor’s position is lost.
– I don’t want that, it only adds one avoidable friction more.

RECOMMENDED ALTERNATIVES

If the team doesn’t thing that the idea should become implemented as the standard behavior, then I highly recommend to add a switch into the settings menu so that the user can decide if he likes this behavior, or the standard one.
– There is already such a switch for the side menu; one switch more wouldn’t hurt, wouldn’t it?

ADDITIONAL CONTEXT

According to @Razor it is highly debatable.
But I think my suggestion in the section above (recommended alternatives) ends the debate.
A simple switch in the settings would satisfy every user.
– And to be honest, I don’t believe that anyone would chose the standard behavior if he can have the automatic vanishing option.

I see it parallel to the side menu: when I leave it with the mouse, then my job there is clearly done, therefore I’ve chosen in the settings that it automatically vanishes. No need for an additional click.
And I btw. would wish the same behavior also for:

  1. The main menu on top.
  2. The three dots menu.
  3. The Slash menu in the editor (“/”)
  4. The global search menu.

  5. BUT these all really with some clearance around, to avoid unintended vanishing.
    – Same as it is for the side menu: it vanishes only if the mouse has left it far enough.

I want to point on two additional aspects:

  1. The text attributes menu stays open also when the user scrolls. :-1:
  2. The link menu on the other hand, behaves as I’ve requested for the text attributes menu! :+1:

If the link menu behaves as wanted (it closes automatically when the mouse leaves it) why needs the text attributes menu have another (worse) behavior?

My video shows both:
See how lovely the link menu works and automatically disappears! :+1:
And in contrast to that, the stubborn text attributes Menu that always demands a click outside of it. :-1:

.

  • Please let the text attributes menu behave the same as we know it from the link menu!

@Razor you wrote in the other thread, my request is “highly debatable”.
But why is it not for the link menu “debatable”?

It would still be possible to add more then one attributes to a text selection, because according to my request, the menu would only then disappear when the user leaves it with the mouse.
What disadvantage could that have?
– I see only benefits.

Link menu opens on mouse hover, text menu opens on text selection. No, this behaviour won’t change, it’s standard.

“Standard”?
Only because Notion does it so, it must IMHO not mean that Anytype shouldn’t or couldn’t do it better,
“Standard” doesn’t automatically mean “ideal”.

The whole editor isn’t “standard”.
For example the behavior of the arrow up/down keys (I like it, how they work in Anytype).

– I will not force the topic further, you have spoken. This is only my last two cents in the small hope, you / the team overthinks it once more.