Planet MathML

It isn't wrong to put things in the WICG's discourse in the CSS category, but note that relatively few members of the CSSWG ever look there. If you don't feel ready to make a proposal to the CSSWG, this is potentially a good place to keep baking your ideas until you feel ready to present them, but if you do feel ready to talk about them, the CSSWG's github issues[1] or mailing list[2] are much more likely to get CSS people's attention.

—Florian

[1] https://github.com/w3c/csswg-drafts/issues
[2] www-style@w3.org

> On Jul 21, 2017, at 20:26, Siegman, Tzviya - Hoboken <tsiegman@wiley.com> wrote:
> 
> That looks good. I recommend adding something to the Web Incubator CG at https://discourse.wicg.io <https://discourse.wicg.io/> in the CSS category.
>  
> Tzviya Siegman
> Information Standards Lead
> Wiley
> 201-748-6884
> tsiegman@wiley.com <mailto:tsiegman@wiley.com>
>  
> From: Daniel Marques [mailto:dani@wiris.com] 
> Sent: Friday, July 21, 2017 6:18 AM
> To: Siegman, Tzviya - Hoboken <tsiegman@wiley.com>; Jean Kaplansky <jeankap@earthlink.net>; Arno Gourdol <arno@arno.org>
> Cc: Volker Sorge <volker.sorge@gmail.com>; mathonweb <public-mathonwebpages@w3.org>; Peter Krautzberger <peter@krautzource.com>
> Subject: RE: Reminder: Meeting today
>  
> Hi Tzviya,
>  
> Thanks for the information regarding the submissions.
>  
> Just wondering how much in advance… Regarding polyfills, did you mean something likehttps://w3c.github.io/mathonwebpages/examples/display/fraction1.html <https://w3c.github.io/mathonwebpages/examples/display/fraction1.html> (this is work in progress) ?
>  
> Regards,
>   <>
> Dani
>  
> From: Siegman, Tzviya - Hoboken [mailto:tsiegman@wiley.com <mailto:tsiegman@wiley.com>] 
> Sent: jueves, 20 de julio de 2017 22:37
> To: Jean Kaplansky; Arno Gourdol
> Cc: Volker Sorge; Daniel Marques; mathonweb; Peter Krautzberger
> Subject: RE: Reminder: Meeting today
>  
> Hi All,
>  
> Apologies for not being attend. If you have proposals for the CSS WG, you should get them to the group well in advance of TPAC. They usually have a really packed schedule. The way CSS tends to work these days is with submissions of polyfills, not just ideas. 
>  
> Tzviya
>  
> Tzviya Siegman
> Information Standards Lead
> Wiley
> 201-748-6884
> tsiegman@wiley.com <mailto:tsiegman@wiley.com>
>  
> From: Jean Kaplansky [mailto:jeankap@earthlink.net <mailto:jeankap@earthlink.net>] 
> Sent: Thursday, July 20, 2017 4:18 PM
> To: Arno Gourdol <arno@arno.org <mailto:arno@arno.org>>
> Cc: Volker Sorge <volker.sorge@gmail.com <mailto:volker.sorge@gmail.com>>; Daniel Marques <dani@wiris.com <mailto:dani@wiris.com>>; mathonweb <public-mathonwebpages@w3.org <mailto:public-mathonwebpages@w3.org>>; Peter Krautzberger <peter@krautzource.com <mailto:peter@krautzource.com>>
> Subject: Re: Reminder: Meeting today
>  
> Hi, Everyone -
>  
> K-12 publishing in the Western Hemisphere will be eternally grateful if you guys can take up the elementary math use cases with the CSS group too. Long division and Stacked Equations especially.
>  
> I'll keep an eye out for any google doc you guys may start to make sure that these use cases get on the list.
>  
> Thanks for considering.
>  
> Best,
> 
> Jean Kaplansky
> Content Architect/Strategist | Technical Account Manager | UI/UX |
> Accessibility Analyst | XML, HTML, and CSS Developer | 
> Instructional Designer
> +1.518.930.1068
> jeankap@earthlink.net <mailto:jeankap@earthlink.net>
> @jeankaplansky
>  
> On Thu, Jul 20, 2017 at 12:35 PM, Arno Gourdol <arno@arno.org <mailto:arno@arno.org>> wrote:
>  
> Minutes from 20 JULY 2017 Math On Web telcon
> Minute taker: Arno.
> Dani: would like to discuss with CSS WG about possibility to incorporate new CSS features that would suit out needs for mathematics.
> 
>  
> 
> At TPAC, we have the possibility to discuss with CSS WG what we would need to display mathematics without JS.
> 
>  
> 
> First we would need the scope of equations we want to support: fractions, matrix, big operators, supsub…?
> 
>  
> 
> Second, explain why CSS as it is is not enough to do represent those equations
> 
>  
> 
> Third, provide some hint/prototypes of what the solution could look like, perhaps with a Javascript implementation.
> 
>  
> 
> We need to do some planing to prepare for this, vacations are coming up for everyone. 
> 
>  
> 
> Neil: I’m away in August.
> 
>  
> 
> Neil: For large operators, would that include stretchy parens?
> 
>  
> 
> Dani: yes, probably.
> 
>  
> 
> Neil: if we can suggest to the CSS WG some non-math use cases, that will help motivate them
> 
>  
> 
> Dani: which math would we want to do? For example, fractions?
> 
>  
> 
> Neil: Wouldn’t Peter have a list like that? Has he approached the CSS WG already with some proposals? 
> 
>  
> 
> Dani: not that I’m aware of. Peter has had some unofficial conversations, perhaps.
> 
>  
> 
> Neil/John: square roots would be useful as well.
> 
>  
> 
> Neil: are fractions actually a problem?
> 
>  
> 
> Dani: sometimes the fraction bar need to be moved up or down, and it needs to be computed depending on the font size. 
> 
>  
> 
> Arno: we would probably need to have the concept of “math axis” similar to the “baseline” that exist today
> 
>  
> 
> Dani: flex box allows vertical alignments, and that helps for fractions and big operators
> 
>  
> 
> Neil: sounds like flex box is solving the problem for big operators, then?
> 
>  
> 
> Dani: yes, partially. But you need to move the operator to align with the math axis.
> 
>  
> 
> John: sounds like we need to work on a list of those cases
> 
>  
> 
> Arno: we also need to think of integrals that require limits to be displayed offset from the symbol
> 
>  
> 
> John: is there that list somewhere?
> 
>  
> 
> Neil: I thought Peter had something, but that may have been a long time ago…
> 
>  
> 
> Arno: I’d suggest creating a Google Docs that we could all collaborate on, with the goal of having something ready in time for TPAC.
> 
>  
> 
> Dani: I will create the document and share it with the group so we can start collaborating on these ideas.
> 

