Minutes: MathML Core meeting Feb 17, 2020

Attendees:

   -

   Bruce Miller
   -

   David Carisle
   -

   Neil Soiffer
   -

   Murray Sargent
   -

   Patrick Ion



Agenda:
https://github.com/mathml-refresh/mathml/issues/8#issuecomment-586808006



The meeting was recorded:
https://benetech.zoom.us/rec/share/4u8rMpD8xkZLULf0xm3PeY15OI6-aaa823Uer_sNxR7NluV-S7DXabQ0aOntrYFl


Operator dictionary update: #87
<https://github.com/mathml-refresh/mathml/issues/87>

DC: Updated  html view of operator dictionary:
https://mathml-refresh.github.io/xml-entities/opdict.html

NS: feedback on eliminating ellipsis from op dict? Mentioned in
https://github.com/mathml-refresh/mathml/issues/87#issuecomment-586773801

DC: I’m happy with that.

PI: You can think of it as an operator that fills in the gap. But that’s
strange.

BM: Ellipses are anything that is left out, it can be anything. It can be
numbers, matrices, or even operators.

DC: but it has no special spacing or other special properties, so being an
mo doesn’t help.

Resolved: let’s remove it.

MS: In OfficeMath, the baseline and center ellipses are treated as
operators with ordinary character spacing. It’s useful to know that they
are used in math typography and that they should be rendered with a math
font. Also if a baseline ellipsis (2026) follows a + or -, it’s displayed
as a center ellipsis. When exported to MathML, <mo> is used.

NS: Two more to consider:  HEAVY DIVISION SIGN' (U+2797) -- ➗ (vs regular
÷).
Also long division symbol (U+27CC): ⟌

MS: I’m thinking of using ⟌ for linear notation (UnicodeMath)

MS: Can’t use it for typography

DC: The attributes associated wouldn’t match ‘/’. Nothing really sensible
associated with it for properties.

DC: The previous two Unicode symbols, heavy plus/minus, would need to go in
if we put in heavy division

Resolved: skip long division

BM: I’ve never seen them used, but I can imagine someone using them if they
want a bold version of those signs

PI: I agree all three go in.

Resolved: put the three dingbats in

Try to resolve bevelled fractions: #29
<https://github.com/mathml-refresh/mathml/issues/29>

BM: I did some further experiments. Neil’s samples all seem like reasonable
candidates for experiments. If I run them through TeX or MathML they all
come out looking reasonable.

BM: Because the spec says raise and lower num/denom a bit, the browsers do
that, but nicefrac doesn’t. In nicefrac, the denom aligns with baseline of
surrounding text. That looked right to me.

BM: I then pushed the envelope a bit with some examples. Xfrac pushed the
numer down and Firefox shifts the n/d way too much. The more I looked at
nicefrac, the more I liked it’s approach.

NS: Can you post them to the issue?

BM: Ok.

NS: We need to update the spec to say something more about the layout.

NS: What about the idea of it being in core?

DC: I think it makes sense from a cleaner language design. It shouldn’t be
a burden to implement. It would be best to avoid using JS if possible.

NS: I agree about language design -- it makes it harder to know if you need
to use a polyfill.

PI: It has a long tradition in math notation layout.

BM: People most likely to use bevelled frac probably aren’t using much
MathML, so maybe the stats are not reliable.

NS: I was hoping to get Pearson stats since they might use it more, but
haven’t gotten anything. I’ll ping again.

NS: Can’t resolve without Fred being here.

Polyfills #188 <https://github.com/mathml-refresh/mathml/issues/188> -- any
more ideas?

NS: I don’t have any new thoughts myself, but we really should think this
through sooner rather than later.

DC: We have an in-house annotation that works in Firefox, but not in
MathJax because the DOM has been radically re-written. It’s why I’m not a
big fan of many polyfills. But not many people complain about MathJax which
radically changes the DOM. Most people just care about rendering.

DC: It muddies the water the more we rely on JS.

DC: Because of the interactive things we do, I want to rely on core to
avoid rewrites, so I need to make sure core contains enough for us.

PI: Does anyone have an example of polyfills for SVG or some other
technology?

NS: Used quite a lot for new features, and stick around for older browsers
like IE once they become common in modern browsers.

DC: Can’t really feature detect for MathML core feature, but could do that
for video. The concern is that it is hard to write a polyfill that would
change as core changes unless all implementations change at the same time.

DC: I would tend to use a polyfill to convert my document before putting it
on the web.

DC: It’s easy to change mfenced to mrow, but what does the schema say? Is
mfenced in the validator or not? I.e., is core really MathML or full what
MathML really is?

DC: My feeling is that if it isn’t in core, then it isn’t valid. Hence, I
want core to be usable, not to be missing vital features that require JS.


Meeting next week.