This is for MathML Core, but I guess the general MathML 4 spec will have to be reworded to take vertical mode into account too.

Quoting @bgeek:

I'm not sure what the best option here, and what use-cases there are, however here are three options.

1. Only horizontal-tb is supported.

2. Setting writing mode is valid on the top level  element, and everything down to the , /etc elements is internall consistent. (This is similar to how tables work, i.e. all boxes from table->td are internally consistent).

3. Setting writing-mode is valid on any element.

Use-cases should guide the decision here. From my weak understanding math is typically only displayed in HTB, however I'm not a domain expert.

(2) May simplify implementations.

Any tests which are created for MathML should test that feature in each writing mode.

So far, the only vertical real-world use case I found was Mongolian (see mozilla bug above). They use vertical-lr for text and math: https://bug1077525.bmoattachments.org/attachment.cgi?id=8733228

Speaking to people writing CJK text, the reply I get is that in practice they often use horizontal-tb fo text and so a fortiori the same is true for math. For example the Korea SAT exam: https://semosu.com/data/exam/379/ab001.gif

However, someone else commented on that the Mozilla bug that even if not used in practice, it should be possible to have vertical MathML. Additionally, the CSS spec ( https://drafts.csswg.org/css-writing-modes-4/#block-flow ) says writing mode should be taken into account for MathML if the UA supports it:

"The content of replaced elements do not rotate due to the writing mode: images and external content such as from <iframe>s, for example, remain upright, and the default object size of 300px×150px does not re-orient. However embedded replaced content involving text (such as MathML content or form elements) should match the replaced element’s writing mode and line orientation if the UA supports such a vertical writing mode for the replaced content. "

(BTW it seems MathML has been mentioned for a while, @kojiishi is the one who added that 9 years ago)

So I would discard option (1). It seems we should definitely support at least option (2) proposed by @bgeek

Regarding (3), I don't think there is any use case to mix vertical and horizontal writing mode in math, so I would prefer to forbid this as that can lead to weird edge cases and complicate things. Even the orthogonal flow section of the CSS spec acknowledges this is tricky aspect: https://drafts.csswg.org/css-writing-modes-4/#orthogonal-flows

From the above examples, it seems the CSS writing-mode property should be inherited on the <math> root by default but potentially overridable by authors (e.g. if they want to do horizontal math in vertical text).

I would leave the possibility for people to use a different writing-mode inside foreign markup (in token or annotation-xml elements). I think we could even allow changing the writing-mode on the MathML elements used as integration point, for example the following already works in Gecko, WebKit and Igalia's chromium-mathml:

<math>
  <mrow>
    <mtext style="writing-mode: vertical-rl">Fraction</mtext>
    <mrow>
      <mo>{</mo>
      <mfrac>
        <mfrac>
          <mn>123</mn>
          <mn>4</mn>
        </mfrac>
        <mfrac>
          <mn>5</mn>
          <mn>678</mn>
        </mfrac>
      </mfrac>
    </mrow>
  </mrow>
</math>

We still need to rewrite the section for mtext ( #139 ) to specify the bounding box calculation. However, I think for the (ink) line-ascent and line-descent when mtext is in an orthogonal writing mode, it makes sense to say that they are equal to half the inline size of the mtext ± AxisHeight so that middle of the text is aligned with the math axis (middle of the vertical brace, of the fraction bar etc).

For Japanese, a colleague of mine pointed out to http://blog.cas-ub.com/?p=1233

Apparently http://blog.cas-ub.com/wp-content/uploads/2012/03/5funMath1-u.png is an excerpt from a real book and shows we need to support both horizontal and vertical for the math root.

It seems we also have case mixing vertical / horizontal inside formulas like in http://blog.cas-ub.com/wp-content/uploads/2012/03/edonosusiki.png but they seem pretty simple and could be handled by just allowing writing-mode change on token elements as I previously proposed (or alternatively by just using text layout only).

The spec is now written to not be specific of writing mode. I think we need to:

• Decide how to force inherited writing mode to avoid orthogonal flow.
• Describe the situations when orthogonal flow happens. Essentially which baseline to use.

With the huge caveat that I know almost nothing about vertical writing and math, I want to caution about putting a lot of faith in examples people can find, even if they are in a published book. In English, it is not too hard to find examples of terrible math typesetting, even in published books. Sometimes, people/publishers take the easy route based on what their software supports.

In some of the examples, they seem self-conflicting. E.g., in http://blog.cas-ub.com/wp-content/uploads/2012/03/edonosusiki.png, ÷ is not rotated, but = is. Is ÷ not rotated because they didn't have a rotated ÷ or is that what is correct? There are other things that seem strange to me in that example: 15 is rotated in (4) but not in (3) and I think that's a rotated square root symbol in (4) but a regular one is used in (7). In http://blog.cas-ub.com/?p=1233, the math in the first block is always enclosed in a box, but shorter examples are horizontal and bigger ones rotated 90 degrees clockwise (in a td-rtl context, are they mirrored?).

I think we need someone who knows math in some of these Asian scripts to give us some help and tell us what is good typographic practice and what isn't. It could be that software support has been so bad for so long that an "anything goes" approach is accepted practice.

Not a math expert but as one of Asian typography experts:

1. I recommend to define the default orientation of the root math element; i.e., whether the math object appears in upright or sideways-rotated. This is what I meant in the CSS Writing Modes spec. I don't have strong opinion either way as both usages exist, and preferred way would vary by many factors. Sideways-rotated might be more common for long math expressions, but upright is consistent with all other HTML objects (img, object, svg, etc.) I mildly prefer upright for the consistency, see below for more.
2. It maybe nice to add a CSS property for authors to change the orientation of the root math element. It is even nicer if the property works for all HTML objects. For this property to be consistent, it'd be nice if math is upright by default, but it's technically possible to make math the only exception if the additional complexity is really needed.
3. I recommend not to support orienting parts differently from the root. It is possible to find such examples in real books, but the authoring cost is very high because, as you found, the best orientation varies by several factors, and that editors need to make a lot of decisions for every math expression. Often they don't look good no matter how it was typeset, editors need to make compromises. It was more common to typeset math in vertical flow 5 decades ago or more, but rarely seen these days, and I expect to see even less in future.

Given the latest comments, my proposal is

1. Make the root math element upright by default (this is consistent with what we did for direction, which is ltr by default ; Arabic math is sometimes RTL and sometimes LTR):

   math {
   writing-mode: horizontal-tb;
   }

2. Authors can just use CSS math { writing-mode: ... } to change the orientation to e.g. vertical-rl or vertical-lr.

3. Don't allow writing-mode changes for any MathML element, except the root <math>.
   As @bgeek mentioned in Define what writing-mode behaviour is desired. mathml#44, CSS already indicates some exceptions here:
   https://drafts.csswg.org/css-writing-modes-4/#propdef-writing-mode
   which are implemented in a style adjuster in Chromium:
   https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/resolver/style_adjuster.cc?l=396
   (WebKit and Stylo have the similar file)
   We could do the same for MathML.

Note that some MathML elements can contain foreign markup e.g.

<math style="writing-mode: horizontal-rl">
  <mtext><span style="writing-mode: vertical-lr">TEXT</span></mtext>
</math>

so it would still be possible to have orthogonal flow inside MathML. However, the layout of such element defer to other CSS box layout so we don't need to define that case.

The orientation of objects and flow are different things, and writing-mode is a property to specify the flow direction. I don't think it's a good idea for the internal of math object to support the full feature of the writing-mode property. There are a lot of tricks, such as supporting traditional Mongolian, and you would not want to think about how to support them within math expressions.

People here are defining the full layout algorithm, correct? Then the algorithm should ignore writing-mode, and you will need another property to specify the object orientation. CSS has text-orientation to specify the orientation of characters. What you might want is similar to it, but affects the orientation of objects.

@kojiishi: Thanks, as I commented on the other channel I'm leaning toward postponing this now until we have a clearer understanding. Relying on writing-mode is easier to get something working "for free" when working with LayoutNG / CSS layout API. However, it's true that relying on flow might be wrong. For example with tables:

data:text/html,<table style="writing-mode: vertical-lr"><tr><td>1</td></tr><tr><td>2</td></tr></table> VS <table style="writing-mode: vertical-rl"><tr><td>1</td></tr><tr><td>2</td></tr></table>

I'm not sure the layout of matrice rows in Mongolian math should follow the flow direction or just be the "rotated by 90°" rule. Similarly, if we ever implement linebreaking in Mongolian math (something like "if x > 0 and y < 0"), should we follow the flow direction or the "rotated by 90°" rule?

If at the end the right thing is to introduce a new CSS property and implement things without relying on existing LayoutNG / CSS layout API, I suspect it's going to be more spec/test/implementation work. So I'd prefer not to deal with it for now.

So to address the original request (interop concern), I would for now force horizontal-tb in MathML (as firefox currently does). And keep existing "Issue" label and tentative WPT tests for the vertical case, until things are clarified.

consensus from 2020/06/23: postpone to a future version

@davidcarlisle Can this be imported moved to the MathML Core repo?

Currently, Chromium forces horizontal-tb in the style adjuster, but that does not work well with logical properties ( see https://phabricator.services.mozilla.com/D48279 ), so let's add a universal rule.

@fred-wang moved