Prev: Passing primitive variables by reference in JavaScript
Next: jQuery Lint
From: Gordon on 18 Jan 2010 05:35
I have been thinking of building a rich text editor based on
iscontenteditable to replace the TinyMCE install we use on our CMS,
but am having trouble finding data on browser support. Is there a
list of browsers that support iscontenteditable? I really could do
with a list of browser, along with the minimum version that implements
support. If there's a more detailed list that includes things like
quirks and bugs in specific versions as well, that would be of great
help.

Thanks.
From: Tim Down on 18 Jan 2010 08:21
On Jan 18, 10:35 am, Gordon <gordon.mc...(a)ntlworld.com> wrote:
> I have been thinking of building a rich text editor based on
> iscontenteditable to replace the TinyMCE install we use on our CMS,
> but am having trouble finding data on browser support.  Is there a
> list of browsers that support iscontenteditable? I really could do
> with a list of browser, along with the minimum version that implements
> support.  If there's a more detailed list that includes things like
> quirks and bugs in specific versions as well, that would be of great
> help.
>
> Thanks.

Firstly, you can build a rich text editor for browsers without
contenteditable, so long as the browser implements the more widely
supported designMode on the document object. TinyMCE and other editors
use an iframe as the editable area for this and other reasons.

Secondly, I don't have the exact knowledge of browsers supporting
designMode and contentEditable, but as an overview, IE has supported
contenteditable since version 5.5, Firefox since version 3.0, Safari
and Opera I'm not sure but both have had it for a while. designMode is
more widely supported: IE since 5.5, Firefox since one of the 0.x
releases, Safari and Opera I think started supporting it at the same
time as contenteditable. If you need more detail I suggest searching
the browser manufacturers' sites.

Thirdly, there are any number of quirks, bugs and inconsistencies
among the different browsers' implementations of content editing,
which makes developing a rich text editor from scratch a very
difficult and time-consuming task. I would suggest thinking very
carefully before taking it on.

Tim
From: Auke van Slooten on 18 Jan 2010 10:31
Tim Down wrote:
> On Jan 18, 10:35 am, Gordon <gordon.mc...(a)ntlworld.com> wrote:
>> I have been thinking of building a rich text editor based on
>> iscontenteditable to replace the TinyMCE install we use on our CMS,
>> but am having trouble finding data on browser support. Is there a
>> list of browsers that support iscontenteditable? I really could do
>> with a list of browser, along with the minimum version that implements
>> support. If there's a more detailed list that includes things like
>> quirks and bugs in specific versions as well, that would be of great
>> help.

Hi,

I've been lurking here for a few months now (and learned a lot in the
process, thanks everyone :) but since I've actually written a beast like
this I think I should speak up here. As Tim said:

> Thirdly, there are any number of quirks, bugs and inconsistencies
> among the different browsers' implementations of content editing,
> which makes developing a rich text editor from scratch a very
> difficult and time-consuming task. I would suggest thinking very
> carefully before taking it on.

This is not an easy task. Whether you go for the designMode or
contentEditable route, you will most probably start using the
execCommand method. You will find that all browsers implement different
sets of commands and in different ways. HTML edited using Firefox will
have wildly different markup then HTML edited using Safari or Internet
Explorer. In addition, there are a number of 'interesting' bugs when you
try to save HTML with embedded objects, e.g. flash. Any version of
Internet Explorer will bite you if you try to read the HTML contents of
your contentEditable element using innerHTML. More specific, the html
returned does not represent the actual parameter values set in the html
source.

If you plan a relatively simple html editor, with just a few simple
commands, by all means build your own, it's easy. If you want something
a bit more complex... I'd seriously consider using an existing one. If
you really need the editableContent part, the only one I'd consider (as
a starting point) is mozile (http://mozile.mozdev.org/). Although it
seems a dead project now, it's the only one I found which doesn't rely
on execCommand but uses the DOM to do all html manipulation. The last
version did run in Internet Explorer, but I'm not sure if it still does.

Using execCommand, you can tell the browser to change the current
selection into a H1, with:

document.execCommand("FormatBlock", false, "<h1>");

However, you cannot do this:

document.execCommand("FormatBlock", false, '<h1 class="myHeading">');

I found no way to reliably set the class attribute on only the tags just
inserted or updated with execCommand. If you take a look at most
webbased WYSIWYG html editors, those that support it use a variety of
hacks, most involve adding font tags and then replace those using DOM
methods.

Now I must say, I haven't really looked at other editors in quite a
while, so perhaps they have cleaned up their code, but the problems of
execCommand still stand, you never know what a command will do. So the
only way to get the same result cross browser reliably, is to write the
code yourself, using DOM manipulation. This is not a simple task, you
must take into account that a selection can start and end most anywhere.
You cannot simply surround the selected fragment of the dom with a new
tag, you will have to walk through the DOM tree and add or delete html
elements according to:

1) what the HTML specification allows
2) what the user expects

These can and fairly often will be in conflict.

Good luck,
Auke van Slooten
 | 
Pages: 1
Prev: Passing primitive variables by reference in JavaScript
Next: jQuery Lint