Minutes: MathML core meeting 30 March, 2020

Attendees:

   -

   David Carisle
   -

   Neil Soiffer
   -

   Brian Kardell
   -

   Bruce Miller
   -

   Frédéric Wang
   -

   Patrick Ion
   -

   Murray Sargent




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



The meeting was recorded:
https://benetech.zoom.us/rec/share/39JNE72g9U9Jbq-T1VDAerM9ArvZeaa8h3Aa-vQLzBpbQgvqrJ3iBw41RZBRfxor


cramped: #164 (comment)
<https://github.com/mathml-refresh/mathml/issues/164#issuecomment-598892217>

   -

   NS: You're not looking at the base, you're looking at the second
   argument and seeing if it has an accent property
   -

   FW: The accent is an embellished operator.  There are two possibilities,
   so you have to look at the core operator, I don't think there is anything
   in CSS today to do that.
   -

   NS: I think we can change the rules to say you just look at whether it
   is an operator only, I can't imagine a case - that allows you to solve all
   of the problems with it, I think?
   -

   FW: It's just that we would have to write the text, I'm not exactly sure
   how.  I guess we have to …
   -

   NS: Patrick, have you ever seen an accent be an embellished operator? In
   other words, the hat or the line…
   -

   PI: So this is the accent, in and of itself?  The quick answer is that
   nothing like that comes to mind, but it's not so difficult to imagine
   someone trying… The answer I think is no - you could probably devise some
   exotic usage, but I doubt that you couldn't replace it by using something
   else.
   -

   NS: I don’t think it would be a big change to the spec to just say it
   was based on operator, not embellished, and that makes it a lot simpler -
   only CSS
   -

   FW: I guess it's not hard but now we have some inconsistency.. Maybe
   users don't expect that?
   -

   BM: <some clarification about cramped?>
   -

   NS: This is not about that, that's different. Cramped is not a relevant
   consideration for the accent - the question is about whether we increment
   the script level, but the rules for cramped are different than the rules
   for accent/overscripts.
   -

   FW: I was wondering why we want to keep the accent attribute which
   allows people to override that behavior.  It seems it would be wrong -
   maybe sometimes it was needed and sometimes it is not. If we require people
   to change their code, which I think we are, we can just tell them to change
   the alternative and get rid of the attribute.
   -

   NS: I think that when we looked at the data, it seemed reasonable that
   accent should always be true and wouldn't impact any actual usage. People
   only set it to true it seems, in practice, so this would only break the
   other case and do something really special. So I think what we would be
   changing here is not actually breaking things in practice from the data we
   had - nobody was using it that way.
   -

   PI: There are commonplace examples where you would set it
   -

   FW: But there are two ways to do it, and I'm not sure we want to keep
   the two ways.  The thing is for sure we can't do this for sure with complex
   nested operators with CSS.
   -

   NS: Do we have the research/data here we can look at? Is this a thing
   that is actually in use.
   -

   NS: Let's pause this part of the conversation and stick to 164 which is
   about cramped
   -

   FW: Maybe we can just use what is in the spec right now.  Like for
   script level we have just selectors, we can do the same.
   -

   NS: The details are different though
   -

   FW: Right, but the idea is the same.  It depends on how we interpret
   accents again.
   -

   NS: They aren't cramped
   -

   FW: There's an issue in FF that they aren't really use how to interpret
   this TeX rule
   -

   NS: I see, this is why the question becomes "what do you mean by accent"?
   -

   FW: Yes, so I am suggesting that for now we can consider either elements
   mfrac/munderover/etc or this + accent on munderover. But not accent on mo
   -

   BM: In your GH issue there is a part that says defaults to false, I
   think you meant to say set to true?
   -

   FW: Yes, that is not right…
   -

   NS: ...Editing...Updated - does this look right?
   -

   BM: Yes, that looks right now.
   -

   NS: I just linked into the comments explaining how TeX does these
   computations. Rule 9 implies that cramped is not relevant here, Rule 12 is
   the other part.  TeX itself doesn't say what to do with the accent, but
   these do say set the base in cramped style and then attached the scripts.
   -

   FW: I think the base is different in concept than in MathML.
   -

   NS: The question is whether munderover etc is cramped?
   -

   FW: Yes, I think there is still ambiguity on when cramped is becoming
   true (or false?)
   -

   BM: He seems implicitly to be talking about underscripts
   -

   NS: I think what rule 12 is saying is that the base is cramped style and
   then if you have a superscript it will be positioned in a cramped style, in
   MathML I think that we'd….
   -

   FW: I think there is some comment in Firefox too.
   -

   NS: I think they misunderstood the TeX rules.
   -

   FW: Or they just made a different decision because they aren't exactly
   the same
   -

   NS: Right, but I think we can clarify and actually sort this out.
   -

   FW: I'm not sure I understand TeX logic on this.
   -

   DC: Think of a fraction - a fraction with an msup inside takes effect
   -

   BM: The key thing is to visualize that cramped takes effect when there
   is a superscript that is 'pushed on, from the top'.  The rules are trying
   to describe the cases where something is 'pushing down from above'.
   -

   NS: You're right.
   -

   BM: So it's simple to describe why it's there, it's complex to define
   why it is what it is, specifically.
   -

   FW: …
   -

   PI: What's wrong with adding Bruce's simple explanation somewhere?
   -

   DC: If you got half a point of extra vertical space, you could probably
   not go to bed with nightmares. We're describing some very very edge cases.
   The important thing is to have cramped under fractions and square roots and
   these cases.
   -

   BM: If MathML rendering in browsers is such that I even notice cramped,
   I will be so happy to begin with.
   -

   PI: There are some cases where it is really annoying if they don't line
   up.
   -

   DC: In different parts of the same formula.
   -

   FW: My proposal is to ignore the accent to that.
   -

   DC: Nobody is actually objecting to this I think, despite all of this in
   the last 30 minutes.
   -

   FW: Do we agree with the proposal ?
   -

   NS: I want to make sure we document why we did this.  It's true we are
   really down in the weeds, but it does change things and I want to have a
   good record of why we made this choice is all.
   -

   BK: I want to rewind -- we are talking about a new CSS property “cramped”
   -

   FW: yes
   -

   MS: Example of cramped in OfficeMath
   -
   -

   -

   NS: that does show the effect, although you have to look at it closely
   to see it.
   -

   BK: So couldn't we use calc and inheritance?
   -

   FW < clarifies aspects of the proposal that that's the wrong direction>
   -

   BK: Ah, so this would work if we had :has() basically
   -

   FW: Right
   -

   BK: <audible groan>
   -

   General agreement to skip this very edge (superscript in the base of a
   mover/munderover. [don’t think we ask about consensus]
   -

   [this is about cramped, not accents/accent property on mo, which we
   didn’t circle back to]


largeop ascent/descent when using a glyph assembly: #198
<https://github.com/mathml-refresh/mathml/issues/198>

   -

   NS: So, if there are other things in the mrow, they are going to
   determine the height and depth - so this is only if it is stretchy…
   -

   FW: No.  It's not that. It is when there are no other things in the
   mrow, so no computed ascent/descent and when you have to use a large op
   made out of pieces
   -

   NS: I don't think this actually happens
   -

   FW: It could, so we just need to explain what will happen
   -

   NS: I would have probably said just center it on the axis, but I don't
   have strong opinions.
   -

   DC: I think the same, do whatever is easy
   -

   MS: When you have large curly braces, office math can do a few things..
   -

   NS: This is the case where you have a large curly and there's nothing
   else around it to inform you what you should do
   -

   FW: it's not about the curly braces specifically, it's any operator…
   Imagine a Sigma. You don't have a large enough sigma glyph, but for some
   reason you have a way to build it with a glyph assembly
   -

   MS: Yeah, nobody does that… they're too ugly. Those people would be
   unconstrained by aesthetics
   -

   DC: integrals would be a better example. Maybe an integral alone with
   some inline text?
   -

   FW: Here it is not when you are using stretchy - I feel like MS you must
   handle this case… The proposal is simple.
   -

   NS: Does anyone object
   -

   MS: I think it probably differs from what OfficeMath does, I can comment
   with what that does on 198, but I think it's OK
   -

   BM: Would it be simple to set the height/depth equal proportional to the
   corresponding character's height and depth if it exists?
   -

   FW: I think it is what we are doing ultimately anyway, but harder.  If
   we agree nobody is doing it I don't want to make it harder for basically
   the same result
   -

   BM: <… something about inline math and a corner case>
   -

   FW: I suppose you could
   -

   NS: Ok, so MS is going to look at what OfficeMath does and comment on
   198, so I guess we will put off a resolution and hopefully we can close
   that one quickly next week.


<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Received on Monday, 30 March 2020 22:26:12 UTC