That looks good. I recommend adding something to the Web Incubator CG at https://discourse.wicg.io in the CSS category.

Tzviya Siegman
Information Standards Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Daniel Marques [mailto:dani@wiris.com]
Sent: Friday, July 21, 2017 6:18 AM
To: Siegman, Tzviya - Hoboken <tsiegman@wiley.com>; Jean Kaplansky <jeankap@earthlink.net>; Arno Gourdol <arno@arno.org>
Cc: Volker Sorge <volker.sorge@gmail.com>; mathonweb <public-mathonwebpages@w3.org>; Peter Krautzberger <peter@krautzource.com>
Subject: RE: Reminder: Meeting today

Hi Tzviya,

Thanks for the information regarding the submissions.

Just wondering how much in advance… Regarding polyfills, did you mean something like https://w3c.github.io/mathonwebpages/examples/display/fraction1.html (this is work in progress) ?

Regards,

Dani

From: Siegman, Tzviya - Hoboken [mailto:tsiegman@wiley.com<mailto:tsiegman@wiley.com>]
Sent: jueves, 20 de julio de 2017 22:37
To: Jean Kaplansky; Arno Gourdol
Cc: Volker Sorge; Daniel Marques; mathonweb; Peter Krautzberger
Subject: RE: Reminder: Meeting today

