[whatwg] Submitting contentEditable Content In A Form

[Hugh Guiney]

On Wed, Oct 17, 2012 at 7:23 PM, Ian Hickson <ian at hixie.ch> wrote:
>
> 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.

For me, it's also useful even just as a way for blog contributors to
edit the content of posts in-context (i.e., with styling applied, as
it will appear on the final page, rather than "blindly" inside a
textarea). Obviously it's going to be more versatile with scripting
enabled, but that's true across the board, and contenteditable doesn't
lose all value merely by virtue of the user not being able to add
specific formatting: additional formatting could occur server-side
(think Markdown expansion); a lot of content on the Web consists
primarily or even exclusively of paragraphs; an editor could make
purely grammatical, spelling, or factual changes to another user's
article draft without touching the underlying structure... And the
formatting isn't necessarily an issue anyway as UAs could just as
easily add script-less controls, as they've done with the video
element. That the attribute is currently useless with scripting
disabled is the very reason I've brought this up; it would no longer
be useless if there were a way to send its containing element's
contents back to the server.

Additionally, shunting into a hidden input, while perhaps trivial, is
essentially a hack to work around this missing feature. As an author,
it doesn't strike me as particularly intuitive when every other method
of user-entry can be submitted on its own. What is the user benefit in
making this particular method of data entry require an extra step?

> 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.

If the plaintext-only value is spec'd, that's no longer an issue: it
could upload HTML by default, or plaintext when that value is
set—which can obviously be transformed or subsumed into a structured
data set, as G+ must do already.

> 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.

Why isn't it? What are the drawbacks?

> > 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.

This is a little hard to search for with simple queries as there are a
lot of results for DHTML scripts of the same name, but I did find the
following article[1] which states that <htmlarea> premiered in version
5, and illustrates the usage, which is identical to how
contenteditable works; it's just a block-level element rather than an
attribute. Considering the fact that contenteditable was introduced
soon afterward in IE 5.5, it seems reasonable to infer that <htmlarea>
was essentially a prototype for the same feature. If this is indeed
the case, given that the original concept behind the feature seems to
be "a textarea that allows markup", it seems highly likely that
generic editable elements would've been used as form controls were
there a way to do that.

[1]: http://www.siteexperts.com/ie5/htmlarea/page1.asp

> 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...

I don't know that a separate API is necessary here either, but the
hidden input trick doesn't really scale well. Consider the submission
of multiple contenteditable elements, use case being that a user has
privileges to edit certain sections of a document and not others, as
in a template-based CMS. The code would have to look something like
this, at the bare minimum:

    var form = document.forms.form;

    function stripHTML(html) {
        var div = document.createElement('div');
        div.innerHTML = html;
        return div.textContent || div.innerText;
    }

    function shuntContentEditables(event) {
        event.preventDefault();

        var editables =
document.querySelectorAll('[contenteditable]'), i, current,
hiddenInput, isPlainTextOnly, content;

        for (i = 0; i < editables.length; ++i) {
            current = editables.item(i);
            hiddenInput =
document.querySelector('input[type="hidden"][name="' + current.id +
'"]');
            isPlainTextOnly =
(current.getAttribute('contenteditable').toLowerCase() ===
'plaintext-only');
            content = current.innerHTML;

            if (isPlainTextOnly) {
                hiddenInput.value = stripHTML(content);
            } else {
                hiddenInput.value = content;
            }

            form.submit();
        }
    }

    form.addEventListener('submit', shuntContentEditables, false);

...30 lines of code! Sure, I could delete some newlines, and it may be
a relatively small price to pay for the functionality, but considering
that with textareas this would be 0 lines, I'm not sure why we'd want
to force authors to do this, just so they can use HTML instead of
text.