Composer should have a Add a equation or add mathml or something similar.

Marking NEW.

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.

-->brade

spam composer change

-->

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 (http://www.newmexico.mackichan.com/MathML/mathmled.htm), 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.)

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.

For quick reference, adding dependency to bug 111514 which exposed the HTML DOM for XHTML documents served as application/xhtml+xml.

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.

.

:( 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

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.