Ian Hickson wrote:
On Mon, 15 Aug 2005, Lachlan Hunt wrote:
How is [contentEditable] 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?
contentEditable is implemented. <textarea type="text/html"> is not.
And, as I demonstrated in an earlier e-mail with the widgEditor I linked
to, it's not hard for an author to provide a script that converts the
textarea to a WYSIWYG editor using the contentEditable DOM interface.
It's not much different from the scripts that are being written to add
support for other extensions in today's browsers.
That would be a far better option than using contentEditable, which is
not only conceptually broken, but *all* implementations of it are so
incredibly broken, that trying to standardise it is like dragging a dead
horse through mud.
There may be some truth to that, but contentEditable also has other
benefits, like integration with the DOM, and the ability to seemlessly
integrate with the page. For example, on a wiki, you can be browing the
content, and then toggle one area so it is contentEditable, edit it, and
submit that, all asynchronously and without having to switch in a
<textarea> or anything like that.
That's a reasonable argument for standardising the DOM interface for it,
but not for including contentEditable as an attribute in the markup,
which is what I'm against the most.
Although I am against the use of contentEditable in general, that's
mostly because {a) all the implementations of it are broken 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.
Using the wiki example, a script could be provided which captures the
events for the "edit this" links and dynamically makes the content for
that section editable using the contentEditable DOM interface. Scripts
would also be used to handle the submission.
However, without script those links should fall back to the way they
currently work, which is to load a seperate page with the editable
markup in a textarea for the user. Additionally, that textarea could
have an accept="text/html" attribute, from which (even without JS
enabled) the user agent could choose to load an HTML editor for the user
(whether that be for just providing syntax highlighting in code view or
a WYSIWYG style editor).
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.
--
Lachlan Hunt
http://lachy.id.au/
