Re: [whatwg] Submitting contentEditable Content In A Form

Am 13.09.2012 23:06 schrieb Ojan Vafai:
> On Fri, Sep 7, 2012 at 1:07 PM, Alain Couthures <
> alain.couthures@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.

We have the @form attribute in form controls, as described in 4.10.18.3. 
If @form was made a global attribute, every element could be associated 
with a form.

If an element contains a @name attribute and a @form attribute, and 
there is a form with the name specified in the @form attribute, then the 
inner HTML of the element will be submitted with this form.

(As the submitted value is a string, I believe this would not even be a 
problem if the element is the form itself or one of its ancestor elements.)

Received on Friday, 14 September 2012 07:51:11 UTC