MathML in headings, problems in nav file

[MartheGjelstad]

It seems like MathML in headings is causing issues in the nav file. Can the nav file contain MathML?

[samimaattaCelia]

The EPUB 3.3 specification document actually has a note that you shouldn't use MathML in the nav document. (7.3 The nav element: restrictions):

Although the headings and links in nav elements allow any [html] phrasing content, app-based reading systems often only support simple text labels. Because these apps create their own navigation widgets that are not based on HTML rendering, they often cannot retain embedded images and multimedia, MathML, inline styling and other element- and attribute-based rendering instructions. EPUB creators should avoid using these types of elements where their absence may lead to usability issues.

So, although it is not banned, the reading systems pose restriction on their usage.

It depends a lot on the content what the compromise should be. If the whole heading is MathML, then it is a problem. Otherwise you could instruct that there should be no math in the heading? Or that the math should be written in plain text. These are not optimal solutions, but could work.

[TimArborealis]

Sounds to me like we should avoid using MathML in headings. I think we should have a section in the guidelines on what to use instead. Can elements like <sub> and <sup> be used, for instance? As an example, how should this heading be marked up?

[samimaattaCelia]

I haven't tested, but I would imagine that it's a problem based on the text from the EPUB guidelines: "-- other element- and attribute-based rendering instructions."

I don't really know a good solution to this one other than we would just drop all the MathML and HTML elements that are not 'simple' and let the text be as is. For example, "8. x2-metoden". Or then it could be spelled out: "8. x-två-metoden", which is more work.

[TimArborealis]

I think it would be good to include Linda and Elise in this discussion.

[eliseaas]

I agree with Sami on using plain text for the headings, I think that's the best practice for adherence to the epub guidelines and to support all reading systems.
We could alternatively present the example above with "8. X^2-metoden" to signify it being in superscript, but the most risk-free option is probably as written, "8. X2-metoden".

[samimaattaCelia]

For the supplier it might be easiest to tell to just transform the heading into plain text, since there are probably automated tools for this. That is why I would lean on the "8. X2-metoden", since it will remove all ambiguity on the authoring. Hopefully no author will write a super complex heading with math.

[lindheli]

It is possible to use sub/sup elements in headers, in the same way as for example footnotes can be added in headers. So, not too complex markup can be added to headers even if mathml should be avoided. See for example added test file with conversion/TTS in Webarch. Note that I had to zip the Epub file to be able to upload.

minitest_260223.zip

[TimArborealis]

In that case I think we should actively encourage the use of <sub> and <sup>, as well as advice against using MathML in headings. I'm thinking that exponents reduced to plain text might cause confusion for the reader. Looking through a few of our university textbooks it seems to me that it is not uncommon to use exponents in headings.

Example of one to be handled using <sup>:

Another example, where plain text would suffice:

There are some instances where bold typeface carries mathematical meaning. Is it possible to use <strong> or similar in headings in our EPUBs? Example:

Other than that, I haven't come across any more advanced maths in headings which can't simply be solved using linear Unicode.

[lindheli]

yes, <strong> and <em> can be used in headings. Note though that some headings are by default already bold with css, so visually it will not be clear.

[MartheGjelstad]

Make a subsection in the section "Some Things That Should Be In Plain Text" with the name "Navigation file". Explain to not use MathML, but <sub> and <sup>. Use unicode characters if necessary.