96392 - Exposing HTML Editor commands to Browser Dom

Status: RESOLVED DUPLICATE of bug 177700

(Core :: DOM: Core & HTML, enhancement, P4)

Description

[Jeff Yates]

Mozilla has HTML editing capabilites built into it's composer component.  I
would like to see a means of exposing this capability to a live web page.  This
would enable web page authors to create a WYSIWYG editor embeded within their
web page.  An example of what I am wanting can be found at:

http://www.laneve.com/Tech/XSDHEditor/test_page.html

In Internet Explorer you can do this via the CONTENTEDITABLE attribute of most
tags.  I would like to see the same capablility (with whatever attribute you
choose) added to Mozilla.

Part of this would be to add methods to the Range object for manipulating the
markup (bold, indent, italic, underline, outdent, cut, copy, paste, etc.).  In
IE these are provided by the execCommand, queryCommandEnabled,
queryCommandIndeterm, queryCommandState, queryCommandSupported and
queryCommandValue methods.

It would also require the automatic display of a text-insersion cursor and
automatic keyboard shortcuts for the commands (ctrl-x, ctrl-v, etc).

I know that this is low on your priority list, but the functionality is already
there, it just needs exposed to JavaScript for regular web pages.

Jeff Yates
http://www.pbwizard.com

Comment 1

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

glazou says "indeed"
hixie says "I have a spec for that somewhere"

Comment 2

[Johnny Stenback (:jst)]

jst says "Future!" :-)

Comment 3

[Fabian Guisset]

P4. Since this has been requested a few times, we will try to do it not long 
after 1.0.

Comment 4

[Mike Lee]

Well, I don't know if it's possible to tune the individual 'tags' for editing,
doesn't editor convert the whole view in one go?

Comment 5

[Hixie (not reading bugmail)]

* Editing *

         'user-modify'
           Value: read-only | text | all
         Initial: read-only
      Applies to: all elements that can obtain focus
       Inherited: yes
     Percentages: n/a
           Media: interactive
  Computed Value: specified value

This property establishes whether the UA should allow editing of the node and
its children.

read-only
   The element should not be editable by the user (unless overriden by the UA, 
   e.g. if the user invokes an "edit" mode on the document).
text
   Any descendant text and CDATA nodes of the element may be edited. No new 
   nodes may be inserted.
all
   Any descendant node may be edited

The exact mechanism used to enable editing is up to the UA.

Comment 6

[Hixie (not reading bugmail)]

That's the spec in question. I don't have any plans of speccing an editor API at
the moment.

Comment 7

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

> text
>   Any descendant text and CDATA nodes of the element may be edited. No new 
>   nodes may be inserted.

Should also allow character entity insertion.

Comment 8

[Jesse Ruderman]

Dup of bug 97284?

Comment 9

[Kathleen :Brade]

I don't think this is a duplicate of that bug.  Instead, it is probably a
dependency that we fix this bug before we fix that bug.

Comment 10

[Jesse Ruderman]

I think it would be better to let the page ask for an editor toolbar and say
what type of HTML is allowed, and have Mozilla/Composer do the rest.  If we
force every web page that uses contenteditable to implement an HTML composer,
those web pages will be likely to leave out keyboard shortcuts and important
commands like "discontinue link".  We might run into problems where the web page
calls the paste command just to see what's on the user's clipboard.  Also, the
user would have to figure out each site's HTML editor instead of just learning
Mozilla's.

Comment 11

[Ted Stresen-Reuter]

As the main developer for an intranet for a company of some 800 people, I can
assure you that the ability to "edit" web page content with a WYSIWYG editor
right in the web browser is a killer application and it is going to "seal the
deal" for IE as far as intranets are concerned. I would be more than happy to
spend some time trying to develop this functionality for Mozilla.

Comment 12

[Markus Hübner]

Ted, exactly my vie too.
Really do hope this will finally make 1.2

Comment 13

[Sybren Stuvel]

I work for a company specialized in content management systems. Currently, we
can only offer easy HTML editing to our windows using customers. It would be
really great to have a platform-independent solution for this!

Comment 14

[Bart van Bragt]

IMO this should be implemented by using the Range object which is a part of DOM2.
Check out this link:

http://www.pbwizard.com/Articles/Moz_Range_Object_Article.htm

bug 30838 seems to be the tracking bug for the Range object. Let's all pray and
hope that object will be functional sometime soon :D

Comment 15

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 16

[Alex Vincent [:WeirdAl]]

Has this been done, perhaps, with canvas?

Comment 17

[Kathleen :Brade]

This bug seems like a duplicate of content-editable.  Glazou--do you agree?

Or is it to implement comment 5?  Hixie?

Comment 18

[Erik Arvidsson]

I think this can be closed as invalid because Midas covers this and there are other bugs requesting contentEditable.

Comment 19

[Laurent Jouanneau]

For me, this is a duplicate of bug 177700 (designmode implementation) and bug 237964 (contenteditable implementation).