Spec: Empty addressable content fields with placeholders

[michael]

Here's a proposal for an official recommendation (spec?) to create "empty addressable content fields with placeholders" inside a contenteditable.

Recommended markup for making an element addressable with the caret:

<div contenteditable="true">
  <p><br></p>
</div>

Why?

• the <br> element ensures there's a single addressable caret position. If you added a zero-width-space instead, or any other character, you'd end up with two addressable caret positions.
• most editors are already handling it this way (e.g. ProseMirror <p><br class="ProseMirror-trailingBreak"></p>

To add a placeholder, use an empty class and a placeholder attribute and CSS to display it:

<div contenteditable="true">
  <p class="empty" placeholder="Enter text"><br></p>
</div>

[contenteditable="true"] [placeholder].empty::before {
  color: #ccc;
  content: attr(placeholder);
}

Considerations:

• In my opinion <div></div> without the <br> should not be addressable with the caret.
  • When developing editors very often those leaf-nodes become addressable accidentally. You'd have to write <div contenteditable="false"></div> to avoid that.
  • Already some browsers skip caret positions here, with keyboard movement. See Firefox: Empty fields with placeholder are not keyboard selectable #500
  • however, this may break some existing apps, that rely on <div></div> being addressable (though that doesn't work in all browsers)

Known issues (only related to placeholder rendering/behavior):

• Firefox: Up/Down arrow navigation doesn't work with absolutely positioned elements in contenteditable #523
• Firefox: Cursor is misaligned on centered text with placeholder #501
• Firefox: Clicking a placeholder inside a contenteditable element does not focus the element #502
• Firefox: Up/Down arrow navigation doesn't work with absolutely positioned elements in contenteditable #523
• Safari/Chrome/Firefox: Caret Rendering inconsistent with empty placeholder across browsers #498
• Safari Desktop: Conditional Show/ Hide of br element in contenteditable element make caret disappear #499 (this would become a non-issue if the placeholder rendering issue were all resolved)

[siusin]

Thank you!

We can apply this template for explainers once the group agrees on the problem and the proposed approach.

[johanneswilm]

This looks like it is a proposal for one of the points to be covered by the caret movement spec itself. Let's additonally have this issue with the explainer proposal itself: #529