Refactor documentFragment and implement both HtmlDomNode and MathDomNode interfaces (stepping stone to port buildMathML to flow) (#1478)

* Make MathNodeClass include documentFragment for ergonomics.

* Separate out the HTML and MathML documentFragments.

These two documentFragments have different additional properties/methodsi
and limitations. This separation is needed for porting buildMathML to
flow.

* Coalesce the documentFragment subclasses to avoid subclassing polyfill.

* Make DomSpan and SvgSpan type aliases again instead of subclasses.

* Remove type MathNodeClass in favor of MathDomNode.

* Resolve $FlowFixMes by reordering variants of a union type.
This commit is contained in:
Ashish Myles
2018-07-16 02:41:27 -04:00
committed by ylemkimon
parent 48e9058a06
commit f0976ade26
11 changed files with 129 additions and 103 deletions

View File

@@ -1,7 +1,7 @@
// @flow
import defineFunction, {ordargument} from "../defineFunction";
import buildCommon from "../buildCommon";
import domTree from "../domTree";
import mathMLTree from "../mathMLTree";
import ParseNode from "../ParseNode";
import * as html from "../buildHTML";
@@ -16,7 +16,7 @@ function htmlBuilder(group, options) {
function mathmlBuilder(group, options) {
const inner = mml.buildExpression(group.value.value, options);
return new domTree.documentFragment(inner);
return mathMLTree.newDocumentFragment(inner);
}
// Math class commands except \mathop