Ian Hickson wrote:
Although I am against the use of contentEditable in general, that's
mostly because {a) all the implementations of it are broken
All the implementations of CSS and HTML and the DOM are broken too, I
don't suggest we remove those! :-)
That's true, but they can be fixed. contentEditable may be able to be
fixed one day too, if it were well defined, standardised and
implemented. However, even if the impelemtnations weren't broken, it
still suffers from the following problems...
and (b) the way it was designed is too presentationally oriented for a
semantic markup language - it basically suffers from the same design
flaws as every other WYSIWYG editor.
Could you elaborate? It would be nice to fix these.
I'll do my best to summarise the core problems.
Most (if not all) WYSIWYG editors don't cleanly seperate the editing of
content and of presentation. Users are able to enter text and then
directly speficify how that text should look, often through toolbar
options like font family, font size, bold, italic, underline, colour,
background, border, etc. If you open up any WYSIWYG editor or word
processor, the chances are that you'll find most of those options
available on one of the standard toolbars.
Although some editors do also provide some semantic options, they're
usually limited in their abilities. Some have some semantic block level
elements like headings, paragraphs, lists and maybe blockquote.
However, few have semantic elements like abbr, cite, code, dfn, kbd,
samp, var, q and strong/em (some, like contentEditable, mistakenly use
bold and italic options for those). I often have to jump through hoops
just to get <code> in my markup while using dreamweaver, by using the
buttons for <b> and/or <i> and then running search and replace to fix up
the markup.
Additionally, even fewer WYSIWYG editors allow authors to easily
categorise (or class) semantic elements easily. As a user, I should be
able to, for example, mark up a note by first selecting a paragraph and
then saying that it belongs in the "note" class. I know of no way to do
so with contentEditable and I haven't found an easy way to do so with an
editor like dreamweaver, short of editing the markup directly.
Personally, I'd like to see it better integrated with the DOM 2 Range
interface, so the scripts could work with the nodes a little easier and
which I'd like to see more widely implemented.
Could you elaborate?
I'll try, though my experience with DOM range is limited since it's not
widely implemented.
For example: Adding a new element around content should be done somewhat
like this:
var selection = ... // Assume this is set to the Range selected by the
// user
selection.surroundContents(document.createElement("code"));
That's far more extensible than using the execCommand() method, which
requires the commandIdentifier to be know for each element it an insert,
and for which there is no command I know of for adding a code element.
If DOMRange were used, then contentEditable may become usable for
non-HTML languages and even with new elements added to HTML. Correct me
if I'm wrong, but I don't believe it can be used for that, the way it's
been designed and implemented.
--
Lachlan Hunt
http://lachy.id.au/
