Technical issues, and rewrite notes

[jared-hughes]

GitHub says it's sunsetting classic projects, which would mess with some existing notes (by @mikehaverstock, from 2018 Nov 9, but the points seem to still stand). The contents of the projects are copied to this issue (italics are my notes). The original projects were Rewrite Overview and Technical Issues.

Rewrite Overview

Organizing thoughts on what we like, don't like, and must keep about mathquill.

Good

• The cursor and selection feel really close to native
• Easy extensibility of autoOperatorNames
• Auto closing parens and brackets -- they just work great
• Layout -- I've looked at KaTex, MathJax, and LaTeX in general. None of them look as good as mathquill in edge cases
• Keyboard navigation and editing (arrow keys, tab, shift, etc)

Bad

• (fixed?) Throws random errors -- we think the bulk of these problems are related to mathquill relinquishing control in the middle of atomic updates. It should queue events and only give control back once atomic updates finish.
• Code is super hard to understand
• Performance -- it's built heavily on top of jQuery so it's just slow (jQuery now removed, but it's still slow due to parser and DOM measurements)
• Full render requires DOM measurements -- top of my head is parens. We've repeatedly run into issues where parens are not sized correctly if initial render happened when root was display:none
• Difficulty of having multiple configurations on the same page

Must Keep

• Horizontal Scrolling
• Some way of listening to keyboard events -- the dream is that we push off this project (proposed rewrite) long enough that all supported browsers have nice interfaces. It'd be great to be able to ditch the super convoluted textarea tracking code.
• Accessibility -- I don't fully understand how this works currently, but there's a chance we can make it better if we consider it from the start
• Special-cased ans node. (now tokens too)
• Efficient rendering updates for simple expressions -- important for animated sliders and dependent table columns

Technical Issues

Places Mathquill currently takes DOM measurements

• While rendering: .reflow() for sqrt, and parens. This would go away if we calculated heights instead of measuring them (like Katex).
• While editing with keyboard and mouse -- .scrollHoriz, .offset, .seek, clickAt, .setOverflowClasses (horizontal measurements would not go away by calculating heights)

ans

• Efficient ans updating may be tricky.
  • If we use 100% absolute positioning - we need to shift everything after the ans rightward
  • If we use horizontal flow then we can just find the dom for ans and update the innerText
• One idea is to pre-process latex going into mathquill and post-process it coming out of mathquill. You'd substitute in the current ans value right before handing latex off to mathquill and you'd strip it out before reading the latex from mathquill.
• It's possible we never have to think about it, but rendering ans on canvas won't work if we need to do a separate external pass over the DOM
• How do we cleanly pass in the value for ans so that mathquill can do the substitution for us?

Canvas rendering?

• I'm leaning towards doing what KaTeX does. position vertically using em units and just let the browser flow horizontally. It means we need to do something special for canvas rendering. We need to measure the horizontal width of characters. But that doesn't seem super tragic. On canvas you can't get incremental rendering updates. You must completely clear and redraw. You can probably memoize the character widths so only the initial render will have to do the measurements. And it's possible that the cost of measuring the width of a character about to go on a canvas is comparable to the cost of a browser managing the horizontal flow anyways.
• 100% absolute positioning is good for canvas support but requires more work. I'm not sure if it's more efficient to let the browser do horizontal flow or if it's more efficient for us to set a new root width and height and then position everything absolutely.
• KaTeX only computes the vertical distances. It lets the horizontal flow naturally. That's why it doesn't automatically support canvas rendering.
  • If we computed horizontal distances then we could use 100% absolute positioning. That would mean rendering to canvas wouldn't be any harder.

Horizontal scroll

• I don't know how 100% absolute positioning helps here. We'd know the inner content width in em units, but that doesn't help us too much. We still need to measure the actual container width in px units. Then we need to convert the inner em units to real pixels. It's probably just worth measuring the outer and inner at the same time.