Restore hiding drop cap on focus to prevent bugs with contenteditable

[ellatrix]

Description

Fixes #6273.

This behaviour seems to have been dropped by accident in #1418. Not sure why, but maybe @BE-Webdesign recalls this PR?

We can't show the drop cap when the user is editing the paragraph for some reasons:

• You cannot move the caret around it.
• Chrome (maybe others) fails to calculate the caret position with range.getClientRects(), which causes errors and things that rely on that such as the link inserter and writing flow to break.
• Typing seems broken in different ways in different browsers. Chrome and Safari seem to insert characters in the wrong position, and additionally Safari just overwrites the last character when the caret is at then end.

I know this isn't a nice solution, but it's all I can come up with at the moment. These CSS rules and contenteditable just don't seem compatible and I've not found a way to make it work. I'm unsure if there's any way we can let the user know that the block has a drop cap while the editable field has focus. Cc @jasmussen.

How has this been tested?

Ensure the above points work fine.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[ellatrix]

I removed this line because it seems to have just been taken over from the editable CSS, where it targeted a different element. I don't know why this line was needed back then and if it still does anything now, but it seems unlikely. It should have been commented.

[ellatrix]

Maybe we could try to add the drop cap in JavaScript instead... Extract the letter, but it in an element and align it. Maybe worth trying in a separate PR.

[jasmussen]

I feel like it is totally totally fine to not show the dropcap when you're typing. I can't imagine we can make the typing experience feel very good with a dropcap there, contenteditable bugs or not. Dropcap is inherently a decorative element, usually something you apply after the fact. And finally, it is completely according the design guidelines, that the selected block can change appearance to surface buttons or controls or change layout. It is the unselected block that should be a preview of the end result. As such, just from a design POV, this seems completely fine to do.

[youknowriad]

LGTM 👍

Only glitch I saw (but not sure how to fix) is if the paragraph is the last in the post and you click under the paragraph, it flickers because the focus is moved out and back to the paragraph.

[mcsf]

This makes the drop cap usable in Safari but I'm still seeing this, which hopefully we can address in this very PR:

1. Select a plain Paragraph block; type in it.
2. With the mouse, toggle drop cap attribute. The decoration is added, even though the block is selected. The caret also remains roughly where it was in the RichText.
3. Now, type some more: you'll still experience the parent issue.
4. To fix, deselect and select the block.

[ellatrix]

it flickers because the focus is moved out and back to the paragraph

The focus back in is intended, not sure how to avoid the flicker either, we'd probably have to prevent moving focus away at all.

Thanks for reviewing!

I love that you can just use an emoji as a drop cap haha.

I can already predict a future where we'll have tons of posts with giant emoji in front of paragraphs on the internet. Cc @pento.

[ellatrix]

@mcsf Sorry, I caught your comment too late... I can't reproduce this issue though. As soon as I start typing in Safari, the drop cap disappears for me. Not sure what is going on with the :focus selector in your case. :/

[ellatrix]

Here's what I get:

[ellatrix]

@mcsf I can reproduce now, but I have to start with a brand new block as you suggested, which makes it even stranger.

[ellatrix]

I'm unsure atm what we can do about tis...

[lsinger]

Should clicking outside of the text area blur the cursor, possibly?

[ellatrix]

@lsinger Yeah, that sounds like the right behaviour. It should blur the text field, but keep the block selection.

[lsinger]

that sounds like the right behaviour

I wonder though whether it would be the right behavior only in this specific case or whether that still holds true in the general case. 🤔

[ellatrix]

Focus should normally move to the drop cap switcher, as it does correctly in Chrome.

[ellatrix]

Focus behaviour in Safari is very different... you can't move focus to every focusable element by default. Just tab through the blocks and you'll see a big difference in behaviour. Cc @afercia.