# make $tags without argument to be inline mathOpen, Needs TriagePublicActions Assigned To None Authored By  Physikerwelt Nov 28 2020, 7:10 PM2020-11-28 19:10:20 (UTC+0) Referenced Files None # Description Currently, the logic for math tag attribute display is the following. • Not set -> mathoid rendering mode 'tex' , tex -> '{\displaystyle ' . tex . '}' , span-element • block -> mathoid rendering mode 'tex', tex -> '{\displaystyle ' . tex . '}'; , div-element • inline -> mathoid rendering mode 'inline-tex', tex -> '{\textstyle ' . tex . '}' , span-element • linebreak only supported in LaTeXML rendering mode tex -> '$' . tex . '$';, div element See https://www.mediawiki.org/wiki/Extension:Math/Displaystyle for documentation, examples, and discussions. In https://phabricator.wikimedia.org/T111712#6653762 it was proposed: make [itex] tags without argument to be inline math. Anything that needs more letters to type or is more complicated will never be accepted. ... Currently, the default is more like block, and also mathjax3 defaults to block http://docs.mathjax.org/en/latest/web/typeset.html?highlight=mode%20display#conversion-options I @Physikerwelt would like to simplify the rendering pipeline and make it more standard. Therefore, I would like to extend the proposal and stop the modification of the tex code, based on the display attribute. Thus MathJax (or any other renderer that will be used in the future +5years) needs to deal with the tex code as it was entered and the display attribute will only be passed as a parameter. However, I am afraid that changing the default, will cause a lot of broken pages. If we default to block and also use div elements to make formulae real blocks, it will break all the inline occurrences of formulae. This is so bad, that the articles will become infeasible to read. Thus this is not an option departed here. The alternative, which was proposed, will however cause that formulae typed with :<math will have small operators, this is also a regression, but I think it is OK if we have a mechanism (i.e., bot) to convert :<math to -><math display=block. Alternatives: • do nothing • add new tags as aliases for <math display=X, e.g, <mathblock>, or <dmath>, or <m2> We need a community vote on that. ### Event Timeline I see the problem a math tag without a display attribute really needs a context-sensitive rendering. If its :<maths> then you would like a \displaystyle rendering. But if the tag occurs in the middle of a sentence you would want it to be \textstyle. I guess this is another unfortunate consequence of the :[itex] hack. It might be an idea to gauge just how big a problem it is. I think my scraping scripts does record the full tag and any colons before it. Ozob added a comment. I'm sympathetic to the idea of simplifying the rendering code. Any change should, at the least, not make it harder for editors to write formulas in wikitext. I think that's a strong argument for using [itex] to mean <math display="inline"> and <mathblock> (or <dmath>, or <mathdisplay>, or something agreeable) to mean <math display="block">. An alternative would be to introduce templates (with short names) that expand to <math display="inline">, <math display="block">, and$.

