Re: [whatwg] Submitting contentEditable Content In A Form

Le 14/09/2012 09:50, Markus Ernst a écrit :
> 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.)
>
The inner HTML of the element would only contain serialized HTML while 
there are components able to edit many kind of texts, such as editarea ( 
http://sourceforge.net/projects/editarea/), which are not rendered in 
raw mode by the component.

Received on Friday, 14 September 2012 17:17:28 UTC