# Description

Generally speaking, it's a lot better to be able to see a full expression than to have it all on the same line, so we probably want to add some sort of wrapping support to the rendered latex output.

# Related Objects

### Event Timeline

Isarra created this task.Aug 4 2018, 1:11 PM
Restricted Application added a subscriber: Aklapper. Aug 4 2018, 1:11 PM

Yes, definitely. This would also solve part of T194768. With JS and Mathjax you can get this functionality easily, however in Wikipedia it seems to be a huge problem because most people get to see the math as images rather than text. We are trying to come up with a solution and would need some input from developers, see T195861.

pmiazga moved this task from Needs triage to Triaged on the Mobile board.
Pkra added a subscriber: Pkra.Aug 7 2018, 6:27 AM

Generally speaking, it's a lot better to be able to see a full expression than to have it all on the same line

That does not match my experience.

From a technical point of view, line-breaking equational content is a difficult problem and traditional approaches focus on print layout, often causing problems on the web (e.g., tolerating partial overflow). At MathJax we did quite a bit of research into alternative ideas and implemented a collapsing/expanding feature (which you can test on any MathJax enabled site). But that's a hard UX change and this space has not been explored much.

From a content point of view, breaking large pieces equational content can very quickly cause confusion as the content suddenly spreads across multiple (vertical/other-direction) viewports. Some of the examples at https://en.wikipedia.org/wiki/User:Salix_alba/maths2018 might be useful to think about.

For example, large expressions often have table(-like) structures which cannot be line-broken at all; similarly, manual linebreaks cause confusion when adding automatic ones.

It's not that it can't be done (even server-side) but it is usually better handled on the authoring level, i.e., if equational content requires linebreaks, then perhaps it would benefit from improving it.

TheDJ added a subscriber: TheDJ.Aug 7 2018, 8:50 AM

I sort of agree with @Pkra. There is this myth that all content should be scalable to a mobile viewport. But that is just insane when you deal with things like huge tables, graphs and indeed formulas. Especially data tables are impossible to make responsive without taking an per table approach, which will never be done for more than the 10% of most popular stuff (and specifically for tables I haven't seen a responsive technique which doesn't destroy the semantics of the table structure in the process and can deal with row/colspans etc, which creates an accessibility concern). And then you still need fallbacks for all the other cases that no one bothered with.

Instead things should be made zoomable, scrollable etc. Just like an image gallery, a map etc. Dedicated interaction UI per type of content (aka per extension / per skin). In this case, i'd love for it to detect that it is overflowing, to indicate to the user that it is overflowing, to make it clickable to turn it modal, and then to have a scrollable and zoomable surface to inspect the element. I've proposed this a couple of times now, but it seems to be too minor a problem to get it prioritised.

BTW. The minerva skin makes the math images scrollable when overflowing. (but it doesn't have indicators for when content is overflowing, making it hard to predict what elements you should scroll. This is one of my biggest annoyances with minerva actually)

@alexhollender - any thoughts on the suggestions here? In particular, I think adding an indicator as @TheDJ suggested could be a good way to do this

Pkra added a comment.Aug 7 2018, 9:43 AM

They are scrollable right now, I think. (Though mobile browser UIs tend to hide scrollbars.)

In this case, i'd love for it to detect that it is overflowing, to indicate to the user that it is overflowing, to make it clickable to turn it modal, and then to have a scrollable and zoomable surface to inspect the element.

👍 It's not easy to do this well, e.g., accessibly.

I think one has to differentiate: Of course there are large formulas which cannot be broken and need some scrolling mechanism. Most formulas however have a structure like $A=B+C+D$ which you can break almost everywhere if necessary. Wikipedia authors currently have a choice between

• Adding permanent linebreaks or splitting the expression up in smaller chunks which means making it less readable by wasting space on large screens and/or introducing unnecessary artificial names for parts of the sum
• Not adding any linebreaks, making the expression unreadable on small screens or introducing unnecessary scrolling or zooming.
First sentence
:$A$$\;=B$$\;+C${{nowrap|$\;+D$.}}
Next sentence.

to force a correct linebreaking behaviour and an equal looking punctuation mark.

I don't really like the last "solution" which unfortunately gets more and more popular among Wikipedia editors. Why should the LaTeX way, where you can modify the line breaking penalties with dedicated macros if necessary be unsuitable for Wikipedia?

So basically we just need a cleaner way for editors to define potential breakpoints - which LaTeX normally provides anyway?

Pkra added a comment.Aug 8 2018, 5:33 AM

Most formulas however have a structure like $A=B+C+D$ which you can break almost everywhere if necessary.

The example nicely shows that one could but should not break everywhere (e.g., most people don't like a line to start with = or +).

In any case, it's feasible to automatically generate rendering into several blocks that then relow individually (generally speaking using MathJax, not with the Math Extension as is).

Having done research in this area, I'd just caution that this kind of reflow can be worse than consistently moving a longer inline expressions to the next line is.

Isarra added a comment.Aug 8 2018, 5:41 PM

It sounds like there are some common symbols/whatever that probably would make for safe assumed breakpoints, though - maybe look into if this is truly the case, for some general default handling for which those blocks should be?

ovasileva triaged this task as Normal priority.Aug 9 2018, 7:13 PM
Pkra added a comment.Dec 7 2018, 2:33 PM