Hi All,

Apologies for not being attend. If you have proposals for the CSS WG, you should get them to the group well in advance of TPAC. They usually have a really packed schedule. The way CSS tends to work these days is with submissions of polyfills, not just ideas.

Tzviya

Tzviya Siegman
Information Standards Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Jean Kaplansky [mailto:jeankap@earthlink.net]
Sent: Thursday, July 20, 2017 4:18 PM
To: Arno Gourdol <arno@arno.org<mailto:arno@arno.org>>
Cc: Volker Sorge <volker.sorge@gmail.com<mailto:volker.sorge@gmail.com>>; Daniel Marques <dani@wiris.com<mailto:dani@wiris.com>>; mathonweb <public-mathonwebpages@w3.org<mailto:public-mathonwebpages@w3.org>>; Peter Krautzberger <peter@krautzource.com<mailto:peter@krautzource.com>>
Subject: Re: Reminder: Meeting today

Hi, Everyone -

K-12 publishing in the Western Hemisphere will be eternally grateful if you guys can take up the elementary math use cases with the CSS group too. Long division and Stacked Equations especially.

I'll keep an eye out for any google doc you guys may start to make sure that these use cases get on the list.

Thanks for considering.

Best,

Jean Kaplansky
Content Architect/Strategist | Technical Account Manager | UI/UX |
Accessibility Analyst | XML, HTML, and CSS Developer |
Instructional Designer
+1.518.930.1068
jeankap@earthlink.net<mailto:jeankap@earthlink.net>
@jeankaplansky

On Thu, Jul 20, 2017 at 12:35 PM, Arno Gourdol <arno@arno.org<mailto:arno@arno.org>> wrote:

Minutes from 20 JULY 2017 Math On Web telcon
Minute taker: Arno.

Dani: would like to discuss with CSS WG about possibility to incorporate new CSS features that would suit out needs for mathematics.



At TPAC, we have the possibility to discuss with CSS WG what we would need to display mathematics without JS.



First we would need the scope of equations we want to support: fractions, matrix, big operators, supsub…?



Second, explain why CSS as it is is not enough to do represent those equations



Third, provide some hint/prototypes of what the solution could look like, perhaps with a Javascript implementation.



We need to do some planing to prepare for this, vacations are coming up for everyone.



Neil: I’m away in August.



Neil: For large operators, would that include stretchy parens?



Dani: yes, probably.



Neil: if we can suggest to the CSS WG some non-math use cases, that will help motivate them



Dani: which math would we want to do? For example, fractions?



Neil: Wouldn’t Peter have a list like that? Has he approached the CSS WG already with some proposals?



Dani: not that I’m aware of. Peter has had some unofficial conversations, perhaps.



Neil/John: square roots would be useful as well.



Neil: are fractions actually a problem?



Dani: sometimes the fraction bar need to be moved up or down, and it needs to be computed depending on the font size.



Arno: we would probably need to have the concept of “math axis” similar to the “baseline” that exist today



Dani: flex box allows vertical alignments, and that helps for fractions and big operators



Neil: sounds like flex box is solving the problem for big operators, then?



Dani: yes, partially. But you need to move the operator to align with the math axis.



John: sounds like we need to work on a list of those cases



Arno: we also need to think of integrals that require limits to be displayed offset from the symbol



John: is there that list somewhere?



Neil: I thought Peter had something, but that may have been a long time ago…



Arno: I’d suggest creating a Google Docs that we could all collaborate on, with the goal of having something ready in time for TPAC.



Dani: I will create the document and share it with the group so we can start collaborating on these ideas.

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

Hi Tzviya,



Thanks for the information regarding the submissions.



Just wondering how much in advance… Regarding polyfills, did you mean
something like
https://w3c.github.io/mathonwebpages/examples/display/fraction1.html (this
is work in progress) ?



Regards,



Dani



*From:* Siegman, Tzviya - Hoboken [mailto:tsiegman@wiley.com]
*Sent:* jueves, 20 de julio de 2017 22:37
*To:* Jean Kaplansky; Arno Gourdol
*Cc:* Volker Sorge; Daniel Marques; mathonweb; Peter Krautzberger
*Subject:* RE: Reminder: Meeting today



Hi All,



Apologies for not being attend. If you have proposals for the CSS WG, you
should get them to the group well in advance of TPAC. They usually have a
really packed schedule. The way CSS tends to work these days is with
submissions of polyfills, not just ideas.



Tzviya



*Tzviya Siegman*

Information Standards Lead

Wiley

201-748-6884

tsiegman@wiley.com



*From:* Jean Kaplansky [mailto:jeankap@earthlink.net <jeankap@earthlink.net>]

*Sent:* Thursday, July 20, 2017 4:18 PM
*To:* Arno Gourdol <arno@arno.org>
*Cc:* Volker Sorge <volker.sorge@gmail.com>; Daniel Marques <dani@wiris.com>;
mathonweb <public-mathonwebpages@w3.org>; Peter Krautzberger <
peter@krautzource.com>
*Subject:* Re: Reminder: Meeting today



Hi, Everyone -



K-12 publishing in the Western Hemisphere will be eternally grateful if you
guys can take up the elementary math use cases with the CSS group too. Long
division and Stacked Equations especially.



I'll keep an eye out for any google doc you guys may start to make sure
that these use cases get on the list.



Thanks for considering.



Best,


*Jean Kaplansky*
Content Architect/Strategist | Technical Account Manager | UI/UX |
Accessibility Analyst | XML, HTML, and CSS Developer |
Instructional Designer
+1.518.930.1068
jeankap@earthlink.net
@jeankaplansky



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



Minutes from 20 JULY 2017 Math On Web telcon

Minute taker: Arno.

Dani: would like to discuss with CSS WG about possibility to incorporate
new CSS features that would suit out needs for mathematics.



At TPAC, we have the possibility to discuss with CSS WG what we would need
to display mathematics without JS.



First we would need the scope of equations we want to support: fractions,
matrix, big operators, supsub…?



Second, explain why CSS as it is is not enough to do represent those
equations



Third, provide some hint/prototypes of what the solution could look like,
perhaps with a Javascript implementation.



We need to do some planing to prepare for this, vacations are coming up for
everyone.



Neil: I’m away in August.



Neil: For large operators, would that include stretchy parens?



Dani: yes, probably.



Neil: if we can suggest to the CSS WG some non-math use cases, that will
help motivate them



Dani: which math would we want to do? For example, fractions?



Neil: Wouldn’t Peter have a list like that? Has he approached the CSS WG
already with some proposals?



Dani: not that I’m aware of. Peter has had some unofficial conversations,
perhaps.



Neil/John: square roots would be useful as well.



Neil: are fractions actually a problem?



Dani: sometimes the fraction bar need to be moved up or down, and it needs
to be computed depending on the font size.



Arno: we would probably need to have the concept of “math axis” similar to
the “baseline” that exist today



Dani: flex box allows vertical alignments, and that helps for fractions and
big operators



Neil: sounds like flex box is solving the problem for big operators, then?



Dani: yes, partially. But you need to move the operator to align with the
math axis.



John: sounds like we need to work on a list of those cases



Arno: we also need to think of integrals that require limits to be
displayed offset from the symbol



John: is there that list somewhere?



Neil: I thought Peter had something, but that may have been a long time ago…



Arno: I’d suggest creating a Google Docs that we could all collaborate on,
with the goal of having something ready in time for TPAC.



Dani: I will create the document and share it with the group so we can
start collaborating on these ideas.

Hi All,

Apologies for not being attend. If you have proposals for the CSS WG, you should get them to the group well in advance of TPAC. They usually have a really packed schedule. The way CSS tends to work these days is with submissions of polyfills, not just ideas.

Tzviya

Tzviya Siegman
Information Standards Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Jean Kaplansky [mailto:jeankap@earthlink.net]
Sent: Thursday, July 20, 2017 4:18 PM
To: Arno Gourdol <arno@arno.org>
Cc: Volker Sorge <volker.sorge@gmail.com>; Daniel Marques <dani@wiris.com>; mathonweb <public-mathonwebpages@w3.org>; Peter Krautzberger <peter@krautzource.com>
Subject: Re: Reminder: Meeting today

