Can I somehow prevent the ContentEditor to touch MathML snippets?

[cyclaero]

I am in need to add some not too complicated math equations into an article which I happen to write using the ContentTools. Since this is rarely needed, I decided to simply add the equations by pure MathML snippets within normal <p> tags. This looks nice until the ContentEditor touched the snippet and joins all <mi> tags on a line and removes all nested <mrow> tags. Besides it scrambles the formatting of the snippet, which is somewhat cumbersome, because MathML code without adequate formatting is almost unreadable/-editable (for me).

I am not asking for a MathML editing feature. For me, it would be perfect, if the ContentEditor would leave anything enclosed by <math></math> tags alone. Can this be achieved somehow?

I guess I need to change something in the HTMLCleaner, needn't I?

[anthonyjb]

So unless you want to be able to edit it in CT (which wont work out the box) then I would suggest making the p tag static so that you can drag it about but CT doesn't try to parse it, I think to do that you'd do:

<p data-ce-tag="static">

[cyclaero]

I just tried it to embed the MathML snippet into a <p data-ce-tag="static"> element, and it really prevents CT from doing any changes. Only, now I also cannot open the p-tag code editor of CT for changing the snippet, and I have to use nano on the server machine for inserting the math code into the HTML file.

In the past I already did changes to the CT sources to my needs. Perhaps, I would need to add only two or three lines of code, something alike:

if (childName != 'math' && childName != 'svg')
    parse the child's HTML as usual
else
    clone the child's HTML without any change

If this would be not too complicated, please can you give me an advice where it would be best to add this. If this is not easily feasible, I will stay with <p data-ce-tag="static"> and enter the MathML somehow, using an external editor.

[cyclaero]

In the meantime I learned the hard way, that MathML, in spite of being a HTML5 standard, is not supported by a huge lot of browsers, namely all those based on the Chromium project. Only Firefox and Safari do a nice MathML rendering. MathML became a dead-end road on my site, and I reworked the few math equations which I wanted to present in pure SVG.

Now the HTML parser in CT got problems with the self-closing PATH-Tag. I added HTMLString.Tag.SELF_CLOSING.path = true; to my script before launching the ContentTools, but this lets CT crash whenever it tries to parse a <path ... /> element. This is because of the XML-closing slash. When I remove the slash, CT does not crash, but unfortunately then the path-element does not work either.

Now, I enclose all SVG with <p data-ce-tag="static">, and since this is only an occasional need, I will happily stay with this solution and with editing any SVG with an external editor.

Anyway thank you very much for your help and your time.

[anthonyjb]

@cyclaero thank you for spending the time to document your experience in such detail. I've no experience of MathML so it's interesting to hear the problems that you had with it and with CT's handling of it.

SVG images will be support in CT2, including inline images - however - I have no plans as it stands to allow these to be edited directly within the CT editor beyond being able to insert a new SVG image or for inline SVGs being able to replace their source - so I'm not sure if that would be a solution for you though it may go some ways to improving things. We also struggle with the lack of SVG support now and have to find ways around it.

Thanks again for your detailed responses.

[cyclaero]

@athonyjb, allow me a few comments. While MathML is for me of no concern anymore, SVG is. I realised the mentioned math equations in hand-written SVG. And if I would be able to place this somehow into a non-static <p> tag by using CT, this would be great.

By the way, in the meantime, I found a solution for the <path /> problem. The closing /> may be replaced by ></path> which seems to be still valid SVG, and I only need to put a   between the opening and closing tag in order to prevent CT from optimizing the whole tag away. A little bit ugly, but it got the advantage that it works.

I tend to believe that CT would sufficiently support inline SVG and other XML based additions, if it would simply facilitate editing of the sources in the .ct-properties-dialog__inner-html dialog, and would not try to parse and optimize these snippets.

I think about placing a tiny SVG image inline within a paragraph. I would open the CT properties dialog and paste the SVG snippet where I want to have it, it is pure text anyway. BUT, then I must insist on CT leaves everything inside of <svg>...</svg> alone. Nothing less, nothing more.

I think of any user wants to place an SVG image like a PNG or JPG somewhere on the page. Most users won’t even understand the differences, since an image of a rose is a rose is an image, isn’t it? I think it would be really sufficient that the image tool just allows uploading of the SVG source. The backend needs to do something about it and then CT would need to place the returned URI into the src property of the <img...>-tag. Isn’t this all almost already in place?

[anthonyjb]

The option to allow a user to set the inner HTML for a static element might be an option and in this scenario we simply wouldn't attempt to optimize the inner HTML. I'll certainly add a not for that in CT2 but also something we could perhaps add sooner.

It's fairly easy to support uploading of SVG images currently as you say (provided you return some basic information on the size as this can't automatically be queried from the image as it can with a raster format). We tend to use SVG inline when we want to edit the SVG's appearance using CSS and so our current work around for that is we use snippets and ContentFlow and give the snippet an editable attribute for the SVG's content.

[cyclaero]

Thank you very much for considering an enhancement to CT2.

If you point me to a location in the CT sources where parsing/optimisation could be conditionally skipped for SVG elements, so these would be treated and returned like black boxes, then I could have a look at it and perhaps I could come up with a solution and save you from some work.

Regarding image uploading, my backend (ContentCGI written in C) is linked against the GraphicsMagick library and this converts everything to PNG, including PDFs and SVGs. I am a bit ashamed to advertise this, because this is not exactly a nice solution, and of course I could do it better. Anyhow, actually the SVG uploading part provided by CT works already perfectly, here only my backend is lacking in order not to say cheating. I put this now on my list to work on.