- From: Olav Junker Kjær <olav@olav.dk>
- Date: Mon, 15 Aug 2005 23:00:45 +0200
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. 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. 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. > 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. > 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. > 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. > 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? > 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. <htmlarea> could work like a <div contenteditable> but in addition work as a form control (support validation, participate in submission and so on). 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. Regards Olav Junker Kj?r
Received on Monday, 15 August 2005 14:00:45 UTC