Hi, Everyone -

K-12 publishing in the Western Hemisphere will be eternally grateful if you guys can take up the elementary math use cases with the CSS group too. Long division and Stacked Equations especially.

I'll keep an eye out for any google doc you guys may start to make sure that these use cases get on the list.

Thanks for considering.

Best,

Jean Kaplansky
Content Architect/Strategist | Technical Account Manager | UI/UX |
Accessibility Analyst | XML, HTML, and CSS Developer |
Instructional Designer
+1.518.930.1068
jeankap@earthlink.net<mailto:jeankap@earthlink.net>
@jeankaplansky

On Thu, Jul 20, 2017 at 12:35 PM, Arno Gourdol <arno@arno.org<mailto:arno@arno.org>> wrote:

Minutes from 20 JULY 2017 Math On Web telcon
Minute taker: Arno.

Dani: would like to discuss with CSS WG about possibility to incorporate new CSS features that would suit out needs for mathematics.



At TPAC, we have the possibility to discuss with CSS WG what we would need to display mathematics without JS.



First we would need the scope of equations we want to support: fractions, matrix, big operators, supsub…?



Second, explain why CSS as it is is not enough to do represent those equations



Third, provide some hint/prototypes of what the solution could look like, perhaps with a Javascript implementation.



We need to do some planing to prepare for this, vacations are coming up for everyone.



Neil: I’m away in August.



Neil: For large operators, would that include stretchy parens?



Dani: yes, probably.



Neil: if we can suggest to the CSS WG some non-math use cases, that will help motivate them



Dani: which math would we want to do? For example, fractions?



Neil: Wouldn’t Peter have a list like that? Has he approached the CSS WG already with some proposals?



Dani: not that I’m aware of. Peter has had some unofficial conversations, perhaps.



Neil/John: square roots would be useful as well.



Neil: are fractions actually a problem?



Dani: sometimes the fraction bar need to be moved up or down, and it needs to be computed depending on the font size.



Arno: we would probably need to have the concept of “math axis” similar to the “baseline” that exist today



Dani: flex box allows vertical alignments, and that helps for fractions and big operators



Neil: sounds like flex box is solving the problem for big operators, then?



Dani: yes, partially. But you need to move the operator to align with the math axis.



John: sounds like we need to work on a list of those cases



Arno: we also need to think of integrals that require limits to be displayed offset from the symbol



John: is there that list somewhere?



Neil: I thought Peter had something, but that may have been a long time ago…



Arno: I’d suggest creating a Google Docs that we could all collaborate on, with the goal of having something ready in time for TPAC.



Dani: I will create the document and share it with the group so we can start collaborating on these ideas.

Hi, Everyone -

K-12 publishing in the Western Hemisphere will be eternally grateful if you
guys can take up the elementary math use cases with the CSS group too. Long
division and Stacked Equations especially.

I'll keep an eye out for any google doc you guys may start to make sure
that these use cases get on the list.

Thanks for considering.

Best,

*Jean Kaplansky*
Content Architect/Strategist | Technical Account Manager | UI/UX |
Accessibility Analyst | XML, HTML, and CSS Developer |
Instructional Designer
+1.518.930.1068
jeankap@earthlink.net
@jeankaplansky <jeankap@earthlink.net>

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

