Open Bug 78128 Opened 24 years ago Updated 4 years ago

Ability to MathML specific Stuff in Composer


(SeaMonkey :: Composer, enhancement, P3)



(Not tracked)



(Reporter: rjkeller, Unassigned)


(Depends on 2 open bugs)


(Keywords: helpwanted)


(2 files)

Composer should have a Add a equation or add mathml or something similar.
Marking NEW.
Ever confirmed: true
Summary: MathML in composer → [RFE] Ability to MathML specific Stuff in Composer
Yes this would be a nice feature! Marking future for now since we won't have 
time to work on this before Moz 1.0.
Priority: -- → P3
Target Milestone: --- → Future
Assignee: beppe → brade
Keywords: helpwanted
spam composer change
Component: Editor: Core → Editor: Composer
Summary: [RFE] Ability to MathML specific Stuff in Composer → Ability to MathML specific Stuff in Composer
Assignee: brade → composer
Now that the HTML DOM is exposed for XHTML documents served as
application/xhtml+xml, coupled with all those things that have been going on
(there is a XUL+JavaScript MathML Editor), the scenery is a lot different than
when this bug was originally filed. Steve Swanson made a demo of Composer+MathML.
Care to attach your screenshot & patch, steve?
*** Bug 201748 has been marked as a duplicate of this bug. ***
Bug 55313 is about XHTML in Composer.  This bug doesn't depend on that one, 
but an implementation might.
With the patch in place, I can edit and save XHTML files. In particular, such
files can contain MathML.

Caveat 1. I've only tried out a few simple things. I doubt this is the correct
long-term solution for editing XHTML in Mozilla.

Caveat 2. No attempt is made to edit MathML.  That's been to goal of my
mathmled project (, but
a significant amount of work is needed to bring that code over.
(I've probably messed-up the patch because I don't know how to build patches
across directories.  I hope it's clean what I did.)
Attached image screenshot
Please break the XHTML loading/saving into a separate bug. I think this patch is
not enough, though, because the composer insists on some HTML doctype AFAIK.
Maybe I am wrong?

You can do diff multiple directories/files in one command by simply adding the
dirs  at the end of the command, like this:

cvs diff -u dir1 dir2 dir3

However, in your case I would just cd to mozilla, then cvs diff -u editor
Further experimentation shows that almost everything in Composer works in 
XHTML documents (with the patch).

The only major hole is Copy/Paste and Drag/Drop.  Sometimes, these appear to 
work, but in fact the operation causes the tag names to uppercase, breaking 
XHTML and MathML.

Poking around, I think the content is serialized to the clipboard in a 
reasonable fashion, but the data is taken off with the HTML parser.  Fixing 
this will probably involve a new clipboard format.  (I don't know whether a 
special XHTMLeditor component is actually necessary.)
With the ongoing push towards separate applications rather than a monolothic
suite, there may actually be more chance for novelties in Composer than in the
other applications. 

I hope MathML will come to composer sooner rather than later this way. It would
be killer that will give an edge to composer -- something, that even commercial
editors are unlikely to have.

>The only major hole is Copy/Paste and Drag/Drop.  Sometimes, these appear to 
>work, but in fact the operation causes the tag names to uppercase, breaking 
>XHTML and MathML.

If everything else is working really really fine, leaving aside the
enthusiastic/lenient testings :-) the point above doesn't look like a big deal
to me since the infrastructure is there. Specifically, it seems that an |if| is
needed somewhere: if the MIME type was indeed HTML then keep the HTML serializer
|else| use the XML serializer, both of which exist at present.
I don't think the HTML/XML switch is so easy.  If you look at 
|nsHTMLEditor::ParseFragment| (in nsHTMLDataTransfer.cpp), you'll see that it 
creates an HTMLFRAGMENTSINK then calls the parser with MIME type "text/html".  
Using to the XHTML MIME type invokes the XML parser, but it fails because it 
wants to see an EXPATSINK.  What is needed is an XMLFRAGMENTSINK, but I don't 
see any evidence that exists yet.

Otherwise, I agree.  The infrastructure is there.
Had a look and it reminded me of nsRange::CreateContextualFragment()... Looks
like that code is smilar to the range's CreateContextualFragment() which doesn't
work for XML too... bug 133827 comment 5 - bug 133827 comment 6.
I built a nsXMLFragmentContentSink and was able to Copy/Paste XHTML+MathML in 
my patched Composer.

I'm not attaching a patch for this because the changes are rather widespread 
(a new interface is needed).  nsXMLFragmentContentSink isn't all that hard 
anyway: just merge nsHTMLFragmentContentSink and nsXMLContentSink.  It only 
took me about a week. ;-)

Furthermore, I'm convinced that in order to do XHTML in Composer, a new 
nsXHTMLEditor component is needed, rather than just a few strategically placed 
switches based on the document MIME type in nsHTMLEditor.  Again, this should 
be straightforward. ;-)

I haven't checked whether my nsXMLFragmentContentSink is a fix for bug 133827.
Blocks: 207531
For quick reference, adding dependency to bug 111514 which exposed the HTML DOM
 for XHTML documents served as application/xhtml+xml.
Depends on: 111514
Just as a note, getting composer to work with XHTML needs, as a first step,
replacing all tagname comparisons in composer with tagname and namespace
comparisons, or better yet checks for nsIContent::eHTML and tagname comparisons.
I happen to be working on a MathML editor in XUL for Composer.
Assignee: composer → ajvincent
Product: Browser → Seamonkey
:( There's hardly any work being done on Mozilla Composer, and my efforts to tie
in MathML (Abacus) were largely unsuccessful.  This is due to certain
architectural decisions with Composer.

I will be reworking Abacus in the future to work with Verbosio, a prototype XML
editing architecture.

-> default owner/QA
Assignee: ajvincent → composer
QA Contact: sujay
Assignee: composer → nobody
QA Contact: composer
I would be very interested in finding out if there have been any new developments in this direction on the Composer and it's capacity for working with XHTML and displaying MathML.
Depends on: 986839
Depends on: 987028
Depends on: 145736
Depends on: 1098150
See Also: → 1065842

MathType now has an option «Thunderbird» in the «Cut and copy Preferences», which works fine with Composer and Mail in that one can insert directly into «normal» sheet, not necessary in HTML code.

You need to log in before you can comment on or make changes to this bug.