[whatwg] What exactly is contentEditable for?

Tue Aug 16 13:17:19 PDT 2005

   Note: I'm changing <textarea usehtml> to <textarea
content-type="text/html"> because I like Lachlan Hunt's idea of being
able to specify multiple content types.

Olav Junker Kjær wrote:
> I'll describe a use case first, since I think it answers some of your
> questions.
> 
> Consider a CMS with a browser-based editing interface. For ease of use,
> it is designed so that pages in "edit mode" looks as much like the
> public site as possible. Different people are allowed to edit different
> parts of the site. E.g. the marketing department are only allowed to
> edit the "content area", while the CEO is allowed to edit the header and
> footer which is shared on every page, but not allowed to change the
> content area.
> The CMS toolbar has a lot of custom editing commands like "insert
> company logo here", "format text as unreadable legalese" and so on,
> which can be used on the editable content.

   Not seeing the difference between <textarea content-type="text/html">
(formerly <textarea usehtml>) and |contenteditable| so far.

> The "killer feature" of contentEditable is that it is orthogonal to 
> document structure. You can make any element - inline or block, anywhere 
> in the document - editable, without changing the basic structure of the 
> document.

   But if you're going to specify regions that only specific people can
access, what's the point of everything being a potent |contenteditable|
section?

> If an extra element (like <htmlarea>) were required around the 
> editable content, it would get quite tricky, since this element would 
> have to be transparent wrt. style and DOM, and it should be able to work 
> both in  block and inline context.

   It's an editing context. Why would you not want the user to know what
region you're editing? Furthermore, it's up to the UA to determine
whether a specific element can be styled in a particular way. They could
easily just allow you to style <textarea> as inline for specific
|content-type| values (i.e. "text/html").

>>   What are you talking about? Why wouldn't a UA use the styling of the
>>parent document to style the HTML inside a <textarea usehtml> element?
> 
> They cant, since a textarea contains only character data, not markup. It
> would seem a giant hack to me, if browsers would take the plaintext
> content of textarea, un-encode it and parse it as HTML, and then render
> it and generate a DOM-subtree below the textarea.

   Well, from an HTML perspective, we can just change <textarea> to
allow unencoded content. It won't validate in a fallback scenario, but
they |content-type| won't either, and most browsers support using
unencoded content inside <textarea> anyways, so there's no issue from a
practical standpoint.

   The real problem is XHTML. If you don't encode there, you don't get
any content on both Opera and Firefox. So, you have to encode for XHTML.

   That said, browsers have to decode the contents anyway. How else do
they generate the text for the control widget? So the control is already
taking text and converting it. The only missing piece is the stage where
 you parse it into the DOM, and considering that many browsers support
things like innerHTML, the code is already there.

   The real problem isn't the implementation. It's the fact that
encoding all those characters is a real pain in the [not neck]. I would
have to agree that it's a serious weakness. Of course, if you don't care
about fallback, you could just use |data| and put the HTML/XHTML in a
separate file...

>>   Here's how it's conceptually broken: How do you submit the edited
>>content without scripting? 
> 
> You dont. You use scripting. XMLHTTP requires scripting too, its still a
> useful feature.

   But what you're saying is that they need Javascript AND
|contenteditable| support just to edit the content, which is what the
page is supposed to allow them to do in the first place. That's really
only well supported right now on desktops with Internet Explorer.

   So, for those who don't have a browser with |contenteditable|
support, they can't edit, and for those without Javascript, they can
edit but can't submit. With a true form control, you can both edit AND
submit on legacy browser that don't enable/support Javascript.

   Also there's the issue of abuse. Take my suggested <date> element,
that allows date information to be displayed in localized form:

| <date id="datecontrol" contenteditable="true">2005-08-16</date>

   Since you're editing within a <date> element, and you would normally
see the localized date rather than the contained alternative content,
the UA editor may just generate the alternative content automatically
and just let you edit the date with some sort of date picker. Therefore,
the above may act as a date picker on some platforms.

   But don't worry. We can submit the date using Javascript, right?!?

>>How do you edit the content in a legacy
>>browser? 
> 
> You dont. In a legacy browser, the content is rendered as ordinary 
> content, but not editable. In most cases this is much better fallback 
> that showing some incomprehensible code in a textarea. Most people dont 
> know HTML code.

   If the people editing the HTML don't know HTML, why the heck are they
editing the web page?!?

>>How do you style the read-only or read-write contents with out
>>using those G*d-awful versions of the :read-only and :read-write
>>pseudo-classes from CSS3-UI? 
> 
> Isnt this really an objection against CSS3-UI, rather than contentEditable?

   Sort of. With <textarea>, you can use the XForms 1.0 Appendix F
definitions of :read-only and :read-write to style content in the
<textarea>:

| :read-only p { /* Style a paragraph inside a read-only textarea. */

   With CSS3-UI, this would style pretty much all paragraphs in the
document.

>>Why are we allowing editing outside a form
>>or controls context?
> 
> As in the use case, different parts of the document may be editable at 
> different times. In some cases you might even want to edit the form to 
> insert new controls.
> 
> Form controls are useful for a "fixed" editable area. E.g. if a blog had
> a comment box which allowed wysiwyg HTML entry, it would make sense to 
> have e.g. a <htmlarea> form element for this.

   No, user agents typically render form controls as fixed areas. They
don't actually have to be anything of the sort. If user agents wanted
to, they could render them as pin-up girls with the content as tattoos
on their backs. Don't forget that this is a semantic language, not a
presentational one.

> <htmlarea> could work like 
> a <div contenteditable> but in addition work as a form control (support 
> validation, participate in submission and so on).

   Hmm...

> In this context I would prefer a new tag <htmlarea> rater than <textarea 
> usehtml> since the new tag could be defined to allow mixed content 
> rather than just plaintext as <textarea>. In any case, this is a 
> different use case than the case for contentEditable.

   Not really. If you style <htmlarea> as inline, it can pretty much do
anything |contenteditable| can.

   What hasn't been mentioned here is that an element where you can
truly set the content type would allow you to do things like this: