[whatwg] What exactly is contentEditable for?

Jim Ley wrote:
> 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.

   And yet the people who are pushing |contenteditable| the hardest are
talking about complex, security-controlled, full-page editing...

>>  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.

   You're talking about defining behavior for a semantic element. You're
essentially dictating parts of the implementation of |contenteditable|
to user agent vendors. The most likely response from these vendors would
be that they'll ignore any limitations of the spec they feel are
unreasonable, especially if IE doesn't have those limitations.

> 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"

   (Wouldn't they have to have hit a "blockquote" button on their
toolbar to get that?)

> - 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 may not be called a "blockquote", but some term must have been
used in the vendor interface. Unless different user agents use wildly
different terminology when referring to blockquotes and the like, I
don't see the problem.

>>  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.

   Oh, I think I get it. You don't necessarily want there to be toolbars
and the like, because authors may want to provide their own UI for that.
I'd rather leave that up to the user agent vendors to figure out. In
most cases, it doesn't hurt to have two buttons for the same thing.

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

   There are implementations of <htmlarea>-style controls that use
|contenteditable|. I find it hard to believe that such a control would
be hard to implement using an HTC (or at least no harder than other
things, like a date picker). Most of the problems associated with
<htmlarea> are identical to those for either <textarea accept> or
|contenteditable|, so once the former two are worked out, the latter is
quite easy to implement. Is a simple, straight-forward rich editing
control too much to ask for?

Received on Tuesday, 30 August 2005 03:11:11 UTC