>
> Minutes from 20 JULY 2017 Math On Web telcon
> Minute taker: Arno.
>
> Dani: would like to discuss with CSS WG about possibility to incorporate
> new CSS features that would suit out needs for mathematics.
>
>
> At TPAC, we have the possibility to discuss with CSS WG what we would need
> to display mathematics without JS.
>
>
> First we would need the scope of equations we want to support: fractions,
> matrix, big operators, supsub…?
>
>
> Second, explain why CSS as it is is not enough to do represent those
> equations
>
>
> Third, provide some hint/prototypes of what the solution could look like,
> perhaps with a Javascript implementation.
>
>
> We need to do some planing to prepare for this, vacations are coming up
> for everyone.
>
>
> Neil: I’m away in August.
>
>
> Neil: For large operators, would that include stretchy parens?
>
>
> Dani: yes, probably.
>
>
> Neil: if we can suggest to the CSS WG some non-math use cases, that will
> help motivate them
>
>
> Dani: which math would we want to do? For example, fractions?
>
>
> Neil: Wouldn’t Peter have a list like that? Has he approached the CSS WG
> already with some proposals?
>
>
> Dani: not that I’m aware of. Peter has had some unofficial conversations,
> perhaps.
>
>
> Neil/John: square roots would be useful as well.
>
>
> Neil: are fractions actually a problem?
>
>
> Dani: sometimes the fraction bar need to be moved up or down, and it needs
> to be computed depending on the font size.
>
>
> Arno: we would probably need to have the concept of “math axis” similar to
> the “baseline” that exist today
>
>
> Dani: flex box allows vertical alignments, and that helps for fractions
> and big operators
>
>
> Neil: sounds like flex box is solving the problem for big operators, then?
>
>
> Dani: yes, partially. But you need to move the operator to align with the
> math axis.
>
>
> John: sounds like we need to work on a list of those cases
>
>
> Arno: we also need to think of integrals that require limits to be
> displayed offset from the symbol
>
>
> John: is there that list somewhere?
>
>
> Neil: I thought Peter had something, but that may have been a long time
> ago…
>
>
> Arno: I’d suggest creating a Google Docs that we could all collaborate on,
> with the goal of having something ready in time for TPAC.
>
>
> Dani: I will create the document and share it with the group so we can
> start collaborating on these ideas.
>

Minutes from 20 JULY 2017 Math On Web telcon
Minute taker: Arno.

Dani: would like to discuss with CSS WG about possibility to incorporate
new CSS features that would suit out needs for mathematics.


At TPAC, we have the possibility to discuss with CSS WG what we would need
to display mathematics without JS.


First we would need the scope of equations we want to support: fractions,
matrix, big operators, supsub…?


Second, explain why CSS as it is is not enough to do represent those
equations


Third, provide some hint/prototypes of what the solution could look like,
perhaps with a Javascript implementation.


We need to do some planing to prepare for this, vacations are coming up for
everyone.


Neil: I’m away in August.


Neil: For large operators, would that include stretchy parens?


Dani: yes, probably.


Neil: if we can suggest to the CSS WG some non-math use cases, that will
help motivate them


Dani: which math would we want to do? For example, fractions?


Neil: Wouldn’t Peter have a list like that? Has he approached the CSS WG
already with some proposals?


Dani: not that I’m aware of. Peter has had some unofficial conversations,
perhaps.


Neil/John: square roots would be useful as well.


Neil: are fractions actually a problem?


Dani: sometimes the fraction bar need to be moved up or down, and it needs
to be computed depending on the font size.


Arno: we would probably need to have the concept of “math axis” similar to
the “baseline” that exist today


Dani: flex box allows vertical alignments, and that helps for fractions and
big operators


Neil: sounds like flex box is solving the problem for big operators, then?


Dani: yes, partially. But you need to move the operator to align with the
math axis.


John: sounds like we need to work on a list of those cases


Arno: we also need to think of integrals that require limits to be
displayed offset from the symbol


John: is there that list somewhere?


Neil: I thought Peter had something, but that may have been a long time ago…


Arno: I’d suggest creating a Google Docs that we could all collaborate on,
with the goal of having something ready in time for TPAC.


Dani: I will create the document and share it with the group so we can
start collaborating on these ideas.

Thanks
EOM

Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
E-mail: charlesl@benetech.org<mailto:charlesl@benetech.org>
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
Phone: 650-600-3301



On Jul 20, 2017, at 7:47 AM, Daniel Marques <dani@wiris.com<mailto:dani@wiris.com>> wrote:

HI everybody,

I guess we have a meeting today!

I would like to discuss about the enhancements to CSS during TPAC 2017.

Dani

