- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Tue, 16 Aug 2005 23:20:31 +1000
Olav Junker Kj?r wrote: > Lachlan Hunt wrote: >> How is that any different from a text area form control with a >> specified accept type of text/html, which would allow a UA to load any >> external editor (eg. XStandard) or degrade to a regular text area? > > The point of contentEditable is that some areas of a page can be made > editable (and editing toggled on and off), while still maintaining the > styling and structure of the document. This is really useful for CMS'es > and other kind of editors - template editing and so on. I'm not disputing the fact that there is an unfortunate demand for embedded WYSIWYG editing in web based CMSs, it is the conceputally broken implementation I'm against. > contentEditable is quite clean since you just toggle an attribute. No, it's messy because it mixes normal document content with user input in a way that does not, by design, degrade very gracefully at all without scripting. > With your proposal, the editable element should toggle between the original > content, and a textarea element containing content, Which, from a user's point of view, is how contentEditable is generally implemented by authors within web pages. Take, for example, the example provided on MSDN [1]. That provides both a content editable region and a textarea. Although they are clearly seperated from each other, the concept of switching between the two editing modes is still there. Now, take a look at Cameron Adams' "widgEditor" [2]: an implementation using script to dynamically replacce an ordinary textarea with a content editable region with the ability for the user to switch between the two. > now HTML escaped, but still rendered as if it were ordinary content, It had to be escaped because the <textarea> contains #PCDATA despite the fact that implementations tend to treat it more like CDATA, with the exception that they still process entity and character references. >> User can edit with plain text editor or UA can load WYSIWYG editor for >> text/html (or whatever ever MIME type is specified) > > But this considers the editable content as just an arbitrary content > type which should be edited in some external editor. It doesn't necessarily have to be an external editor, that aspect is implementation specific. A UA could quite easily replace the text area with a content editable region, much like the widgEditor script does. Another UA could alternatively load an editor plug-in like XStandard into the page; and another could even, theoretically, launch an application like dreamweaver. The point is that the markup should not be concerned with the actual implementation details, like contentEditable is. > The point of contentEditable is that the editable content is HTML The point of the suggested <textarea content-type="text/html"> was that the editable content is HTML; what's the semantic difference? > and an integrated part of the containing page, which enables much cleaner > "in place" editing. Perhaps, cleaner from a user's point of view, but, IMHO, certainly not cleaner from an author's and markup point of view. However, as I've said above, there's nothing stopping a UA implementing the interface for my suggestion like the content editable interface. > If you just consider the editable content an arbitrary blob of editable > content, you wouldn't e.g. expect styles from the containing document > to inherit into the editable HTML, which is a major point of contentEditable. That is conceptually a preview mode and there's nothing stopping the UA providing such a view with either method. In fact, there are several examples of authors providing script based previewing. See Jon Hicks' weblog comment system [3] for one. That particular example uses Textile for editing, rather than HTML, but the concept is still the same and with script enabled, the user should see a preview of the content below, as they type. > Also consider that editable areas may contain non-editable islands which > aganin may contain editable areas. How would that be expresses using > TEXTAREA ? That's a usability nightmare, it wouldn't make much sense for part of the content to be editable and other parts not. If you have seperate sections to edit, provide seperate form fields for each one. > I dont see how its "conceptually broken". Well, firstly, because the whole idea of editing a semantic langauge like HTML with a very presentationally oriented WYSIWYG system is broken. That applies to all WYSIWYG HTML editors (not just contentEditable) which are not helped by the presence of presentational toolbar functions (eg. the typical bold, italic, font colour, alignment buttons, etc. found in a typical editor's toolbar). However, even ignoring the problems of WYSIWYG editing for HTML, contentEditable is still conceptually broken. The attribute is behavioural, not semantic, and has no place within a semantic language. Although, there may be some arguments for retaining/standardising the scripting interface for it based on this point alone, I don't support that option either. A content editable region is conceptually a form control implemented as regular content with a behavioural attribute. It requires a script to write the content into a form control for submission and it does not degrade gracefully at all. Although, the widgEditor example I mentioned earlier does degrade to a regular text area (because the script dynamically replaces the textarea with the contentEditable region), that just further emphasises the fact that it is conceptually nothing more than a form control (specifically a textarea) and should be implemented as such from a markup perspective. > Its very useful, despite its shortcomings. The functionality provided from a user's point of view may be very useful for some (though I personally think HTML should not be edited with WYSIWYG editors, especially with such poorly implemented editors), the implementation using contentEditable is a complete disaster. If a user wants a WYSIWYG editor to write HTML, leave that up to the UA to implement, not the author. The author should only need to specify what kind of input is expected, *not how it should be input*. There is a precedent for this kind of implementation. Consider some of the Firefox extensions that allow users to insert BBCode or HTML markup into textareas via a context menu. There's nothing to stop such extensions replacing the text area with a content editable region, at the user's request, for the same purpose. In fact, if there were an attribute that specified the content to be text/html, there would be nothing to stop the UA automatically replacing the textarea for the user. [1] http://msdn.microsoft.com/workshop/samples/author/dhtml/refs/editRegions.htm [2] http://www.themaninblue.com/experiment/widgEditor/ [3] http://www.hicksdesign.co.uk/journal/now-powered-by-textpattern-4#commentform -- Lachlan Hunt http://lachy.id.au/
Received on Tuesday, 16 August 2005 06:20:31 UTC