Open fred-wang opened 5 years ago
@fred-wang moved
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
(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 ( w3c/mathml-core#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:
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:
Given the latest comments, my proposal is
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; }
Authors can just use CSS math { writing-mode: ... }
to change the orientation to e.g. vertical-rl or vertical-lr.
Don't allow writing-mode changes for any MathML element, except the root <math>
.
As @bgeek mentioned in w3c/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.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1077525 and https://bugs.webkit.org/show_bug.cgi?id=48951
Original report: https://gitlab.com/mathml/MathMLinHTML5/issues/21