Minutes: MathML Core meeting: 8 July

Thanks to Brian for the vast majority of minuting. Charles is away, so no
recording link this week.

Attendees


   -

   Brian Kardell
   -

   Frédéric Wang
   -

   David Carlisle
   -

   Neil Soiffer
   -

   Rob Buis
   -

   Murray Sargent


---

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

Item: Brian update on DOM/IDL/Shadow dom?

BK: open issue about renaming IDL name that involves SVG name to include
MathML. Looking for implementor interest. BK is trying to get some people
to state their interest preference.

BK: can Fred to a pull

FW: maybe we can do it -- need to ask

NS: shadow DOM?

BK: nothing to share yet
Item: Fallback values for math constants: #69
<https://github.com/mathml-refresh/mathml/issues/69> <-- Updates from Neil,
Murray and Dani? Rob found a function to get text bounding box?

NS: I'm still working on my fallback document, nothing new to report.  I
guess Rob found some information that might help?
RB: I'm not entirely sure why that is on the agenda
FW: Mostly informative so that you can use it in your fallback document

NS: Is this specific to the chrome implementation?

FW: It seems possible to get this information in all of the browsers

(no resolutions)
Item: MathML Core / MathML 4 status <-- Updates from Fred and David? #108
<https://github.com/mathml-refresh/mathml/issues/108> #17
<https://github.com/mathml-refresh/mathml/issues/17>

FW: I've been rewriting the core specification using respec which allows us
to provide metadata - so we have linked tests and things.  I've been
working through issues from Ian Kilpatrick from Google requiring that we
specify a lot of things about layout and CSS display modes, so there are a
lot of updates.  I think I have replied to most of the issues, the only
significant thing left is stretchy operators. I'm not sure there isn't more
to do.

NS: So if Google is asking questions, does that mean they are also
responding and watching?

FW/BK:  It was reviewed early, lots of questions listed for us to answer in
our work.  They aren't watching day to day but if we request review or let
them know we have a critical enough mass for them to review, they'll look
again.  We are working with them though, yes.

FW: I'd like to get some more on stretchy operators before we say it's
ready for review

DC: I also started moving things to respec, in a fork in my github. I think
this is generally pretty good because there are sort of dwindling number of
people who could take it up in my absence or something.  It's a little
quirky, but I think it's generally good? It seems better to make a decision
now rather than later and bring them inline with one another. I think we
need to decide how we do examples and whether they are or also run inline
to show how it works in your browser.

NS: Let's add an agenda+ for the full group

RB: I really like the integration linking tests to the spec section. I've
seen some other things in other specs having the integration status - can
we do that? I think CSS specs do this.

FW: Those use another spec format I think…

BK: Bikeshed

FW: Yes, so I suppose it is very easy in that tool… It seems easy enough to
in respec too, but I don't think it is supported out of the box. I
mentioned it in an issue
<https://build-chromium.igalia.com/mathml/wpt/summary.htm>

NS: That seems different, like it means the spec changes any time some
implementation changes/runs the tests.

DC: We could always change it in non-editors drafts

BK: (goes on with a long number of words that basically amount to 'it is
useful because this is one of the primary questions most people have when
they turn to a spec, it helps them make sense of the status of things')

FW: This is useful to anyone reviewing - implementers, W3C TAG, etc.  These
are primary sorts of questions.

NS: Can we update the pointer in the core spec that points to the test
suite?

FW: Yes

Action item: Fred to fix link and/or destination

Item: Margin/border/padding #14
<https://github.com/mathml-refresh/mathml/issues/14>

FW: Now that we have specs, we are using the CSS box model.  We have an
issue that we ignore margin, border, padding and describes the layout of
the content.  The question is do we want to take into account borders,
padding and margin?

NS: You mean if someone specifies a border, that would affect the layout?

FW: The spec describes the layout of the fraction, but not the borders and
so on.  If you take the example of radicals, we describe that you use extra
space - my proposal is that this refers to the stuff inside.

BK: What’s the relation between content box and math content box?

FW: Content box is what is defined in core spec. The context box is text,
but could be linebroken, so content isn’t just text.

BK: Important that we define these things

FW: Currently, they are all the same. Proposal is to make
margin/border/padding to work as they do elsewhere.

BK: that sounds like a good idea

RB: will people actually use them

FW: dunno but my use cases: spacing of fraction, merror frame, menclose
notations

BK: people will find it surprising if they don’t work like everything else.
The CSS group would be the most surprised.

Resolved:  Should be supported.

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