Mathjax backlog

We collect potential features. This is not a discussion area but a presentation area for review.

The future development tasks for MathJax fall into three broad categories that are closely intertwined.

1. Continuing the original project goals
2. Adapting to the constantly evolving state of art on the web
3. Expanding our goals

The following is out of our development backlog. The color codes indicate how they relate to the overall goals. The asterisks give an indication of each deliverable’s complexity.

1. Completing the MathML implementation

2. elementary math O (**)

3. more mtable attributes (e.g., rowspan, colspan) O (***)

4. in-table alignments O (***)

5. right-to-left support OO (**)

6. improve annotation-xml OO (**)

7. improving ContentMathML support O (*)

8. Speed Improvements

9. “simple” (fast but lower quality) HTML-output OO (**)

10. Caching APIs for local storage and mobile device storage OO (***)

11. Move towards “jquery of math” by implementing a “tweaked” native MathML output that works around browser implementation deficiencies. OOO (***)

12. server-side preprocessing (TeX to MathML, MathML to SVG etc) OO (***)

13. Accessibility

14. Add APIs for accessibility tools (AT) to interact with MathJax rendering as if it was native MathML. This includes

15. compatibility to user style sheets (used for improved readability) OO (*)

16. interact with accessibility preferences coming from AT O (**)

17. handing MathML over to AT O (**)

18. embed speech-text generation from AT O (**)

19. enable synchronized highlighting O (***)

20. enable user navigation O (**)

21. basic math-speech extension

22. collaborating with other open source solutions from Benetech and Google’s ChromeVox O (***)

23. accessible MathJax menu O (*)

24. embedding alternative source formats of math (TeX, MathML, OpenMath, computer algebra notation) O (**)

25. Outreach activities O

26. Math accessibility workshop at AIM O (**)

27. MathJax community meetups -- virtual and real-life O (**)

28. MathJax in education (web literacy, authoring, annotation) O (**)

29. MathJax in authoring tool chains for research and publishing O (***)

30. Content Testing OO

31. server side testing OO (***)

32. production environment testing OO (***)

33. enable MathJax outside the DOM (***)

34. Internal Testing

35. fuzz testing OO (**)

36. integrating MathJax testing into other testing environments O (***)

37. Interface improvements OOO

38. better interface on mobile devices O (***)

39. improving copy&paste (share mechanisms, microdata, rdf) OO (**)

40. improve discoverability of math on the page OO (**)

41. menu extensions

42. search menu (enabling math search engines such as symbolab, wolfram alpha, Springer LaTeX search etc) O (*)

43. Fonts OO

44. Asana fonts OO (**)

45. DejaVu fonts OO (**)

46. crowdsource font-metric generation for local fonts O (***)

47. find ways to make use of commercial local fonts that we can’t deliver as webfonts but which are ubiquitous O (**)

48. Lucida Sans

49. Apple symbol fonts

50. Arial unicode

51. Output extensions OO

52. Canvas output OO (***)

53. VML output for old IE OO (***)

54. fluid output choice (content-dependent choice, mixed output modes) O (****)

55. “tweaked MathML” output (***)

56. Input extensions OOO

57. crowd-sourcing TeX-macro extensions O (**)

58. integrating XyJax (mixed), mathapedia (PStricks), graphing tools (d3.js, three.js, asciisvg), computer algebra tools (e.g. Sage Cell, R-notebooks, ipython notebooks) OO (**)

59. Documentation OOO

60. building more community involvement OO (**)

61. good code examples, moving towards a proper SDK OO (***)

62. document plugin using MathJax in other systems, e.g., CMS, LMS. OO (***)

63. Native browser MathML development in Gecko and WebKit O

64. This would be a major expansion of our mission -- but an overdue one.

65. re-enabling MathML support in Chrome / Blink (****)

66. Developing Gecko/Firefox at least on the level that allows us to keep a “tweaked” MathML output. (**)

67. Continuing WebKit implementation.

68. 6. 7. 8. NEED: list of features in FF & webkit, rough development plan etc

69. Outreach to other sciences

70. CML (chemistry) O (***)

71. CellML (computer modeling in biomed) O (***)

User stories

Collecting user stories).

Localization

Authors and Readers want to use the MathJax user interface in their native language. MathJax currently uses a number of English language strings in its UI, namely the MathJax Menu and the various messages (processing, error etc). To support global use of MathJax, a full localization of the UI allows MathJax users to flexibly decide on the locale and allows translators to contribute easily and efficiently.

Authors want to specify the UI language depending on the language of their content. Authors want to load translations they supply themselves, just like configuration options in general.

Readers want to be able to set the UI to their language of choice. Readers want to be able to copy&paste math even if they don't understand the surrounding language.

Using MathJax outside the DOM

Developers want to use MathJax outside the DOM for testing. MathJax depends on the DOM and parts of its functionality does not make sense outside the DOM. We want to enable MathJax outside the DOM to the extent possible and provide APIs for servers-side javascript implementations.

Testing speed

Authors want to know how fast MathJax should be. Authors and Developers want to track down performance bottlenecks.

We want to be able to test speed enhancements.

Accessibility

Users want their AT tools to pick up MathJax-generated content just as well as regular MathML.

AT vendors want to use a robust API to seamlessly integrate with MathJax rendering. This currently includes User preference negotiation, Highlighting, Sync-Highlighting and copy & paste.

Open source solutions (like Benetech's prototype or possibly ChromeVox) want to integrate into MathJax to provide math speech text and other data for passive AT on mobile platforms.

TeX input enhancements

Authors want the convenience of TeX packages in MathJax.

Authors want to easily input commutative diagrams.

Authors want easy ways to input diagrams like xypics, pstricks and tikz.

Users want documentation for writing TeX input extensions.

Speed related enhancements

Authors don't want to worry about very large equations locking up the browser while rendering. Simileraly, community driven content can't afford to have a page lock up because of "vandalism" with huge MathML equations. Compare: [#425], [#409]