While this is something we could consider addressing this is part of a bigger issue which is the general state of contenteditable, or editing support in general, on the web platform. Lots and lots of work to do on that front, but not something that's risen to the top of the priority list at any vendor to date, thus the current state. I'm passing this over to the editing team for further evaluation against their overall priorities, and for the team to decide whether they want to confirm this issue or not, given the under specified nature of editing.

Editing team considers adding contenteditable to <input> and <textarea> as incorrect usage. Their interactability should be controled by readonly and disabled attributes.

Note: Firefox (60.2.0esr (64-bit)) has the same behavior on the test case.

@leoseven: Could you give an example where we must use contenteditable on <input> and <textarea>, while readonly and disabled don't serve the purpose?

"contenteditable" enables editing functionality to contents of element.

Regarding HTML5 specification, <input> element doesn't take child element in its syntax. Even if JS adds child nodes, they are not rendered.

This is also applied to <textarea>, parser treats characters inside <textarea> as sequence of characters instead of markup until </textarea>. <textarea> takes only Text node and they are used for initial value of <textarea>.

In other words, form controls, <audio>, <video>, <svg>, <canvas> are not supported as editing functionality now.

Possible extension are implementing special editors of them, e.g. drawing editor for <canvas>, video editor for <video>, etc.

>Editing team considers adding contenteditable to <input> and <textarea> as incorrect usage. Their interactability should be controled by readonly and disabled attributes.

In such case, contentEditable DOM property should always return "false" for readonly inputs. Now it returns "inherit".

>Could you give an example where we must use contenteditable on <input> and <textarea>, while readonly and disabled don't serve the purpose?
No, I couldn't. It's just an experiment.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Mark WontFix since it works as expected.

>#c5, the value of Element#contentEdiable is "inherit" if the element doesn't have "contenteditable" attribute[1].

From the spec:
The contentEditable IDL attribute, on getting, 
* must return the string "true" if the content attribute is set to the true state, 
* "false" if the content attribute is set to the false state, 
* and "inherit" otherwise.

[1] https://html.spec.whatwg.org/multipage/interaction.html#dom-contenteditable