Re: Minutes: MathML Core meeting Feb 17, 2020

Late apologies for missing this, Monday was my birthday and presidents day
and I was just getting over a bad cold at the doctor's recommendation so it
seemed like a good day to just take the day off and not pay attention to
tech stuff at all :)



On Tue, Feb 18, 2020 at 2:09 PM Neil Soiffer <soiffer@alum.mit.edu> wrote:

>
> 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.
>
>

-- 
Brian Kardell :: @briankardell :: bkardell.com