Exposing HTML Editor commands to Browser Dom

RESOLVED DUPLICATE of bug 177700

Status

()

Core
DOM
P4
enhancement
RESOLVED DUPLICATE of bug 177700
16 years ago
4 years ago

People

(Reporter: Jeff Yates, Unassigned)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
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
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

Comment 3

15 years ago
P4. Since this has been requested a few times, we will try to do it not long 
after 1.0.
Priority: -- → P4

Comment 4

15 years ago
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 *

         '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.
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.

Comment 8

15 years ago
Dup of bug 97284?

Comment 9

15 years ago
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

15 years ago
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.
Blocks: 97284

Comment 11

15 years ago
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

15 years ago
Ted, exactly my vie too.
Really do hope this will finally make 1.2
Keywords: mozilla1.2

Comment 13

15 years ago
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!
Blocks: 171034

Updated

15 years ago
Summary: [RFE] Exposing HTML Editor commands to Browser Dom → Exposing HTML Editor commands to Browser Dom

Comment 14

15 years ago
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

Updated

15 years ago
QA Contact: lchiang → ian
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Has this been done, perhaps, with canvas?

Comment 17

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

Or is it to implement comment 5?  Hixie?

Comment 18

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

Updated

10 years ago
No longer blocks: 97284

Comment 19

9 years ago
For me, this is a duplicate of bug 177700 (designmode implementation) and bug 237964 (contenteditable implementation).
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 177700
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.