We could run a bot right now to convert :$to <math displaystyle="block">. Regardless of what is ultimately decided about the behavior of [itex], that would make future work easier. @Ozob do you see any disadvantages in using templates rather than tags? The advantage I see with the template is that it can be adjusted to the needs of individual wikis. The downside is that we would need to introduce a way for VisualEditor to understand it. Do you know if there is a widely used way to create a keyboard shortcut (optimally $$and $) that expand before the page is being saved? To my impression this is what everyone wants: I suppose it's too much to ask that we get \[ ...$ as a wiki-shortcut for block math? Yes. I wonder if we can't get quite close, with what is available to editors today. I personally am using wiked https://en.wikipedia.org/wiki/User:Cacycle/wikEd_customization#Keyboard_shortcuts that allows for custom keyboard shortcuts. Moreover, in addition to the display attribute, there are the attributes, id, qid and maybe others, in the future, e.g., to specify predefined macro shortcuts or enable new features like amscd or tikz. Thus maybe it is a good idea to make editors aware that what is inside the [itex] tag can never access anything that is not within the math tags except for the attributes passed to it. A downside of templates is the number of keystrokes to enter them. No template-based solution is ever going to be as short as \( and $. Another downside is that the template would essentially duplicate the functionality of [itex]. If [itex] ever changed, all the templates would have to change. Also, there would be pointless edit wars between the tag and the template. If there are two equivalent ways of doing something, then human nature says that one way is right, the other way is dumb, and which one you pick is really important. The main advantages to templates are that they don't require any changes to MediaWiki itself, and they don't introduce backwards compatibility problems. If everybody agreed that {{\(}} and {{$$}} were acceptable syntax, then we could create those templates and start using them right away. (Unfortunately, {{\[}} and {{$}} contain unsupported characters.) I like the idea of using keyboard shortcuts. But one of the disadvantages of [itex] is that it's more cluttered than $$and$$. Maybe it would be better to put an optional filter between the raw wikitext and what the user works with? If off, [itex] tags would be left as-is. If on, then when the editor loads the page, it converts [itex] ...$ and <math display="inline"> ... [/itex] to $$...$$ and converts <math display="block"> ... [/itex] to $...$; when it saves the page, it does the reverse transformation (and aborts in case of mismatched tags).

I like the idea of using keyboard shortcuts. But one of the disadvantages of $is that it's more cluttered than $$and$$. Maybe it would be better to put an optional filter between the raw wikitext and what the user works with? If off, [itex] tags would be left as-is. If on, then when the editor loads the page, it converts [itex] ...$ and <math display="inline"> ... [/itex] to $$...$$ and converts <math display="block"> ... [/itex] to $...$; when it saves the page, it does the reverse transformation (and aborts in case of mismatched tags).

I like this idea a lot. I think, especially for inline math. See a basic example:

A function $$f:U\subset\mathbb{R}\to\mathbb{R}$$, defined on an open set $$U$$, is said to be differentiable at $$a\in U$$ if any of the following equivalent conditions is satisfied:

is easier to read for my eyes than the current version

A function $f:U\subset\mathbb{R}\to\mathbb{R}$, defined on an open set $U$, is said to be differentiable at $a\in U$ if any of the following equivalent conditions is satisfied:

To me, the block level tags are less important, as they don't disturb the flow of reading that much.

However, I have no clue if this can be realized using the current infrastructure.

The problem with $$and $is that they could conflict with other uses. Pages of regular expressions might provide a particular problem. Consider this legal and potentially useful sentence. "Regular Expressions: The character [ and ] select a group of alternative character so [0-9a-f] is hexadecimal digits, ( and ) define a capturing group. To use these characters without their special meaning use the escape sequences \[,$, \(,$$."

Indeed these sequences occur in https://en.wikipedia.org/wiki/Regular_expression

If we were defining wikitext from scratch I would be all for it. But we have a legacy system and we can't impose changes of the rest of the entire MediaWiki ecosystem.

What we could do is catch these sequences before a page is submitted, apply a substitution and submit the correct wikicode. It might be possible to do the reverse when the a page loads in an editor, spot the tags and replace them with the short cuts. This should be possible for the normal text editor (not VE) and it looks trivial if WikEd is used.

I agree that sometimes, it would be important not to do any interpretation. And there are certainly users who are more likely to want to type regular expressions than a formula. This is why I think an optional setting is a good idea. As long as it defaults to off, it's fully backwards compatible; at the same time it's there for those who want it. Probably the editor should also let you turn off the conversion to [itex] after you begin editing (in case you usually want $$to begin an equation but you happen to be editing an article about regular expressions). Or turn it back on, in case you mistakenly turned it off. And I guess it should detect whether the sequences $,$, \(, and$$ appear in the original wikitext, and if they do, override your default and turn off the conversion (so that you don't accidentally damage the article).

I feel like this task should be easy for someone proficient at web development, but sadly that's not me.