- From: Alain Couthures <alain.couthures@agencexml.com>
- Date: Fri, 07 Sep 2012 22:07:38 +0200
- To: Mikko Rantalainen <mikko.rantalainen@peda.net>
- Cc: whatwg@lists.whatwg.org
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!
Received on Friday, 7 September 2012 20:08:13 UTC