MathML Refresh Core Minutes meeting 15/7/19

The meeting was recorded and can be heard at:
https://benetech.zoom.us/recording/play/YtJNgaGJEIOmUJvReF9woKNbSo9nLUL2bkRZi0O0KtV08oPlnAHgorj_tBRQ9lQo


Attendees:
Brian Kardell
Frédéric Wang
David Farmer
Neil Soiffer
Rob Buis
Sam Dooley
Murray Sargent
Patrick Ion

---


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

Brian update on DOM/IDL/Shadow dom? #83
<https://github.com/mathml-refresh/mathml/issues/83> #118
<https://github.com/mathml-refresh/mathml/issues/118> BK: Talked to people
about unweirding the IDL.
NS: Someone suggested mixins. Unclear why. Is there some special things
that we wanted.
BK: No. Originally element was generic for XML. Can have subclasses. HTML
is a subclass. SVG lives in a different spec but needs a bunch in common
with HTML, so created a mixin. Lots of options.
BK:  need to get people to agree about tests and what they should result in
BK:  started to write some tests, but many failures. Not sure if they got
into WPT in current form.
BK:  nothing new about Shadow DOM. A few positive comments but not much
excitement.
BK: mainly want to get IDL right first. Right now a custom element is
better than MathML elements at the moment, so this needs to be improved.

FW: Added issue #118 about new attributes we need to add to specfallback
values for math constants: #69
<https://github.com/mathml-refresh/mathml/issues/69> <-- Updates from Neil,
Murray and Dani?NS: no progress on adding to
https://mathml-refresh.github.io/math-constants.html

FW: RB had some questions about radical drawing. Need to define how to get
rule thickness.

MS: might be useful for testing to have default values

NS: the values depend on the font, so the defaults need to be calculated or
come from the font.

FW: rule thickness needed to be determined

NS and FW: lots of chars could be used for measurements, but may not be
present or may not have same values

MS: I know some experts (Ross Mills and John Hudson of Tyro Typeworks ) who
did Cambria and STIX fonts.

FW: I want to move some info from the constants table to the spec (
https://mathml-refresh.github.io/mathml-core/#layout-constants-mathconstants)
to make it easier for Rob to do implementation.

NS: I’m ok with that.

FW: We can change the spec values when we get better values.

RB: what did the older spec say about fallbacks?

NS: Nothing -- previous spec didn’t specify layout


MS: In Word, we put Cambria math at the start font lookup and then fallback
to other fonts.

MS: That gets math to look good and allows foriegn scripts to be used when
not in the math font.

NS: This is backward from what we were discussing, but that could be an
interesting approach.

NS: We talked about fallbacks to math fonts if chars not present in math
font, but axis height really needs to match - and +. Murray’s approach
solves that problem.

FW: I don’t think this is compatible with how fallbacks are defined in CSS.
In Firefox, we put it at the end of the list specified by the user.

FW: proposal is that math element defines a math font similar to a generic
font-family

NS: Murray is suggesting something different. Essentially the math element
adds to the start of the font-family list a math font.

FW: I think what was done in the browsers is to say that the user-agent
stylesheet has a default font family that contains a list of math fonts.
It’s hard coded and not clear that the font will be installed outside of
windows (Cambria).

FW: I was thinking we add a new generic “math” font family similar
“monospace”. We can have some mechinism to say what user-specified fonts
corresponding to ‘math”.

PI: Who is the user?

FW: Two users -- one defined by CSS one defined by the browser interface
which maps generic to a specific font. So in that case, user is browser
user.

PI: So if a user picks a bad font like comic, then the more fool them.

NS: If some picks comic when reading an Arabic text, then get Arabic, not
blanks.

PI: This is a communication problem between the author and reader. If the
reader picks something other than what the author intended, that’s on the
reader.

FW: the spec should give people a way to choose and say what should happen
when it is a bad choice?

NS: Did we resolve anything with font ordering?

FW: Should discuss with CSS folks to be consistent.width/height #45
<https://github.com/mathml-refresh/mathml/issues/45> #50
<https://github.com/mathml-refresh/mathml/issues/50> #51
<https://github.com/mathml-refresh/mathml/issues/51>FW: currently the
width/height is calculated. CSS allows specification of width/height. Does
width affect linebreaking? What about overflow, clipping, etc.

FW: proposal is width/height refers to border box or is it margin box? For
%, % of actual content, sort of like mspace. For mspace, default is 0, to
x% will always be 0.

FW: for %, it comes from the parent for block like elements (math, mtable).

BK: should resolve before next CSS F2F (TPAC in Sept)

BK: What should happen here:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=6703


FW: This is how layout of token elements is currently defined, we delegate
to CSS for the inner layout so as long as things are well defined in CSS it
shouldn’t be a problem:
https://mathml-refresh.github.io/mathml-core/#layout-of-mtext

FW: It would be good if parent doesn’t pass width down and we use that for
% because it complicates things. CSS does that for block elements.

NS: It seems like the math element and mtable are the only MathML elements
where that makes sense.

FW: Yes, they are display-block. It would affect linebreaking.

FW: For inline math or mrow, I’m not sure that makes sense. Maybe it should
take width of content.

FW: I think inline elements will ignore it.

BK: Yes, it will be ignored. It would be good to have tests and then we can
discuss whether that’s the result we want. A number of examples renders
differents. E.g.,

https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=6703

NS: should most math elements be inline. Leaf elements?

FW: Some people might want to use CSS to change width/height when writing a
polyfill

NS: Can always use mpadded to change width/height -- don’t need to use CSS.

FW: Implementation-wise: ignoring everything is easiest, then ignoring %,
then interpret % on content; last is to use parent width.

NS: Again, mpadded is there so maybe ignoring everywhere to make
implementation easist.


FW: I think token elements should act like a block and some HTML inside is
interpreted accordingly. CSS defines the layout inside of token elements.

NS: Block as opposed to inline?

FW: Block is how it is currently defined. David mentioned that block
elements wo

uld be allowed inside of token elements if they were inline.

NS: Wouldn’t that be make token elements be on separate lines

FW: Actually inline-block

FW: We just start with a width/height and CSS lays out the contents.
Defined in MathML code spec.

BK: div inside of span will layout more or less the same in all browsers
despite being illegal.

[some discussion of invalid HTML handling]

FW: In the end, we get some width/height from the contents and they get
used in math layout.


NS: Out of time. Good discussion and let’s continue this next week.