Html: Reasoning for `contenteditable` as a global attribute?

[scottaohara]

I'm curious to know what the use case was for including contenteditable as a global attribute. Specifically, I'm curious per its behavior when used on interactive elements, or on elements within interactive elements.

Used on a button

<button contenteditable="true">
    I'm editable
</button>

On mouse click, an event will fire and as long as focus isn't moved from the button (e.g. by opening an alert) a user can start retyping the text of the button. If someone uses the space or enter key, as one is to do when typing, in Firefox and Chrome events on the button will continue to fire.

Firefox, Chrome and Safari all allow for different levels of editing as well. For example, Firefox will let someone enter a space, but not a character return when typing. Chrome will neither let someone enter a space or character return when typing. Safari will let someone enter a space or character return. Safari will not fire the button's click event on space or enter keypress.

Used on a span within a button

<button>
    <span contenteditable="true">I'm editable</span>
</button>

Will cause the inner text of the button to be focusable. When focused on the editable span within, similar interactions will occur as when contenteditable is added to the button, with a few differences.

Safari and Chrome will fire the button's click event on space keypress, but not on enter. Being that the attribute is on the span within the button, Chrome will now allow for space and enter keys to add a space or a character return.

Firefox will still not allow a character return and the click event will fire on both space and enter keypress.

Used on, and within, an <a href=...>

<a href="https://..." contenteditable>
    Change me
</a>

<a href="https://...">
    <span contenteditable>Change me</span>
</a>

When having the contenteditable attribute, a link no longer functions. This isn't necessarily unexpected if it were in the context of a larger rich-text editor, or if a button was pressed to specifically edit the link. But noting the difference between this and buttons continuing to fire their events. If the contenteditable is added to a span within the link, a mouse user will not be able to click into the text to edit, without additional measures to prevent the link's default behavior.

Used on a select and option

<select contenteditable>
    <option contenteditable>Change me</option>
</select>

No editing can occur on select or option elements.
Adding contenteditable to these elements in Firefox causes the select to no longer function.

If they're added in Safari, if someone attempts to keyboard focus on the select they might find keyboard focus has been shot back to the first focusable element of the document.

---

I think this is a good point to pause with the examples. I look forward to discussing this further. Thank you.

[annevk]

contenteditable was shipped without being formalized and all browsers were forced to support it. So there's not necessarily reasoning or use cases, but it probably made sense to whoever added it to IE to do it this way.

[LJWatson]

@AnneVK That seems likely. Given that having it as a global attribute is problematic, could the spec be amended to make it less so? At least then conformance checking tools would flag up problem uses.

[domenic]

It depends. If you're building e.g. a WYSIWYG form editor, being able to edit the contents of a button is pretty important. In general, in such a scenario, the elements aren't meant to be interacted with in a non-editing modality while in editing mode; you'd switch to preview mode (which would remove the contenteditable attribute) to interact with them.

I think the better way forward would be to file interop bugs, and perhaps tighten the spec, on how you can more usefully edit these controls, to iron out the inconsistencies pointed out in the OP.

[domenic]

So in particular I think the following would be the steps forward:

• Determine a desired behavior (using some combination of reasonableness and matches-most-engines) for the various scenarios listed in the OP
• Write web platform tests for each of them
• File bugs on browsers which fail the tests
• Update the spec to state the behavior clearly

Which spec is "the spec" here is tricky, unfortunately, as I think most of this behavior would be defined in the unmaintained https://w3c.github.io/editing/execCommand.html. We could maybe monkey-patch it in HTML, just to have somewhere to put the interoperable behavior.

[scottaohara]

Your comment about the WYSIWYG editor is something I had thought of, @domenic, having worked on a WYSIWYG website editor in the past. During my time working on that project, we had opted to go the route of a separate UI (modal dialog with text input) to specifically change interactive elements. This was because the user often still needed controls to be functional in both edit and preview mode. For example, buttons that opened accordion panels so the accordion panel content could be edited without having to have it expanded at all times while in edit mode.

But I digress.

Seems a good idea to add tests per your comment above, and more. e.g. contenteditable is awkward on a label without additional JS to stop the label from moving focus to its associated input. Speaking of inputs, it doesn't appear to do anything on most of these. Adding it to an img or video also do nothing.

All that said, I'm personally not really expecting the attribute to do much, if anything on those elements. But it does again make me question it continuing to be classified as a global attribute if it's problematic or results in no reasonable functionality on some elements.

Anyway, thank you again for the responses. Here is the test page I had started putting together to test contenteditable for other reasons, but which lead me down this rabbit hole of questioning.