Closed
Bug 96392
Opened 23 years ago
Closed 16 years ago
Exposing HTML Editor commands to Browser Dom
Categories
(Core :: DOM: Core & HTML, enhancement, P4)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
DUPLICATE
of bug 177700
Future
People
(Reporter: pbwiz, Unassigned)
References
()
Details
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"
Comment 2•23 years ago
|
||
jst says "Future!" :-)
Summary: Exposing HTML Editor commands to Browser Dom → [RFE] Exposing HTML Editor commands to Browser Dom
Target Milestone: --- → Future
Comment 3•23 years ago
|
||
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?
Comment 5•22 years ago
|
||
* 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•22 years ago
|
||
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 9•22 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•22 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.
Comment 11•22 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•22 years ago
|
||
Ted, exactly my vie too. Really do hope this will finally make 1.2
Keywords: mozilla1.2
Comment 13•22 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!
Summary: [RFE] Exposing HTML Editor commands to Browser Dom → Exposing HTML Editor commands to Browser Dom
Comment 14•22 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
Comment 16•19 years ago
|
||
Has this been done, perhaps, with canvas?
Comment 17•19 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•19 years ago
|
||
I think this can be closed as invalid because Midas covers this and there are other bugs requesting contentEditable.
Comment 19•16 years ago
|
||
For me, this is a duplicate of bug 177700 (designmode implementation) and bug 237964 (contenteditable implementation).
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Updated•11 years ago
|
Component: DOM: Mozilla Extensions → DOM
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•