We need to factor out specific htmleditor code from the `generic' editor code. That way, it will be much easier to just plug in new formats, if we have generic code that doesn't know about the format, and that interacts with the format through a generic architecture. This is the tracking bug to track this work, as it will probably involve big changes.
Before this can start, there needs to be a consensus of exactly how a "plug-in", or a format should interact with the generic editor structure. Can anyone fill me in here, or is it up for discussion? Right now the plaintext format and html format is so tightly integrated that at least *I* cannot see a simple way for a new format - say XUL - to be hooked up.
Mike Judge has been working on something to do with editor embedding interfaces -- perhaps he or Saari can point us to the documentation or an example of how the editor should be initialized in the new world.
This sounds like a core issue and not Composer-specific
Assignee: syd → kin
Component: Editor: Composer → Editor: Core
We already have this modularization. It's called nsEditor. That's where the base functionality lives. html-specific is in nsHTMLEditor.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.