- From: Daniel Marques <dani@wiris.com>
- Date: Fri, 21 Jul 2017 12:34:04 +0200
- To: Arno Gourdol <arno@arno.org>
- Cc: Peter Krautzberger <peter@krautzource.com>, mathonweb <public-mathonwebpages@w3.org>
- Message-ID: <CAFGc8v2M+PrJpqWODQqyFtzZB9qGJ5tD=SZHpDWBH31ZRqFB4A@mail.gmail.com>
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? > > > > > > > > > > > >
Received on Friday, 21 July 2017 10:34:30 UTC