Re: [whatwg] Submitting contentEditable Content In A Form -- also in SVG and audio contexts

I don't know if this matters or not, but at some point in time, other standards than HTML like <svg> or <audio> might receive sensible proposals to allow other media (than just text) to be contentEditable.

Just as it makes sense to have built in text editors (imagine the spectrum ranging from <textarea> to rich web content editors like in Google+ and beyond) in a spec that deals with text (as in HyperText ML handling such routine things as word-wrap, backspace, delete, select, copy, paste etc.), so might it make sense to have a default (cross-browser-consistent) generic drawing pad that produces structured graphical objects (and not just silly pixelbits) built into a graphical element or a default (cross-browser-consistent) sound studio built into audio objects. The GUI interfaces for these things have been pretty consistent since MacDraw in 1984 and SoundEdit in 1986 so any patents with the oft-replicated interface would have expired by now. 

I'm not saying that coherent proposals that meet the acceptance of the standards community for such will emerge in the next few years, but at some time, the logic for them is likely to eventually overcome the resistance. And, in the meantime, it might make sense to make sure that what is done with the stuff in HTML is consistent with the broader spectrum of possible use cases that will emerge in the future.

Cheers
David

-----Original Message-----
From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Ian Hickson
Sent: Wednesday, October 17, 2012 7:24 PM
To: whatwg
Cc: ayg@aryeh.name
Subject: Re: [whatwg] Submitting contentEditable Content In A Form

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 Thursday, 18 October 2012 00:16:47 UTC