Re: Reminder: Meeting today

Hi Arno and others!

Thanks for the minutes.

I created the document
https://docs.google.com/document/d/1VZcmZad-ZU6zC390r4LiQLIcO415bQOhoDVonN7sIsw/edit
and I've given access to some of you. Anyone that wants a write access can
request it to me and I will give it.

Regards,

Dani

On Thu, Jul 6, 2017 at 7:20 PM, Arno Gourdol <arno@arno.org> wrote:

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