- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 19 Dec 2012 20:49:20 +0000 (UTC)
- To: Hugh Guiney <hugh.guiney@gmail.com>, Ojan Vafai <ojan@chromium.org>
- Cc: whatwg <whatwg@lists.whatwg.org>, Aryeh Gregor <ayg@aryeh.name>
- Message-ID: <Pine.LNX.4.64.1212192012310.20758@ps20323.dreamhostps.com>
On Mon, 22 Oct 2012, Hugh Guiney wrote:
> On Wed, Oct 17, 2012 at 7:23 PM, Ian Hickson <ian@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.
How common is it for a part of a page to be editable when the page is
loaded, for there to be no formatting UI, for the page to not mind if the
user uses the browser's own formatting features (e.g. dragging and
dropping formatted text into an editable region, using Ctrl+B, etc), and
for the process of submitting the update to the server to consist of
literally a form submission?
I don't recall ever seeing a page like this. Literally every time I've
seen contenteditable, it's had _some_ script beyond what is needed to
shunt the value into a form control.
If it's something that really does happen commonly, then sure, let's
support it.
> 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.
Not every other. Anything involving drag-and-drop, for instance, requires
script.
> What is the user benefit in making this particular method of data entry
> require an extra step?
The benefit to _not_ having a feature is just that the platform is
smaller, so we avoid all the costs associated with adding a feature:
http://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94
> > 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.
I don't understand what you mean. How would plaintext-only enable
+mentioning and so forth to be handled without script?
> > 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'm not sure this question makes sense. Why is a bicycle not meant to have
an engine? What are the drawbacks of turning a bicycle into a motorcycle?
It's just the design that it has. It may be that there are use cases for a
rich text editor that doesn't involve scripting, and in that case we
should design and add such a feature; but that's orthogonal to
contenteditable, which is specifically designed to be a low-level feature
to enable people to write editors and so forth.
> > > 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
My point is that Microsoft, while prototyping how to do rich text editing,
first started with a form control approach, and then abandoned it and
instead went for the contenteditable="" approach. There is presumably a
reason why they did so. Did the form control approach have some
fundamental flaw, providing us with lessons from which we can learn? Did
the person who invented it upset someone else on the team by beating them
at ping pong, resulting in internal politics that killed the feature and
resulted in someone else making a new feature for no good technical
reason? What's the reason? I hesitate to introduce features that were
previously abandoned without understanding why, because I don't want us to
just make the same mistakes again.
But as I said above, if it does make sense to support this, then we
should. I'm just saying we should do it with open eyes.
> > 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!
This is doing more than what my "one line of code" is equivalent to.
Certainly, the more you support, the more complicated the script gets. It
would also make the non-script version more complicated. :-)
When adding features, we do so by first looking at use cases and then
working from there. What are the use case for a script-free non-plaintext
editor in HTML? Would they really be script-free?
On Mon, 22 Oct 2012, Ojan Vafai wrote:
> On Sat, Oct 20, 2012 at 4:55 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Sat, 20 Oct 2012, Aryeh Gregor wrote:
> > > On Thu, Oct 18, 2012 at 1:23 AM, Ian Hickson <ian@hixie.ch> wrote:
> > > >
> > > > 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.
> > >
> > > In principle, yes, this should be specced. In practice, it would
> > > require extensive changes to the editing spec and a lot of careful
> > > thinking, and no one is really working on editing implementations
> > > anyway. Gecko's editor code is in maintenance mode, I haven't
> > > received a single piece of feedback ever about editing from IE or
> > > Opera people, and WebKit is the one that already implements the
> > > feature, so I don't see the effort as being worth the time spent
> > > right now. (I did receive feedback from Opera about selection, but
> > > not editing as far as I remember.)
> > >
> > > The same goes for any other proposed editing spec features. When I
> > > see people actually implementing the existing spec, that's when it
> > > will make sense for me to spend more of my time adding more stuff to
> > > it. Until then, I might fix bugs, but that's it.
> >
> > Sounds reasonable.
>
> FWIW, when I discussed this with Mozilla folk a couple years ago, the
> only sticking point was what hitting enter should should in a
> plaintext-only region. In WebKit, it inserts a <br>. Some people thought
> it should insert a '\n' and/or should based what it inserts off of the
> CSS whitespace property. Never really came up with a resolution to that
> question.
If that's the only issue, we should just pick one and go with it, if
anyone but WebKit is going to implement it.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 19 December 2012 20:49:47 UTC