Re: Reminder: Meeting today

Minutes from the meeting today. Any transcription errors are my own.

Display of math in HTML 5


Peter want to discuss MathML, but not feeling well today and he sends his
apologies.


Neil Soiffer: Peter has said that MathML is inadequate on the web. What are
its particular limitations/problems?


Volker Sorge: MathML is a fine presentation language. But it’s not
implemented, and probably won’t be fully implemented. It’s not modern
enough. It was trying to do things ten years ago that are now available in
CSS/HTML. What is really *necessary* to render Math that is not available
in HTML/CSS today? Rather than keep asking for an implementation of MathML
that is not happening.


Neil: Understood, but custom elements, shadow DOM may be a way to leave the
DOM clean and use CSS for rendering. And it’s been closer to twenty years,
not ten! So, are there things very problematic in MathML that would never
make it in CSS? For example, I’ve always been opposed to <mfence>,
<mstyle>, but what else?


<someone>: <mfence>: we all hate it!


Neil: Always regretted <mfence>, I’d be happy to see it go. What else are
we talking about? Maybe you don’t believe in Shadow DOM or custom elements,
but if they do happen, it would leave the DOM nice and clean.


Volker: do you expect browsers to implement MathML or web apps to make use
of it. Should MathML not be adapted to be more realistic to what browsers
would actually implement?


Neil: The problem with MathJax, etc… is that you’re polluting the DOM and
have spans, etc… that don’t represent the content, but just the
presentation. Shadow DOM could help with that. I’d like to see browser
implementation of MathML, but the major thing is to have a clean DOM
instead of a tag soup. I’d like to see MathML implemented with a shadow
DOM, and maybe it would encourage browser vendors to adopt it.


Volker: One of my main issues with MathML is that presentation MathML has
some semantic in it, which can be confusing and abused for other things. Is
it really necessary to have a special <mfrac> or special square root, etc..
rather than something more general to “enclose” elements.


Stretching characters is a particular problem to cover.


Neil: <menclose> has a square root option, but you’d rather see it
generalized? Not sure how we would deal with n-th root, but there might be
a way.


Volker: yeah, and same thing for fractions. In particular for
accessibility, you’d want to control the order: just have a bar and specify
where the numer/denom is in the DOM.


Neil: asian languages read fractions the other way around, but they’re
displayed the same way.


Volker: you’d want to draw them the same way, but want to traverse them
differently in the DOM.


Neil: not sure I see the need for that. If a screen reader wants to read in
a certain way, they can determine what is the right order


Arno: but wouldn’t it be difficult without the semantic information for the
screen reader to infer the correct order?


Volker: I don’t always want to represent a fraction, so I want to be able
to give it explicit order, kinda like a ‘z-index’, but for reading order.
For example, in logic, when you want to talk about conclusions before
premises, the author may want to specify the correct order. There should be
a better separation between presentation and semantics.


Dani: the assistive technology can read the page, can access the DOM, but
the assistive technology shouldn’t have to infer the semantic


Volker: yes. With web apps for example, you can implement a pull down menu
for example, however you want. The ARIA attributes will give screen readers
the right info to interpret it correctly.


Neil: there is a difference. Screen readers already know about buttons,
etc… but they don’t know about fractions, etc..


Volker: true, but couldn’t you put some descriptions for the things they
don’t know.


Neil: they would need to know about some primitives: fractions, deductions,
etc…


Volker: what would they need to know about semantics? Couldn’t they just
have some info about order, and what to say?


Neil: but that’s language dependent. The order and how to say it in other
languages. In fact, with math speech, there isn’t a single way to say
something. Why force it?


Volker: if I’m in an English web page, I don’t expect the screen reader to
tell it to me in German. If there’s English math on it, it should read it
in English, not try to localize it in German.


Neil: Once it’s been generated, the language is known, I agree, but there
are still multiple way to speak math notations. Steve Noble went to a
school, but a teacher said “that’s not how I say parenthesis”. And another
teacher in the same school was saying the same thing completely differently
(“open paren” vs. “left paren”, etc…)


Volker: shouldn’t the author be in control of that?


Neil: the teacher might be reading Wikipedia or Kahn academy, something
they didn’t author. For example, screen readers give control over how much
punctuations are said.


Steve Noble: We found that students who are visually impaired needed the
additional language (“begin root”/“end root”) to read while other students
who are dyslexic for example would stumble with that same additional
language. Users that use a Braille Nemeth reader need a different rendering
that Braille users using a different system.


Volker: I agree there’s still a lot of work to do on the screen reader
side, but I still don’t see why we need MathML for that. Unfortunately, I
do have the leave the call now.


Steve: I see three pillars:

(1) There are problems with the MathML standard and they should be fixed.

(2) browsers and other tools need to implement MathML.

(3) techniques we use in the meantime, like MathJAX, while the other
pillars get resolved on their own timeline


Volker: I don’t feel like the second pillar will ever happen, and we should
step back and determine more realistic goals in terms of changes to
CSS/HTML, like stretchy characters.


Dani: MathML is also important from the authoring point of view: if you
create a tool to create a formula you need an interoperable way to exchange
machine-readable formulas between tools.


Arno: what would be the benefit of MathML over LaTeX for interchange?


Neil: the problem with LaTeX is that it’s a programming language, with no
fixed syntax, lots of extensions. Too powerful to be used for exchange
unless you have a full TeX engine. Also MathML is easy to parse, since it’s
XML, easy to get a tree.


Arno: have there been discussions of a JSON version of MathML that would be
even easier to parse?


Neil: not aware of it, but there are mapping between XML and JSON, so it’s
certainly possible.


Dani: didn’t think a lot about what I would change in MathML, but
interoperability between browsers could be better. Simple things like
fractions, stretchy characters is where the difficulties are today, so
changing MathML would not be a priority for me.


Neil: Another thing that would be useful could be font info.


Arno: Agreed. To do a layout with CSS/HTML you sometimes have to get
measurements of elements, and it’s not always easy to do. You have to use
some workarounds, like creating elements and temporarily inserting them as
invisible elements in the page in order to get their bounding rectangles.
Would be much better to have an API to measure offscreen elements. It would
also be very useful to have access to information such as the math axis and
other math typesetting specific data which are available in some “math”
fonts such as Cambria Math (see
https://www.microsoft.com/typography/otspec/math.htm).


Dani: but some of that info is not proportional to the font size. For
example, a 2pt value at 16pt may need to be 5pt at 32pt.


Arno: That’s right, and that’s the information that is included in those
‘math’ tables that are embedded in ‘math’ fonts, but that information is
not accessible from CSS or Javascript. Same thing if the concept of “math
axis” similar to the concept of “baseline” was understood by CSS. It would
make math layout much easier. That would be really nice to have. Perhaps an
area of further discussion and collaboration with the CSS WG and others?