[whatwg] What exactly is contentEditable for?

Jim Ley jim.ley at gmail.com
Tue Aug 30 02:29:13 PDT 2005

On 8/29/05, Matthew Raymond <mattraymond at earthlink.net> wrote:
>   By the way, I think Hallvord's asking for giving the UA vendors
> flexibility in what tools are available for HTML editing in a document,
> not asking for anything to be mandatory. Vendors are likely to implement
> what they feel is useful for the users anyway.

Sure, but I'm saying they're not useful for the use cases of
contentEditable as it is used today, we've seen lots of people asking
what are the use cases for contentEditable, and I'm not completely
sure everyone is actually looking at if their proposals meet them. 
contentEditable is not used for authoring of full pages, it's used for
simple authoring - wiki like markup for people who can't do
wiki-markup basically.  I've seen very few outside email apps that
don't limit what can be achieved.

>   Servers must validate all input, regardless of whether or not it came
> from a form control. 

Validating the semantic appropriateness of mark-up is not
computationally feasible, however it's not possible to have a link or
an image semantically invalid, they are what they are.  This is the
difference, limiting what the user can create in their contentEditable
is important to maintain semantic appropriateness.

For ensuring only elements and tags you want are in the CMS, that's
fine, but rejecting it, it will not be possible to give a meaningful
answer of why the edit failed to user of a wysiwyg control - "you used
a blockquote, please resend without a blockquote" - If a user's done
nothing but gone, give me a left margin in his editor, he'll not have
a clue on how to fix that or WTF a blockquote is.
>   It would be nice to be able to explicitly define what markup can be
> used in a |contenteditable| element. Any suggestions how that can be
> defined?

It might be nice, but I can't see how a user agent could really
achieve such a thing, what's it going to do change its edit bar for
every user, that would lose any consistency that would be gained by
providing it in browser.

I think a rich textarea is a good idea, I just see it as distinct from
contentEditable - something with existing implementations and uses.


More information about the whatwg mailing list