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!