On Thu, Jul 6, 2017 at 5:03 PM, Peter Krautzberger <peter@krautzource.com<mailto:peter@krautzource.com>> wrote:
Hi everyone,

We are scheduled to meet today, July 6, 12pm Eastern time. (I.e. in about 1 hour.)

The meeting topic is MathML.

Best,
Peter.

Apologies. I'm at a meeting in Edinburgh today.
Volker

On 20 Jul 2017 3:48 pm, "Daniel Marques" <dani@wiris.com> wrote:

> HI everybody,
>
> I guess we have a meeting today!
>
> I would like to discuss about the enhancements to CSS during TPAC 2017.
>
> Dani
>
> On Thu, Jul 6, 2017 at 5:03 PM, Peter Krautzberger <peter@krautzource.com>
> wrote:
>
>> Hi everyone,
>>
>> We are scheduled to meet today, July 6, 12pm Eastern time. (I.e. in about
>> 1 hour.)
>>
>> The meeting topic is MathML.
>>
>> Best,
>> Peter.
>>
>
>

HI everybody,

I guess we have a meeting today!

I would like to discuss about the enhancements to CSS during TPAC 2017.

Dani

On Thu, Jul 6, 2017 at 5:03 PM, Peter Krautzberger <peter@krautzource.com>
wrote:

> Hi everyone,
>
> We are scheduled to meet today, July 6, 12pm Eastern time. (I.e. in about
> 1 hour.)
>
> The meeting topic is MathML.
>
> Best,
> Peter.
>

Hi Liam,

Sorry for my delayed answer but I'm in the middle of closing many projects.

It is great that some people still think that with CSS should be possible to
do mathematics easier. It is probably very improbable to be able to do all
the MathML specification. But, at least, simple formulas with fractions,
roots and matrices, among others, should be achievable.

You say
> If this CG were to come up with a list of the most urgent things together
> with some tests (and patches for browsers?) I can see something happening.
That's for sure a starting point and makes sense working in this direction.
We can elaborate it more during the following group meetings.

I appreciate very much your suggestion.

Daniel Marques

-----Original Message-----
From: Liam R. E. Quin [mailto:liam@w3.org]
Sent: jueves, 6 de julio de 2017 20:45
To: Arno Gourdol; Daniel Marques
Cc: Peter Krautzberger; mathonweb
Subject: Re: Reminder: Meeting today

On Thu, 2017-07-06 at 10:20 -0700, Arno Gourdol wrote:
> Minutes from the meeting today. Any transcription errors are my own.
>
> Display of math in HTML 5

It took more than a decade for SVG to get supported natively in Web
browsers, so "never" isn't right. The support is neither perfect nor
complete (e.g. browser vendors don't seem to like SMIL animation, possibly
because it reminds them of XML) but it's usable.

If this CG were to come up with a list of the most urgent things together
with some tests (and patches for browsers?) I can see something happening.

Built-up fences, fractions, stretching characters (e.g. via font
transformation matrix), aligning separate blocks (displayed equations) on
the = sign even if there isn't one, all also have applications outside
mathematics, so having CSS able to do them would make sense to me.

[...]

> Would be much better to have an API to measure offscreen elements.

To some extent you can do this today, but you can't get at font metrics, and
in particular the math table. There are some privacy issues, but if it was
restricted to downloaded fonts maybe that would be OK.

A set of proposals for CSS might be something that the CSS WG could
conceivably consider at TPAC.

Liam

On Thu, 2017-07-06 at 10:20 -0700, Arno Gourdol wrote:
> Minutes from the meeting today. Any transcription errors are my own.
> 
> Display of math in HTML 5

It took more than a decade for SVG to get supported natively in Web
browsers, so "never" isn't right. The support is neither perfect nor
complete (e.g. browser vendors don't seem to like SMIL animation,
possibly because it reminds them of XML) but it's usable.

If this CG were to come up with a list of the most urgent things
together with some tests (and patches for browsers?) I can see
something happening.

Built-up fences, fractions, stretching characters (e.g. via font
transformation matrix), aligning separate blocks (displayed equations)
on the = sign even if there isn't one, all also have applications
outside mathematics, so having CSS able to do them would make sense to
me.

