- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 17 Oct 2012 23:23:55 +0000 (UTC)
- To: whatwg <whatwg@lists.whatwg.org>
- Cc: ayg@aryeh.name
- Message-ID: <Pine.LNX.4.64.1210172307460.2478@ps20323.dreamhostps.com>
On Fri, 7 Sep 2012, Hugh Guiney wrote: > > I'm developing a CMS and would like to be able to submit user-edited > content back to the server, but at present, it's not possible to do this > without copying the contents of the edited element with 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? I haven't added this, because contenteditable="" is only truly useful with scripting enabled, and it's basically one line of script to support shunting the current value into a hidden input. This becomes especially more relevant when contenteditable is used for editors that don't just upload HTML; for example, the Google+ editor is contenteditable="" but it's not going to upload the HTML, it uploads structured data. Incidentally, it seems to use a WebKit-specific "plaintext-only" value. Should we spec that? Aryeh? It's filed as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14554 If this should involve changes to HTML, let me know. On Fri, 7 Sep 2012, Mikko Rantalainen wrote: > > The contenteditable attribute is meant for low level wysiwyg-editor like > behavior framework and it is not meant to work standalone without > scripting. Indeed. > 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. This is actually what old versions of IE did (as <htmlarea>, IIRC), but it was dropped. I don't fully understand why, but I'm skeptical of introducing a new control for this without making sure we don't make the same mistakes, which means figuring out what those mistakes were. On Thu, 13 Sep 2012, Ojan Vafai wrote: > > 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. Given how easy it is to copy data into a hidden <input>, why isn't that sufficient? It would actually be pretty difficult to come up with an API that is simpler than declaring an <input> and settings its value... On Sun, 16 Sep 2012, Jonas Sicking wrote: > > 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. This is something else that just already works with <input type=hidden>. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 17 October 2012 23:27:36 UTC