Add a linkedom adaptor (mathjax/MathJax#2833)

[dpvc]

This PR adds an adaptor for the linkedom node-based DOM implementation.

Resolves issue mathjax/MathJax#2833.

[swamidass]

Thanks @dpvc . When do you think this will get integrated into MathJax?

[dpvc]

It will be merged into develop when the code is reviewed, and into master for the next release, which is still several months away.

[zorkow]

As this is now the third adaptor which share very similar components (with liteAdaptor, jsdomAdaptor) I believe that it is time to refactor the common elements into an abstract superclass.

[zorkow]

I believe that it is time to refactor the common elements into an abstract superclass.

As a common superclass might not fit, as some inherit from HTMLAdaptor maybe could have at least have common utilities to the static elements like OPTIONS and cjkPattern.

[dpvc]

As this is now the third adaptor which share very similar components (with liteAdaptor, jsdomAdaptor) I believe that it is time to refactor the common elements into an abstract superclass.

I did that in the next PR. I didn't do it here because I referred the original requester to this PR to get the linkedom adaptor until this is public. So the refactoring was in a separate PR.

As a common superclass might not fit, as some inherit from HTMLAdaptor maybe could have at least have common utilities to the static elements like OPTIONS and cjkPattern.

I considered that, but used a mix-in instead.

[zorkow]

I considered that, but used a mix-in instead.

I also thought about that. But having tried to explain mixins here for an afternoon, I am now aware that they add considerable hurdles to understanding the code.
I always liked that about C++ (or CLOS) having multiple inheritance, friends, ...

[dpvc]

But having tried to explain mixins here for an afternoon, I am now aware that they add considerable hurdles to understanding the code.

Yes, some can be complicated, and not quite as flexible as I would like. But the one used here is less complicated than the more sophisticated ones need for MathItem and MathDocument render actions (which are pretty horrible). So I thought this was reasonable.

I, too, which there were an easier way to deal with multiple inheritance.

[swamidass]

Why not use a pollyfill for getComputedStyle?

E.g. see https://gist.github.com/abbotto/19a6680bf052e8c64f6e and https://github.com/mikemadest/jest-environment-linkedom/blob/main/src/get-computed-style-polyfill.js

[dpvc]

(Sorry, see my comment below. I entered it in the wrong box.)

[dpvc]

Both of the links you provide are only polyfills to get a version of getComputedStyle() to work in Internet Explorer (and older versions of Opera). They rely on currentStyle, which is a non-standard IE-only property. So this doesn't work in linkedom or jsdom or liteDOM, none of which implement this.

To get a version of getComputedStyle() to work in these settings, one would have to interpret all the CSS files, and all the inheritance involved in the CSS cascade. Doing that for all elements just to be able to use getComputedStyle() in the few cases MathJax needs it would be a huge performance hit. Even trying to do it just for the limited properties MathJax needs (e.g., the font size) would still require loading and interpreting all the CSS files, and determining which selectors apply to the element and every parent element until one of them sets the needed property. This is still a pretty big undertaking, and a non-trivial bit of coding. If someone wants to implement that, I'd be happy to entertain it.

[swamidass]

Got it. I see the problem. If it's a similar problem with the other adapters, it shouldn't be a show stopper here.

[dpvc]

Yes, all the node-based adaptors have the same issue. The getComputedStyle() function only works in the browser.

[swamidass]

@dpvc thank you for the detailed help you've offered me here. I really appreciate it.

I've been trying to figure out how to use the develop branch in my project to make use of the linkedom adapter, but it seems Mathjax has a confused build process that npm can't understand.

I thought that this would work,

npm install mathjax/MathJax-src#develop

but it doesn't. This does pull the development version into node_packages, but it doesn't actually build anything. Is it possible that this could be fixed by adding the right "build" script to package.json in the develop branch? Or is there another trick for importing and building mathjax from github using npm? Or is there a way to get the development branch from the npm registry somehow?

[dpvc]

You are right that the GitHub repository doesn't include the compiled or webpacked versions of the files, and doesn't build those on install. You would need to

cd node_modules/mathjax-full
npm install
npm run -s compile
npm run -s make-components

The last line is only needed if you are using one of the component-based means of accessing MathJax. If you use the direct approach, only the first three lines are needed.

[dpvc]

(sorry, left out one line. You probably need npm install before npm run -s compile. I've added it to my comment above)