[...]

> Would be much better to have an API to measure offscreen elements.

To some extent you can do this today, but you can't get at font
metrics, and in particular the math table. There are some privacy
issues, but if it was restricted to downloaded fonts maybe that would
be OK.

A set of proposals for CSS might be something that the CSS WG could
conceivably consider at TPAC.

Liam

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?

Hi,



I updated the examples of formulas with solely HTML5 at
https://w3c.github.io/mathonwebpages/examples/display/html5.html



I’ve added two examples with matrices at the end of the page.



It seems realistic to display simple matrices with HTML5  except for the
known limitations with stretchy parenthesis and vertical align that needs
precomputed numeric alignment.



Dani



*From:* Peter Krautzberger [mailto:peter@krautzource.com]
*Sent:* jueves, 6 de julio de 2017 17:24
*To:* mathonweb
*Subject:* Re: Reminder: Meeting today



Last minute regrets from me, I'm afraid.



If somebody can minute the meeting, that would be great.



Best,

Peter.



On Jul 6, 2017 5:03 PM, "Peter Krautzberger" <peter@krautzource.com> wrote:

Hi everyone,



We are scheduled to meet today, July 6, 12pm Eastern time. (I.e. in about 1
hour.)



The meeting topic is MathML.



Best,

Peter.

Last minute regrets from me, I'm afraid.

If somebody can minute the meeting, that would be great.

Best,
Peter.

On Jul 6, 2017 5:03 PM, "Peter Krautzberger" <peter@krautzource.com> wrote:

> Hi everyone,
>
> We are scheduled to meet today, July 6, 12pm Eastern time. (I.e. in about
> 1 hour.)
>
> The meeting topic is MathML.
>
> Best,
> Peter.
>

Hi everyone,

We are scheduled to meet today, July 6, 12pm Eastern time. (I.e. in about 1
hour.)

The meeting topic is MathML.

Best,
Peter.

Hi everyone,

Below are the minutes from the CG meeting last week. A bit more condensed
than usual.

The next meeting will be on July 6 and we'll broadly discuss MathML.

Best,
Peter.

# [math on web CG] minutes 2017-06-22

* Peter: statuson https://github.com/w3c/csswg-drafts/issues/1339
  * more input from MathJax side
  * first positive responses from Tab
  * => more feedback needed
* Arno: mathlive now on github
  * https://github.com/arnog/mathlive/
  * some discusssion around the code base
* What do we want to talk about next? layout, a11y, formats
  * Neil: interested in talking broadly about MathML
    * some preliminary discussion what that might entail
    * => agreed

My apologies. I have to go out on short notice. I might catch the end
of the meeting.
Best,
Volker

On 22 June 2017 at 12:24, Peter Krautzberger <peter@krautzource.com> wrote:
> Hi everyone,
>
> Just a reminder that we're meeting today.
>
> The focus topic will be layout, continuing from the last meeting.
>
> Best wishes,
> Peter.

Same (waves down the table to Charles ☺)

From: Charles LaPierre <charlesl@benetech.org>
Date: Thursday, June 22, 2017 at 9:01 AM
To: Peter Krautzberger <peter@krautzource.com>
Cc: "public-mathonwebpages@w3.org" <public-mathonwebpages@w3.org>
Subject: Re: [math-on-web] reminder: meeting 2017/06/22
Resent-From: <public-mathonwebpages@w3.org>
Resent-Date: Thursday, June 22, 2017 at 9:02 AM

Regrets I am at the W3C Publishing Face to Face meetings in New York today.

Thanks
EOM

Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
E-mail: charlesl@benetech.org<mailto:charlesl@benetech.org>
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
Phone: 650-600-3301


On Jun 22, 2017, at 7:24 AM, Peter Krautzberger <peter@krautzource.com<mailto:peter@krautzource.com>> wrote:

Hi everyone,

Just a reminder that we're meeting today.

The focus topic will be layout, continuing from the last meeting.

Best wishes,
Peter.