Remove/Deprecate numalign/denomalign/align attributes

[fred-wang]

These are used for horizontal alignments:

• numalign, denomalign for mfrac
• align attributes for munderover/munder/mover

I'm opening the discussion about whether we really want to keep these attributes. I think in practice most people use the default alignment.

[davidcarlisle]

for fractions at least the main use of alignment is continued fractions see section 4.12

http://anorien.csc.warwick.ac.uk/mirrors/CTAN/macros/latex/required/amsmath/amsldoc.pdf

where amsmath supports \cfrac (left alignment) and \cfrac[r] (right)

As far as possible we should be able to support amsmath which is the base level support for math typesetting in LaTeX.

[dani31415]

We can remove it but implement the CSS style text-align. We will have the same effect.

[fred-wang]

We can remove it but implement the CSS style text-align. We will have the same effect.

Quick comment on this:
(1) As others stated elsewhere, people who implement MathML in a non-browser context might want to keep it.
(2) As I commented in a previous meeting, if we decide to support text-align (which makes sense and avoids to introduce new properties) we will need to extend its definition for math layout. Currently, the CSS spec says "how the inline-level content of a block is aligned along the inline axis if the content does not completely fill the line box" ( https://drafts.csswg.org/css-text-3/#text-align-property ). Note that we still haven't defined precisely the CSS display values of MathML elements ( #56 ).

[fred-wang]

for fractions at least the main use of alignment is continued fractions see section 4.12

http://anorien.csc.warwick.ac.uk/mirrors/CTAN/macros/latex/required/amsmath/amsldoc.pdf

where amsmath supports \cfrac (left alignment) and \cfrac[r] (right)

As far as possible we should be able to support amsmath which is the base level support for math typesetting in LaTeX.

Thanks. it seems this is only for numalign though. Do we have use cases for denomalign and align? (maybe non-LaTeX use case)

In general per #55 we should figure out how MathML converters handle things like

\cfrac{1}{234}
\cfrac[r]{1}{234}
\cfrac[l]{1}{234}

( TeXZilla/itex2MML don't support that command https://golem.ph.utexas.edu/~distler/blog/itex2MMLcommands.html https://github.com/fred-wang/TeXZilla/blob/master/base-commands.txt )

[fred-wang]

Here is the summary of the options:

(I) Remove numalign/denomalign attributes.

(II) Keep numalign/denomalign attributes for MathML but not expose them at all to CSS (Firefox and WebKit's implementation). I guess this would be fine for the short term but I suspect people would like to rely on CSS in the future.

(III) Implement numalign/denomalign using CSS properties. Two options:

(A) It could be something like

mfrac[numalign="left"] > *:first-child {
ALIGNMENT-PROPERTY: left;
}
mfrac[denomalign="left"] > *:last-child {
ALIGNMENT-PROPERTY: left;
}
...

which implies introducing universal selectors for UA agent stylesheet, something we want to avoid as Chromium implementers (otherwise they need to be "expanded" with all the possible MathML element names). I don't know if we can implement such a mapping in the MathML C++ code.

ALIGNMENT-PROPERTY can just be text-align, but that will require introducing a new CSS display for and that we override the definition of text-align, two things that need the approval of the CSS WG.

(B) Or introducing independent properties like

mfrac[numalign="left"] {
NUMALIGN-PROPERTY: left;
}
mfrac[denomalign="left"] {
DENOMALIGN-PROPERTY: left;
}

which actually can also be directly implemented in the C++ code. The disadvantage is that we would need to introduce two independent CSS properties and get approval from the CSS WG. In general, we want to avoid introducing too many CSS properties if they are not justified.

(IV) Same as (III)(A) but remove the MathML attributes (i.e. what Dani said) and move them to CSS polyfills. However, maybe some people will complain that we still need to support non-CSS environment.

(V) Currently, only a use case for numalign was provided by @davidcarlisle. So another alternative is to do something like (III)(B) but remove denomalign. The cons is that users will likely complain of not keeping the symmetry.

[davidcarlisle]

There is a use case for this but I agree we want to "ration" the number of css-extension requests we make.

Definitely they should be in full mathml. If it was easy (or possible) for a document author to get the effect with css than I'd even say drop from core (at least initially, revisit if there is end user demand) but if I understand you correctly that there isn't currently anything that even an in-document stylesheet can do unless css is extended.

so perhaps I'd go for this if CSS WG are happy with that

(IV) Same as (III)(A) but remove the MathML attributes (i.e. what Dani said) and move them to CSS
polyfills. However, maybe some people will complain that we still need to support non-CSS environment.

I think non CSS environments will most likely need to define their own subsets of full that are compatible with, but not necessarily the same as, mathml core, and so they could allow "native" handling of these attributes if needed.

[NSoiffer]

Chiming in a little late on uses cases, but this Wikipedia page on inference rules uses left alignment for the premise and conclusion. I've seen several others that center them. Logic is not something I took, so I don't know what is really the correct notation (maybe both?).

[NSoiffer]

Just an FYI...

I'm a bit surprised, but neither the arXiv stats nor the NAG stats have any usage of numalign or denomalign. So despite potential usage for continued fractions and logical inference rules, they don't seem to be getting much use.

[NSoiffer]

I don't see how this very rarely usage feature of MathML is worth spending any "capital" with the CSS WG (i.e., let's keep our requests for those things that are critical). I very much agree they should remain in full and a polyfill created that uses text-align as per @dani31415's suggestion. So, I agree with @davidcarlisle that we go with @fred-wang's IV:

(IV) Same as (III)(A) but remove the MathML attributes (i.e. what Dani said) and move them to CSS
polyfills.

@fred-wang wrote earlier:

...if we decide to support text-align (which makes sense and avoids to introduce new properties) we will need to extend its definition for math layout. Currently, the CSS spec says "how the inline-level content of a block is aligned along the inline axis if the content does not completely fill the line box" (https://drafts.csswg.org/css-text-3/#text-align-property). Note that we still haven't defined precisely the CSS display values of MathML elements ( #56 ).

Sorry for being dense, but why is an extension needed for math layout? Don't we want exactly the same thing to happen for numerators/denominators of fractions as happens when textalign is left/right/center?

[fred-wang]

Chiming in a little late on uses cases, but this Wikipedia page on inference rules uses left alignment for the premise and conclusion. I've seen several others that center them. Logic is not something I took, so I don't know what is really the correct notation (maybe both?).

mfrac is for fractions or fractions-like argument per https://mathml-refresh.github.io/mathml/chapter3.html#presm.mfrac but here it describes inference rules so it does not seem appropriate to use a fraction. Actually, the HTML/MathML on this page is not very good: it's two separate formulas one of the top of the other and the top one has an munder with a stretchy underline. Also, I don't think the alignment is important for the semantic, it's probably a author hack to ensure that the top and bottom SVG image have the same width and hence align correctly.

I believe this use case is similar to commutative diagrams, where the expected rendering could be emulated with mtable but what we really want is MathML formulas inside an SVG image. I would be good to check how this is implemented in LaTeXML, maybe there are some arXiV articles.

[fred-wang]

...if we decide to support text-align (which makes sense and avoids to introduce new properties) we will need to extend its definition for math layout. Currently, the CSS spec says "how the inline-level content of a block is aligned along the inline axis if the content does not completely fill the line box" (https://drafts.csswg.org/css-text-3/#text-align-property). Note that we still haven't defined precisely the CSS display values of MathML elements ( #56 ).

Sorry for being dense, but why is an extension needed for math layout? Don't we want exactly the same thing to happen for numerators/denominators of fractions as happens when textalign is left/right/center?

We want the same rendering but it's difficult to see if the CSS concepts involved in the definition of text-align would just work here until we clarify all the CSS display, size etc for MathML elements. So I would not bother the CSS WG until we are sure of what we want and have a solid proposal.

For example I don't think we can use text-align to emulate numalign/denomalign in this case (which is close to current Chromium and WebKit implementations CSS-wise).

<style>
  .mfrac { width: 100px; height: 20px; background: red; }
  .mspace1 { width: 50px; height: 10px; background: blue; }
  .mspace1 { width: 100px; height: 10px; background: green; }
</style>
<div class="mfrac">
  <div class="mspace1"></div>
  <div class="mspace2"></div>
</div>
<div class="mfrac">
  <div class="mspace2"></div>
  <div class="mspace1"></div>
</div>

[NSoiffer]

Inference notation uses a fraction-like notation and hence is an appropriate use of mfrac. mfrac hints at a semantics, but doesn't specify it. The math on the web CG came up with a page that deals with ambiguous notations, with a long section devoted to fraction-like notations, only one of which is semantically a fraction. The logic notation is part of that (although in they point off to one that centers it). Dealing with these other uses is something I hope the non-core group figures out with respect to accessibility.

[fred-wang]

For me all but 2-Dimensional vector notation and logical deduction are fraction-like in the sense of binary functions with some kind of multiplicative property. I'm not sure what's the 2-Dimensional vector notation, but for me it's a matrix so it should rely on mtable. And the logical deduction is more a diagram to me (you basically put several deduction on the same schema to produce sequence of deduction). Anyway, all of this is subjective and MathML 3 is not clear at all, so people could use whatever they want to emulate a visual rendering of the formula. But again, it's not clear whether the alignment is important at all for logical deduction.

[NSoiffer]

For example I don't think we can use text-align to emulate numalign/denomalign in this case (which is close to current Chromium and WebKit implementations CSS-wise).
[css/html example]

The example you use doesn't seem like the right model. For a fraction, the numerator and denominator are each lines that want to be aligned, so I think it is more like a span inside of a div, which does align properly. Something like

<style>
  .mfrac   { width: 8em; height: 4ex; background: red;}
  .cline   { width: 8em; height: 2ex; background: lightyellow; text-align: center;}
  .lline   { width: 8em; height: 2ex; background: lightyellow; text-align: left;}
  .num { width: 4em; height: 2ex; background: lightblue;}
  .denom { width: 8em; height: 2ex; background: lightgreen;}
</style>

<div class="mfrac">
  <div class="cline"> <span class="num">num</span> </div>
  <div class="lline"> <span class="denom">denom</span> </div>
</div>

which displays as

[fred-wang]

The example you use doesn't seem like the right model.

Note sure what you mean by the right model, as I said MathML CSS display is undefined right now and in the WebKit/Chromium implementations all elements are essentially block so that's closer to the example I gave. I was just trying to illustrate that you cannot just say "let's use text-align" without being careful about the CSS details. Of course for the numalign/denomalign implementation we can interpret text-align as we want (Rob did that for Chromium) but that does not necessary match what the CSS spec currently says. Hence we would need to modify/extend that definition, which was your initial question.

[fred-wang]

@rwlbuis: I was thinking about this again and we have an additional problem: text-align is inherited. So it's not possible to just map alignment attributes to text-align as that won't work for nested expressions like

<math>
  <mfrac numalign="right">
    <mfrac> <!-- should be right aligned -->
      <mspace width="33px" height="10px" style="background: red"/> <!-- should be centered -->
      <mspace width="66px" height="10px" style="background: green"/>
    </mfrac>
    <mspace width="99px" height="10px" style="background: blue"/>
  </mfrac>
</math>

If page authors want to implement alignment using text-align, they would have to be aware of the inheritance and reset the value in descendants if necessary. This plus the fact that CSS defines text-align for alignment of inline-level content right now make me unsure whether it's a good idea to rely on it for MathML box alignment...

BTW, I think I already mentioned this in a previous meeting but I don't like that alignment attributes are not "logicalized". Values should really have been start/center/end.

[fred-wang]

My proposal:

(1) For now: Remove numalign/denomalign/align from MathML Core.
(2) In the future: If we really have strong use cases to justify the need of alignment in fraction/munderover, we can later propose new non-inherited CSS properties for them. They could be used to implement/polyfill these attributes (using straightforward mapping), we can decide whether they should be in core == implemented natively.

[rwlbuis]

@rwlbuis: I was thinking about this again and we have an additional problem: text-align is inherited. So it's not possible to just map alignment attributes to text-align as that won't work for nested expressions like

<math>
  <mfrac numalign="right">
    <mfrac> <!-- should be right aligned -->
      <mspace width="33px" height="10px" style="background: red"/> <!-- should be centered -->
      <mspace width="66px" height="10px" style="background: green"/>
    </mfrac>
    <mspace width="99px" height="10px" style="background: blue"/>
  </mfrac>
</math>

Good find. I think margin-left: auto/margin-right:auto can act as a replacement that is not inheritable, but right now our chromium implementation does not take margins into account.

If page authors want to implement alignment using text-align, they would have to be aware of the inheritance and reset the value in descendants if necessary. This plus the fact that CSS defines text-align for alignment of inline-level content right now make me unsure whether it's a good idea to rely on it for MathML box alignment...

Yes resetting would be cumbersome and easy to forget.

BTW, I think I already mentioned this in a previous meeting but I don't like that alignment attributes are not "logicalized". Values should really have been start/center/end.

Same here.

[NSoiffer]

BTW, I think I already mentioned this in a previous meeting but I don't

like that alignment attributes are not "logicalized". Values should really have been start/center/end. Not sure what you mean about "logicalized". DId you mean didn't take into account that different languages/locales use different text writing directions? If so, the MathML committee recognized that when support for right-to-left was added to MathML, but at that point, it made too late to change the names. Doing so, would have broken lots of things. Lots of the web uses "left" and "right" with accommodations/changes when the text direction isn't left to right, so MathML is not alone in having that problem. Or did you mean some different?

…

On Fri, Apr 26, 2019 at 12:16 AM Rob Buis ***@***.***> wrote: @rwlbuis <https://github.com/rwlbuis>: I was thinking about this again and we have an additional problem: text-align is inherited. So it's not possible to just map alignment attributes to text-align as that won't work for nested expressions like <math> <mfrac numalign="right"> <mfrac> <!-- should be right aligned --> <mspace width="33px" height="10px" style="background: red"/> <!-- should be centered --> <mspace width="66px" height="10px" style="background: green"/> </mfrac> <mspace width="99px" height="10px" style="background: blue"/> </mfrac> </math> Good find. I think margin-left: auto/margin-right:auto can act as a replacement that is not inheritable, but right now our chromium implementation does not take margins into account. If page authors want to implement alignment using text-align, they would have to be aware of the inheritance and reset the value in descendants if necessary. This plus the fact that CSS defines text-align for alignment of inline-level content right now make me unsure whether it's a good idea to rely on it for MathML box alignment... Yes resetting would be cumbersome and easy to forget. BTW, I think I already mentioned this in a previous meeting but I don't like that alignment attributes are not "logicalized". Values should really have been start/center/end. Same here. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#30 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALZM3HRTJKJLIZGA7RVJWDPSKT5XANCNFSM4GZFHWRA> .

[fred-wang]

Yes, this. I get that we want to keep backward compa, but in other specs they at least introduce "start" and "end" values.

[NSoiffer]

Agreed in 29/4/19 meeting:
Remove from core (mfrac, munder, mover, munderover alignment attrs)
Leave in full

Move discussion of polyfill implementation to a separate issue

[davidcarlisle]

On Mon, 29 Apr 2019 at 18:24, Frédéric Wang ***@***.***> wrote: Yes, this. I get that we want to keep backward compat, but in other specs they at least introduce "start" and "end" values.

If I understand the model of when css introduces start, it is in values like text-align:start instead of left or right but property names like margin-left:1em are always referring to the physical layout and so left means left even in rtl pages. If so we could I think add start and end anywhere that it makes sense without affecting compatibility with existing use. (we should probably open a new issue on that)

[fred-wang]

Note that you also have margin-inline-start, margin-end-start, margin-inline-end and margin-inline-end properties depending on CSS orientation and direction values. But yes in general other specs have solved this by introduce extensions with start/end and block/inline.

[fred-wang]

@rwlbuis I think you can update the WPT test for this

[fred-wang]

The CSS align modules has various properties:
https://www.w3.org/TR/css-align-3/#intro
(both alignment of children and with respect to parent)

We could define interpretation of these properties for mfrac/munder/munderover/munderover elements in order to keep the old behavior.

[fred-wang]

tests updated, so closing.

[NSoiffer]

Just to be clear upfront: I am not proposing adding numalign/denomalign back into core.

In a comment, @fred-wang wrote:

The CSS align modules has various properties: https://www.w3.org/TR/css-align-3/#intro (both alignment of children and with respect to parent)
We could define interpretation of these properties for mfrac/munder/munderover/munderover elements in order to keep the old behavior.

What is the plan for interpreting the CSS align properties? I'm guessing the answer is either "ignore them" or "they do whatever they do", but if they were implemented to support left and right alignment, then a polyfill could take advantage of them.

[fred-wang]

There is no short-term plan to define/test/implement CSS properties for https://www.w3.org/TR/css-align-3/ (see https://mathml-refresh.github.io/mathml-core/#css-styling for ignored properties). FWIW, the old tests from Firefox use mspace to force alignment ; until the CSS layout API is available you could add mspaces of width mfrac.width - num/denum.width on the proper side of the num/denum

[NSoiffer]

Yes, measuring seems to be the only solution. The downside of that is that one can't transform the MathML into core on the server (or earlier).

Reopening because we still need a polyfill.

[NSoiffer]

I've written a polyfill for this: https://github.com/mathml-refresh/mathml-polyfills/tree/master/horiz-align

[davidcarlisle]

will be kept in full and not in core, so closing here.