mirror of
https://github.com/Smaug123/KaTeX
synced 2025-10-10 21:48:41 +00:00
* Make KaTeX work in Quirks mode Summary: In issue #601, it was noticed that the KaTeX bug with the fraction bars overlapping the text was occuring with an XHTML doctype. This indicated that the bug we were seeing was caused by both quirks mode and limited-quirks mode (which is a version of quirks mode with fewer quirks and is enabled for various doctypes including some XHTML ones). Based on the [quirks spec](https://quirks.spec.whatwg.org/), it appears that there are only two quirks in limited-quirks mode, both having to do with a line-height calculation. @gagern figured out that if we added some zero-width spaces in our elements, we would stop triggering the quirk, which would make our fractions render correctly in limited-quirks mode. I implemented that change, and ran the screenshotter in limited-quirks mode. There were several other places that suffered from the same quirk, but were also easily fixed via adding zero-width spaces. I then ran the screenshotter in quirks mode, and discovered that (once an appropriate meta charset was added), everything looked correct still. So, this diff fixes all of the places that the limited-quirks mode quirks affect our rendering, and removes the warning about rendering in quirks mode. I also added support to our screenshotter to render things in both no-quirks and quirks mode, to ensure that things don't break in the future. I copied the non-quirks images to the quirks images, and ran the screenshotter with `--verify` to make sure that they look the same. I have some thoughts that I'd like to hear opinions about: - I'm not super happy with how the screenshot tests work. Ideally we'd test both quirks mode and non-quirks mode against the same images, since we'd like them to be the same. I'm not sure how to make that work well, though, since then people wouldn't be able to tell if it's a quirks-mode problem or not. - I removed the doctype in the testing page file, so all testing would now be done in quirks-mode. Not sure if we really want that. - I need to test this in IE, but it looks like the trailing commas change we made with eslinting is causing problems (cause IE doesn't like trailing commas). Test Plan: - `./dockers/Screenshotter/screenshotter.sh --verify` * Compare quirks mode against same screenshot files Now the screenshotter itself can run more than one mode. It does serve the HTML file from its own JavaScript code now, so that it can include different doctype headers without needing distinct files for each. There is a provision to mark specific tests as quirky in case they produce different results depending on the mode. * Some cleaning up and comments * Restore access to the babelified version of the HTML page for screenshots * Reference unicode fonts using absolute path names This avoids issues caused by the fact that the dynamically generated ss-render.html is mounted to a different location than the test.html from which it is derived. * do chrome screenshots first * remove commented out code, simplify hadle_search_string call
61 lines
1.7 KiB
JavaScript
61 lines
1.7 KiB
JavaScript
/* eslint no-console:0 */
|
|
/**
|
|
* This is the main entry point for KaTeX. Here, we expose functions for
|
|
* rendering expressions either to DOM nodes or to markup strings.
|
|
*
|
|
* We also expose the ParseError class to check if errors thrown from KaTeX are
|
|
* errors in the expression, or errors in javascript handling.
|
|
*/
|
|
|
|
import ParseError from "./src/ParseError";
|
|
import Settings from "./src/Settings";
|
|
|
|
import buildTree from "./src/buildTree";
|
|
import parseTree from "./src/parseTree";
|
|
import utils from "./src/utils";
|
|
|
|
/**
|
|
* Parse and build an expression, and place that expression in the DOM node
|
|
* given.
|
|
*/
|
|
const render = function(expression, baseNode, options) {
|
|
utils.clearNode(baseNode);
|
|
|
|
const settings = new Settings(options);
|
|
|
|
const tree = parseTree(expression, settings);
|
|
const node = buildTree(tree, expression, settings).toNode();
|
|
|
|
baseNode.appendChild(node);
|
|
};
|
|
|
|
/**
|
|
* Parse and build an expression, and return the markup for that.
|
|
*/
|
|
const renderToString = function(expression, options) {
|
|
const settings = new Settings(options);
|
|
|
|
const tree = parseTree(expression, settings);
|
|
return buildTree(tree, expression, settings).toMarkup();
|
|
};
|
|
|
|
/**
|
|
* Parse an expression and return the parse tree.
|
|
*/
|
|
const generateParseTree = function(expression, options) {
|
|
const settings = new Settings(options);
|
|
return parseTree(expression, settings);
|
|
};
|
|
|
|
module.exports = {
|
|
render: render,
|
|
renderToString: renderToString,
|
|
/**
|
|
* NOTE: This method is not currently recommended for public use.
|
|
* The internal tree representation is unstable and is very likely
|
|
* to change. Use at your own risk.
|
|
*/
|
|
__parse: generateParseTree,
|
|
ParseError: ParseError,
|
|
};
|