MathML-3's copy-and-paste

A new draft of MathML-3 has just come out. It has a bunch of good maturations. But it also has a very nice new section on clipboard support which could generalize.

The problematic is classic: if you copy a selection of the web-page, what will end up in your clipboard? Generally, plain-text works in all cases, HTML works in several cases, RTF often works as well. With MathML? Well, it was not easy thus far.

The section 7.2 proposes a way to compliant processors to allow MathML-fragments to be copied with great flexibility: using the semantics elements, an arbitrary element can be decorated with alternate representations of any given mime-type. Something along the lines:

     <annotation-xml encoding="MathML-Content">....</annotation-xml>
     <annotation href="../fRender?coord=1723;type=png" encoding="image/png"/>
     <annotation href="../fRender?coord=1723;type=tex" encoding="text/tex"/>
     <annotation href="../fRender?coord=1723;type=maple" encoding="text/maple"/>

The fancy bit are these annotation elements which are now allowed to have an href element.The section 7.2 of MathML3 now says that a copy-action of this math element should export several clipboard flavours: the png flavour should be pulled from the URL ../fRender?coord=1723;type=png” encoding=”image/png, etc.

The big novelty here is that it allows content-producers to be allowed to deliver content to the users’ clipboards with a flavour they can choose. This allows servers which have rich conversion services to offer them transparently to the user without bloating the web-page delivery and by avoid useless load on the server since this conversion is done only when the copy action is requested (typically, there will be many such math islands but few copies).

To me, this looks like a very general mechanism and I wonder if that would not be the right thing to propose to the WebAPI working group to replace the current javascript clipboard APIs (a stagnant spec and loads of incompatible implementations.

It would need to be complemented by the realization of form elements that should control their acceptable types. And that would very well be done by adding a simple attribute to input elements to indicate the (list of) preferred mime-types once can “paste” inside this input element.

Many example flavours would apply here… for example the ICS format for appointments, the VCF format for personal information, the Dublin-Core record for bibliographical info, a fragment of code in either beautified HTML or plain-text form, a picture in rasterized and vector formats…

Trackback URL for this post: