[whatwg] Submitting contentEditable Content In A Form

[Ian Hickson]

On Fri, 7 Sep 2012, Hugh Guiney wrote:
>
> I'm developing a CMS and would like to be able to submit user-edited 
> content back to the server, but at present, it's not possible to do this 
> without copying the contents of the edited element with JavaScript into, 
> say, a hidden form field. I think that there should be some mechanism to 
> associate contentEditable elements with forms—maybe the combination of 
> contentEditable="true" and the presence of @name creates an implicit 
> form control? The value sent to the server could be equivalent to that 
> element's innerHTML. Thoughts?

I haven't added this, because contenteditable="" is only truly useful with 
scripting enabled, and it's basically one line of script to support 
shunting the current value into a hidden input. This becomes especially 
more relevant when contenteditable is used for editors that don't just 
upload HTML; for example, the Google+ editor is contenteditable="" but 
it's not going to upload the HTML, it uploads structured data.

Incidentally, it seems to use a WebKit-specific "plaintext-only" value. 
Should we spec that? Aryeh? It's filed as:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=14554

If this should involve changes to HTML, let me know.


On Fri, 7 Sep 2012, Mikko Rantalainen wrote:
> 
> The contenteditable attribute is meant for low level wysiwyg-editor like 
> behavior framework and it is not meant to work standalone without 
> scripting.

Indeed.


> I'd suggest supporting <textarea type="text/html"> with a built-in HTML 
> wysiwyg editor if any UA wants to support HTML editing without 
> JavaScript. In that case, the UA should provide a scriptable method for 
> detecting for native support of type="text/html". As a result, a CMS 
> system could fallback to e.g. TinyMCE or CKeditor to emulate the missing 
> support.

This is actually what old versions of IE did (as <htmlarea>, IIRC), but it 
was dropped. I don't fully understand why, but I'm skeptical of 
introducing a new control for this without making sure we don't make the 
same mistakes, which means figuring out what those mistakes were.


On Thu, 13 Sep 2012, Ojan Vafai wrote:
> 
> I think this is a problem that we need to address more generally. I'm 
> not sure what the API should look like, but it's not specific to 
> contentEditable. I should be able to make a Web Component that submits 
> specific values with forms based off it's content. If we solve that 
> problem right, it'll be possible to make contentEditable elements submit 
> with forms without extra JS code.

Given how easy it is to copy data into a hidden <input>, why isn't that 
sufficient? It would actually be pretty difficult to come up with an API 
that is simpler than declaring an <input> and settings its value...


On Sun, 16 Sep 2012, Jonas Sicking wrote:
> 
> I agree, I would like to see a more general-purpose solution for this. 
> One problem that we have is that |new FormData(form)| allows 
> synchronously grabbing, so we'd likely end up having to fire synchronous 
> callbacks, which is always unfortunate, but I don't see an alternative 
> here. Especially since grabbing data asynchronously is always risky.

This is something else that just already works with <input type=hidden>.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'