This is a really good idea!

Though lots of edge cases which needs to be handled. What happens in the following markup for example:

<div contenteditable=plaintext>This word is <span style="color:blue">not green</span>!. <table><tr><td>And this is in a table</table></div>

Or what happens if the same type of elements are inserted using the DOM?

I guess one solution would be that any DOM elements that are there (through markup or though DOM) are rendered as normal. However execCommand and user editing keystrokes (including pasting) can only insert plaintext.

Is there anything here which cannot be handled by the beforeeditingaction/aftereditingaction events?

(In reply to comment #3)
> Is there anything here which cannot be handled by the
> beforeeditingaction/aftereditingaction events?

Supporting paste will be annoying because you'd have to grab plain text out of the clipboard. Also, declarative notation is much easier to use than having to listen to those events and decide which one to allow.

(In reply to comment #4)
> (In reply to comment #3)
> > Is there anything here which cannot be handled by the
> > beforeeditingaction/aftereditingaction events?
> 
> Supporting paste will be annoying because you'd have to grab plain text out of
> the clipboard.

True.  But we can fix that by providing a property on the event object which returns the plaintext content on the clipboard or something to that effect.

> Also, declarative notation is much easier to use than having to
> listen to those events and decide which one to allow.

What makes me hesitate here is that there are a fair number of edge cases to be handled here, such as nested contenteditable elements of different types, things like form controls and images in plaintext contenteditable elements, the way that selections spanning multiple types of contenteditable elements should behave in response to editing commands, etc.

If anything, this needs to be very carefully specified.

The alternative here would be to provide a way to style DOM ranges. <textarea>.addCSSRange(range, identifier) or some such and ::range(identifier) in CSS.

(In reply to comment #6)
> The alternative here would be to provide a way to style DOM ranges.
> <textarea>.addCSSRange(range, identifier) or some such and ::range(identifier)
> in CSS.

That would not give web content access to the DOM behind the textarea though (unless it's exposed as shadow DOM, which might introduce other problems).

The case comment 0 described does not require access to the DOM, but I suppose there may be cases that do?

Another example of a use case for something like this is the Google+ post editor, which is a markdown-style editor, but supports first-class objects other than text, e.g. if you type "+Ian Hickson" it turns into a chip that represents my profile. The idea in the context of this bug would be for this to be implemented as a plaintext-only contenteditable region, with the script manipulating the DOM to provide features such as the chips as non-editable movable subregions.

(In reply to Ehsan Akhgari [:ehsan] from comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > Is there anything here which cannot be handled by the
> > > beforeeditingaction/aftereditingaction events?

[...]

> What makes me hesitate here is that there are a fair number of edge cases to
> be handled here, such as nested contenteditable elements of different types,
> things like form controls and images in plaintext contenteditable elements,
> the way that selections spanning multiple types of contenteditable elements
> should behave in response to editing commands, etc.

Nested elements seem fairly trivial — anything within plaintext is rendered as plaintext (even if it contains non-plaintext contenteditable elements). Overlapping selection is trickier. I wonder what WebKit/Chrome do in this case. 

It's unfortunate that we still don't have plaintext insertion and so everyone ends up reinventing the wheel again and again: facebook uses overlay; google plus uses non-standard plaintext and seems to enliven it with JS for non-supporting clients; medium intercepts all operations and maintains internal model; so does few-days-ago-released Trix editor; grammarly.com uses textarea with overlay just like facebook; few other sites implement some kind of hybrid solutions via a series of contenteditable lines; and so on.

Clearly, a better mechanism is desperately needed. I'm not sure if plaintext is the answer but it certainly looks very helpful.