Fix placeholder positioning

[ellatrix]

Alternative fix for #1247.

1. Makes sure boxes are properly wrapped around the placeholder.
2. "Inherits" styling. (Not really, but has same classes and tag.)
3. Does not use :before or :after, so no style conflicts.
4. Editable is easily focusable is empty state.
5. Caret stays in the middle.

Yay! (I think)

[jasmussen]

Hmm. Impressive! Seems to work well for me. 👍 👍

[ellatrix]

It's so silly! Don't know why I didn't think about this earlier.

Added an aria-label too.

[ellatrix]

Fixed some multi-line bugs.

[youknowriad]

Seems to work as intended. Nice work 👍

[aduth]

Curious the a11y impact of having placeholder both as aria-label of the TinyMCE and as the content of the adjacent placeholder node. Should this be aria-hidden perhaps?

[ellatrix]

Good question! What are your thoughts, @afercia?

[aduth]

Wondering if we should include a modifier class here so reading the stylesheet is more obvious the intention on the .blocks-editable__tinymce + .blocks-editable__tinymce styling.

[afercia]

I'm not sure I'm able to fully follow 🙂 not so familiar with this part and with what inline Editables are. One important thing to consider is that contenteditable regions tend to be reported by screen readers as sort of form fields. The behavior differs across screen readers but they understand it's an editable region. Thus, an aria-label gets announced as it was the label of a form field:

NVDA instead tends to announce as editable the actual HTML element, for example it announces:
paragraph editable for the text block
list editable for the list block
text frame editable for the button block (because it's a span)

and it does announce the aria-label. So what happens, in a few words?
There's the risk the visible placeholder text is reported as content of the editable text, so hearing:
Write label ... Write label should be avoided. Hiding it with aria-hidden seems a good idea.

However, I'm not sure we should use Write label… or Write… as aria-label in the first place. They behave like labels of a form field so they will be announced even after users enter some content, for example:

This could be confusing, as the aria-label text in this scenario is not so appropriate. Wondering how to improve the overall way editable regions are exposed to assistive technologies, will open a separate issue.