[whatwg] What exactly is contentEditable for?

[Hallvord Reiar Michaelsen Steen]

[ Re-arranging reply to start with the fundamental "scripting 
dependency" topic. If you insist that I'm beating some dead animal 
now I promise to shut up :) ]

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? For 
example, nothing should prevent the UA from making its own toolbar 
available with formatting commands (whether those are FONT or STRONG 
is an entirely different debate), or supporting common editing 
shortcuts (like Word's Ctrl-B for Bold text) when in editing mode. If 
the contentEditable element can also act as a form control, we have a 
perfectly fine basic option for authors who aren't interested in a 
complex, full editor with lots of buttons.

>> <form id="saveform" action="" method="put"></form>
>> <div contentEditable="true" form="saveform"></div>

> Well, you can do that now:
> <form action="" method="post"
>       onsubmit="savedata.value = firstChild.innerHTML"
>   ><div contentEditable="true"></div><input name="savedata" type="hidden">
> </form>

My question is whether we could make contentEditable more useful for 
HTML/CMS authors by removing scripting requirements. I'm not against 
a scripting dependency per se, I just thought it would be a very nice 
option for a small-scale CMS to just add a FORM tag and 
contenteditable + form attributes instead of having to find and 
implement a big JS library for an editor. 

> Not quite the same, I guess. If we wanted to say that the UA could PUT the 
> document back to the same URI if it was modified, though, I'd suggest 
> using the HTTP header "Allow: PUT" when serving the content in the first 
> place. Better than modifying the document itself IMHO.

You are already modifying the document to make it editable (whichever 
way you apply the contentEditable property/attribute). A FORM post 
allows much greater flexibility in terms of information you may want 
to include with the page, for example to include page metadata as 
separate form inputs. Whether method is POST or PUT wasn't important.

> (Especially if you 
> consider that the page might be copied to other servers that don't support 
> it, e.g. in mirroring networks.)

For a FORM the action could always be an absolute URL to a server 
with the CMS backend.. Another example of "form" attribute 
flexibility.
-- 
Hallvord Reiar Michaelsen Steen
http://www.hallvord.com/