What should be the shape of contentEditable?

[BenjamP]

Some ideas include contentEditable="minimal", where we would need to be clear about what functionality is provided, and contentEditable={list of capabilities}, where {list of capabilities} might include "cursor", "typing", "newlines", etc.

[BenjamP]

From Julie Parent (a few months ago):
Without default text input, the current proposal for contentEditable="minimal" is essentially just enabling cursors (drawing them, dispatching events, performing default actions). Rather than calling the mode "minimal", which is ill-defined, why not explicitly call it what it is: "cursor-only"? Or, have contentEditable take a list of features to turn enable: contentEditable="enable-cursors enable-CommandEvents".

Or, rather than tying this concept to contentEditable, with all the assumptions and complications that brings up, why not expose this building block as a completely separate attribute?

[darobin]

On the contrary: rather than bringing in the complexity from cE (which it doesn't) it avoids conflicting with it. Imagine we add a cursoring attribute, what happens with <div contentEditable=true cursoring>?

Using cE is just a simple syntax hook, it doesn't bring up the rest of the tangled mess.

[BenjamP]

Are you advocating for contentEditable="minimal"? I currently think that have a space-delimited list is the best approach. We can say which ones have precedence. For instance "true" could mean "ignore everything else, just use legacy contentEditable".

[johanneswilm]

I think either way can work. But if we could start out with one mode that only allows the movement of the cursor (not entering or deleting any content), then we don't have to define a lot of behavior on element merging, etc. . If the possibility to write/delete content is there, but not not defined through a spec, editors will once again build their functionality on top of the implementations and if we ever want to create a definition in the future we will have the same problem as we have now with editors relying on bugs and weird implementations.

[BenjamP]

I propose we start with the following allowed values for contentEditable: true, false, inherit, and cursor. We can speck it such that inherit and cursor have defined behaviors, and true and false simply overwrite all other values, with a similar meaning as is already in HTML5. If there are no objections, I would like to go ahead and create this definition in the spec.

[darobin]

Definitely go ahead and specify this — it's good to have concrete text and if we find issues we can change that later!

[BenjamP]

I have added a proposed definition to the Editing Explainer. Feedback would be great!

http://w3c.github.io/editing-explainer/#customizable-default-handling-with-contenteditable

[BenjamP]

I have updated the definition to reflect the ideas in http://lists.w3.org/Archives/Public/public-editing-tf/2014Nov/0049.html