is-hovered css class application quirks

[jameskoster]

Whilst working on #27271 I noticed a couple of strange instances where the is-hovered class it not correctly applied. The first one is block placeholders, please observe:

I added a red outline to highlight the elements that seem to block the class being added. Interestingly, hovering the elements inside those elements does not seem to block the class being added.

A similar thing happens with link blocks in the navigation block:

cc @jasmussen

[jasmussen]

Excellent GIF usage. Definitely helpful for debugging.

[jeyip]

After doing some digging:

• useBlockProps implements the useIsHovered hook here and here
• useIsHovered adds event listeners one of which includes mouseout
• the issue we're seeing can be characterized by this blurb:

mouseleave and mouseout are similar but differ in that mouseleave does not bubble and mouseout does. This means that mouseleave is fired when the pointer has exited the element and all of its descendants, whereas mouseout is fired when the pointer leaves the element or leaves one of the element's descendants (even if the pointer is still within the element).

Using the navigation link as an example, when we hover over text, even though it's clearly a child of the navigation link <li> tag, mouseout is still triggered. This is because, even though the pointer is still within the <li> tag, it is technically "mousing out" of the current element and mousing over a new element (its descendent).

Using mouseleave instead of mouseout seems like a promising alternative, but the general behavior of editor hover states and hover outlines changes noticeably. I'm not sure if these changes make the experience better or worse, but I'll spin up a PR for folks to play around with.