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 * '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.
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 Mozilla's.
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
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!
17 years ago
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: 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
Mass-reassigning bugs to firstname.lastname@example.org
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.
For me, this is a duplicate of bug 177700 (designmode implementation) and bug 237964 (contenteditable implementation).
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 177700
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.