w3c / w3c/editing

Speccing placeholders

Open
#503 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
HTML
Stars
202
Forks
43
PR merge metrics
No merged PRs in 30d

Description

Over the years I've spent an enormous amount of time related to issues with rendering placeholders inside a contenteditable. There are lots of solutions that work in one situation but not in others. I've been searching and finding a solution, but at the price of many workarounds.

I was wondering, if it would make sense to spec a best-practice solution for in-flow placeholders that don't break editing, and ensure that all browsers support it, without requiring workarounds.

Here's example of different placeholders in https://svedit.dev.

Image

I have the following requirements:

  • should work with any markup/styling and must be rendered in flow (position: absolute hacks are not solving the general issue)
  • support multi-line placeholders
  • should work with centered text (cursor is rendered centered too, i.e. the cursor is where the first character would appear when typing)
  • The empty field should remain keyboard addressable despite the placeholder

My current solution works like this:

.editable [placeholder].empty::before {
	color: #ccc;
	content: attr(placeholder);
}

.editable [placeholder].empty.focused br {
	display:none;
}
<div class="editable" contenteditable="true">
  <h3 class="field empty" placeholder="Heading 3"><br></h3>
  <h3 class="field empty focused" placeholder="Heading 3"></h3>
  <h3 class="field empty" placeholder="Heading 3"><br></h3>
  <h3 class="field empty" placeholder="Heading 3"><br></h3>
</div>

Notice, that I dynamically add a focused class, once a field gets selected and the br is removed. The reason is that placeholder rendering doesn't work reliably when there's a br tag inside. E.g. the cursor gets rendered at the wrong position (e.g. after the placeholder in Chrome). The br is needed to make the element addressable with cursor-keys. However the br is not needed if you have a placeholder (except in Firefox).

See: #498, #499, #500, #501, #502

Would be amazing if the issues could be fixed, and I could document a recommended way of how to use placeholders in contenteditable.

I will follow up with a first proposal soon.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing related issues #498, #499, #500, #501, and #502, then examine the contenteditable placeholder examples at svedit.dev and the CSS/HTML shown here. A completed proposal should define a browser-supported, in-flow placeholder approach that handles multiline and centered text, preserves keyboard addressability, and avoids the described br and cursor-position workarounds.

Written by the indexing model from the issue text.

Assessment

Tech stack
css, html
Domain
frontend, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.