[whatwg] Submitting contentEditable Content In A Form
ian at hixie.ch
Wed Oct 17 16:23:55 PDT 2012
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
> say, a hidden form field. I think that there should be some mechanism to
> associate contentEditable elements with formsmaybe 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:
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
> I'd suggest supporting <textarea type="text/html"> with a built-in HTML
> wysiwyg editor if any UA wants to support HTML editing without
> 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
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg