Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adding input processors to default.js #586

Closed
pkra opened this issue Sep 26, 2013 · 9 comments

Comments

Projects
None yet
3 participants
@pkra
Copy link
Member

commented Sep 26, 2013

Is there a reasons why default.js doesn't load all input processors / doesn't mention the code in the comments?

As we say in our docs:

the default.js file contains nearly all the possible configuration options together with comments explaining them, so you can use that file to customize MathJax to your needs.

Seems like we don't.

@fred-wang

This comment has been minimized.

Copy link
Contributor

commented Sep 26, 2013

I think the idea of the default is to give the most common setup and the most used modules, so for the processors just input TeX and output HTML. The *-full configurations are more appropriate otherwise. However, that's true that the comments should mention the other input/output modes.

@pkra

This comment has been minimized.

Copy link
Member Author

commented Sep 26, 2013

That's not how I read the documentation and not how I've thought about default.js in the past. At the very least MathML should be in the list of input processors!

@fred-wang

This comment has been minimized.

Copy link
Contributor

commented Sep 26, 2013

There is the "nearly" :-) I think what's intended is to list all the configurations (at least in the comments) but you can not test all the values, you have to select a specific config anyway. Perhaps @dpvc can explain what's expected.

It seems to me that, when I joined the project, most people use the TeX input. I've seen a few people talking about the MathML input on the mailing lists but not that much. Perhaps we can update default.js if that has changed. I think we still can't know about the usage of input MathML / AsciiMath on the CDN?

@dpvc

This comment has been minimized.

Copy link
Member

commented Sep 26, 2013

I just made the following comment on Neil's issue #587 (during which you closed it):

I think this is a confusion over the use of the word "includes". This was meant to mean that the default.js lists all the things that can be configured (e.g., the jax, the extensions, the HTML-CSS parameters for equation chunking, the TeX parameters for equation numbering, and so on). That is, if something can be configured through MathJax.Hub.Config(), then it should be included in this file. That does not mean that every extension or optional piece of MathJax is activated by default.js (i.e., not every extension is included into your web page by the default default.js).

The default.js file has always only included TeX input and HTML-CSS output in the jax array. That comes from the old days before we had the CDN, and everyone had their own copy of MathJax. At that time, default.js was read automatically to perform MathJax configuration, and originally, these where the only input and output available, so they were the only ones listed. Later as more were added, we didn't want to change the configuration that everyone was using, so we left just those.

It would be possible to add the other input and output jax, but since this isn't a combined configuration file, that would cause additional file downloads, so I'd prefer not doing so. Also, if you want to get MathML output automatically for IE/MathPlayer, you don't want to specify an output jax and instead include the MMLorHTML config file in the config array, as that is the code that makes the decision for you.

@pkra

This comment has been minimized.

Copy link
Member Author

commented Sep 26, 2013

Thanks, Davide, for clarifying that this has not changed.

We all seem to agree that we need to list the input processors in the comments.

As for adding other inputs, in particular MathML. Some pros and cons.

  • As Neil experienced, anyone looking at MathJax as a MathML polyfill will be surprised that default.js does not work with MathML. Hence my strong leaning towards having it in there.
  • Personally, I find it odd that anyone uses default.js except for learning MathJax.
  • I've looked at the logs and default.js is used by ~1.5% of CDN users
  • How large of a load are we talking about? What gets loaded if there's not MathML on the page? Assuming the entities aren't loaded, I see ~15KB. Is that correct?

I do think that 1.5% / 15KB are prohibitive of changing its behavior in v2.3. But I'd be much in favor of changing this in the next semantic jump.

Finally, I'm curious. Davide, you wrote "when TeX was the only input option" -- was that ever the case?

@dpvc

This comment has been minimized.

Copy link
Member

commented Sep 26, 2013

What gets loaded if there's not MathML on the page?

Just the jax/input/MathML/config.js file, which is about 2KB uncompressed, and you would also need to include the mml2jax extension for another 8KB. It is not the amount of data so much as the two extra network accesses to get the files that is the cost for this.

you wrote "when TeX was the only input option" -- was that ever the case?

I think so (it is pretty far back). I remember announcing beta support for MathML input at the JMM at one point, and I know there were people already using MathJax at that time. Perhaps it was just 1.0-beta, however. The 1.0 docs do seem to include it.

If you want to include all the input processors (and their associated preprocessors), that's OK with me. I was just saying why it wasn't done originally. The expectation was that pages would know what input form they planned to handle, and would include just the jax and preprocessor for that. We hadn't really thought about multiple input formats on one page (or single configurations that covered different pages with different types of input). As long as people where hosting their own copies, it seemed reasonable for them to take a moment to configure MathJax via this file.

Once we went to the CDN, and they could no longer edit the files, we built the combined configurations which both gave them a number of common setups to choose from, and reduced the number of file downloads. At that point, we considered default.js to be more of an example than something anyone would actually use directly. It is more efficient to load a combined configuration plus a local customization file than to use default.js (either from our server or from a local copy), so this was not a use-case that we expected to see. Form that viewpoint, default.js represents an example, and documentation of the options, not an actual in-use configuration file.

@pkra

This comment has been minimized.

Copy link
Member Author

commented Sep 30, 2013

Thanks for the background, Davide.

I'm a bit torn. I would prefer to add all of them. But at the same time we have a lot of people not configuring MathJax efficiently (not just by using default.js but generally speaking). So perhaps detailed comments are better?

I'm wondering if (in the long run) we should remove default.js from the CDN and make it part of the tests // documentation instead. There's still the idea of a configuration builder in the backlog and we could offer to host many configurations on the 3rd party repository. Just some random ideas.

@dpvc

This comment has been minimized.

Copy link
Member

commented Feb 14, 2014

I suppose moving default.js to documentation would be OK. For now, I've added comments listing the possible choices for the jax.

One of the other things this file was supposed to do was list the actual default values for the parameters is includes. I'm not sure that is true any longer, and there are some exceptions (like the jax and extensions array (which are actually empty by default).

dpvc pushed a commit to dpvc/MathJax that referenced this issue Feb 14, 2014

dpvc pushed a commit to dpvc/MathJax that referenced this issue Feb 15, 2014

@dpvc dpvc added Merged and removed Ready for Review labels Feb 15, 2014

@dpvc

This comment has been minimized.

Copy link
Member

commented Feb 15, 2014

=> Merged.

@dpvc dpvc closed this Feb 15, 2014

@dpvc dpvc added v2.4 and removed Merged labels Jun 30, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.