Last modified: 2014-06-12 21:54:04 UTC
The extension could output TeX code inside a script tag with type math/tex. This would save one transformation on client side. This would mean that the decision block mode vs. inline mode had to be done on server side. (See bug 35188)
This one's trickier, since we don't really have context inside the extension run. :(
See http://math-test2.instance-proxy.wmflabs.org/wiki/Displaystyle for the proposed solution.
Rather than specifying "inline" for each inline math element I would suggest adopting the wiki2jax.js heuristics such that users need to add a qualifier only for overriding the default behavior. IMHO.
@physikerwel: do we still want to output script elements (in addition to SVG+MathML+PNG)? Or let wiki2jax process the correct TeX source from the new SVG+MathML+PNG output? @nageh: The plan is to move to server-side conversion, so heuristics that depend on the surrounding context do not really work. Also, it seems more reliable to let the user explicitly specify what kind of output he wants rather than trying to guess his intention.
I would prefer not to put additional script elements in the output. I think it would be great to use nageh's heuristics to write a not that sets the mathstyle.
(In reply to physikerwelt from comment #5) > I would prefer not to put additional script elements in the output. OK, I was just asking because of theDJ's comment on another bug. > I think it would be great to use nageh's heuristics to write a not that sets > the mathstyle. I don't think heuristics will be necessary anymore once you have the mathstyle mode. Your commit 119010 is already checking the CSS class for that.
(In reply to Frédéric Wang from comment #6) > > I think it would be great to use nageh's heuristics to write a not that sets > > the mathstyle. > > I don't think heuristics will be necessary anymore once you have the > mathstyle mode. Your commit 119010 is already checking the CSS class for > that. Ah, sorry you meant a "bot" to automatically add the attribute?
