[whatwg] What exactly is contentEditable for?

[Dimitri Glazkov]

On 8/23/05, Ian Hickson <ian at hixie.ch> wrote:
>
> Actually, originally, HTML was supposed to be user editable always. Much
> like in Amaya. So contentEditable is more of a compromise between the
> original intent of the Web and the "don't let them modify it!" attitude
> that has grown since.

I understand (and appreciate) the sentiment, but that's not how HTML
had developed. Amaya's simplistic PUT is not going to cut it for most
of today's managed content. Web pages have become compositions of
resources, and something a little more sophisticated is needed to
specify how the edits are passed on to the server.

As you know, there is already a scheme for communicating server's
expectations on input -- forms.

I can't see how contentEditable fits in this scheme. The attribute
only specifies whether the area is possible to edit. It does not
specify how the UA is to communicate it back. It just doesn't seem
kosher to leave it as is.

And answering your earlier comment, I understand that it's just a
couple of lines of code to provide that communication. The problem is
that it's not a consistent or standardized way, which makes it next to
impossible to determine how this communication is handled without
actually executing the code.

Shooting from the hip, I would rather see something like this:

<textarea type="text/html" src="#mainPageContent"
id="mainPageContentEditor"></textarea>

Where the src attribute points to an element (or the whole document,
if you want to). The element and its children/descendants may or may
not have contentEditable attribute set, thus regulating which parts of
the fragment is editable.

At least now you are using the same form scheme to specify how the
server would like to receive this data.

:DG<