[whatwg] What exactly is contentEditable for?

[Matthew Raymond]

Jim Ley wrote:
> On 8/29/05, Hallvord Reiar Michaelsen Steen <hallvord at hallvord.com> wrote:
>>On 24 Aug 2005 at 12:16, Ian Hickson wrote:
>>>contentEditable needs scripting anyway, to offer things like "insert <em>
>>>element here", etc.
>>
>>Why must contentEditable depend on scripting? What if we make sure
>>the wording of the spec allows non-scripting implementations? 
> 
> Please, no, a lot the use cases for contentEditable are not full
> wysiwyg editing, a lot of the ones I create allow only a minimal
> subset of editing, and they do this by scripting, if you can only
> strong/make link/italic/colour/insert image, then you get a simple
> editor that allows for easy editing, but doesn't run into much
> tag-soup that needs elaborate cleaning up.
> 
> Whilst I agree the concept of contentEditable is not good, I don't
> think it should be solved by trying to modify the existing behaviour
> the accept="text/html" is a much better way of meeting your use case.

   I don't think it's wise to dictate what markup the user agent
supports via a toolbar or the like for HTML editing in a page. That's
crossing over from semantic to behavioral. If your really want to
specify that, it should be done via a DOM interface.

   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.

>>My question is whether we could make contentEditable more useful for
>>HTML/CMS authors by removing scripting requirements.
> 
> I would be extremely unhappy, and would need to find ways of blocking
> browsers that implemented contentEditable in this manner from
> providing the functionality, that's not a good thing, but the risk of
> letting any user/browsers attempts at html into the CMS would be
> worse.

   Servers must validate all input, regardless of whether or not it came
from a form control. That's always been the case. With something like
|contenteditable|, which need not even be submitted, hiding client-side
validation requirements deep in a WHAT WG spec isn't in the interests of
developers and will likely be ignored.

> So whilst I agree with the need, please seperate the browser provided
> from the script provided interfaces.

   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?