Closed Bug 96392 Opened 20 years ago Closed 13 years ago

Exposing HTML Editor commands to Browser Dom


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






(Reporter: pbwiz, Unassigned)




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:

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
glazou says "indeed"
hixie says "I have a spec for that somewhere"
jst says "Future!" :-)
Summary: Exposing HTML Editor commands to Browser Dom → [RFE] Exposing HTML Editor commands to Browser Dom
Target Milestone: --- → Future
P4. Since this has been requested a few times, we will try to do it not long 
after 1.0.
Priority: -- → P4
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?
* Editing *

           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.

   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).
   Any descendant text and CDATA nodes of the element may be edited. No new 
   nodes may be inserted.
   Any descendant node may be edited

The exact mechanism used to enable editing is up to the UA.
That's the spec in question. I don't have any plans of speccing an editor API at
the moment.
> 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.
Dup of bug 97284?
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.
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
Blocks: 97284
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.
Ted, exactly my vie too.
Really do hope this will finally make 1.2
Keywords: mozilla1.2
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!
Summary: [RFE] Exposing HTML Editor commands to Browser Dom → Exposing HTML Editor commands to Browser Dom
IMO this should be implemented by using the Range object which is a part of DOM2.
Check out this link:

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
QA Contact: lchiang → ian
Mass-reassigning bugs to
Assignee: jst → dom_bugs
Has this been done, perhaps, with canvas?
This bug seems like a duplicate of content-editable.  Glazou--do you agree?

Or is it to implement comment 5?  Hixie?
I think this can be closed as invalid because Midas covers this and there are other bugs requesting contentEditable.
No longer blocks: 97284
For me, this is a duplicate of bug 177700 (designmode implementation) and bug 237964 (contenteditable implementation).
Closed: 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 177700
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.