[whatwg] Submitting contentEditable Content In A Form

[Jonas Sicking]

On Thu, Sep 13, 2012 at 2:06 PM, Ojan Vafai <ojan at chromium.org> wrote:
> On Fri, Sep 7, 2012 at 1:07 PM, Alain Couthures <
> alain.couthures at agencexml.com> wrote:
>
>> Le 07/09/2012 12:32, Mikko Rantalainen a écrit :
>>
>>  2012-09-07 11:57 Europe/Helsinki: Hugh Guiney:
>>>
>>>> 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?
>>>>
>>> The contenteditable attribute is meant for low level wysiwyg-editor like
>>> behavior framework and it is not meant to work standalone without
>>> scripting.
>>>
>>> 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.
>>>
>>>  @type should only contain a type name, such as "date" or "number", and
>> "text/html" is a media type so "html" would be more appropriate from my
>> point of view.
>>
>> I can mention that XForms has the same problematic and I implemented a
>> wysiwyg editor support in my own XForms implementation with TinyMCE for
>> XForms textarea control. In XForms, the type associated to the target node
>> is used to automatically adapt the control rendering.
>>
>> BTW, I even consider that "textarea" would be useless if only a
>> "multilined" type could be supported for the input field. A select field
>> would be an input field for an enumeration... So input tag would cover
>> every possibility!
>
> 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.

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.

/ Jonas