Getting Math Onto Web Pages

[iherman]

There is a Community Group

There are many technical issues in presenting mathematics in today's Open Web Platform, which has led to the poor access to Mathematics in Web Pages. This is in spite of the existing de jure or de facto standards for authoring mathematics, like MathML, LaTeX, or asciimath, which have been around for a very long time and are widely used by the mathematical and technical communities.

While MathML was supposed to solve the problem of rendering mathematics on the web it lacks in both implementations and general interest from browser vendors. However, in the past decade, many math rendering tools have been pushing math on the web forward using HTML/CSS and SVG.

One of the identified issues is that, while browser manufacturers have continually improved and extended their HTML and CSS layout engines, the approaches to render mathematics have not been able to align with these improvements. In fact, the current approaches to math layout could be considered to be largely disjoint from the other technologies of OWP. Another key issue, is that exposing (and thus leveraging) semantic information of mathematical and scientific content on the web needs to move towards modern practices and standards instead of being limited to a single solution (MathML). Such information is critical for accessibility, machine-readability, and re-use of mathematical content.

This Community Group intends to look at the problems of math on the web in a very bottom-up manner. Experts in this group should identify how the core OWP layout engines, centered around HTML, SVG, and CSS, can be re-used for the purpose of mathematical layout by mapping mathematical entities on top of these, thereby ensuring a much more efficient result, and making use of current and future OWP optimization possibilities. Similarly, experts should work to identify best practices for semantics from the point of view of today's successful solutions.

[iherman]

The current discussions are not yet really focussed. Potentially this work may have an influence on CSS, and is of a major importance for publishers.

[svgeesus]

Text based math standards

[svgeesus]

https://github.com/w3c/mathonwebpages

[iherman]

Interesting discussion threads on the CG:

• https://lists.w3.org/Archives/Public/public-mathonwebpages/2018Jan/0003.html
• https://lists.w3.org/Archives/Public/public-mathonwebpages/2018Jan/0010.html

[liamquin]

A strategy favoured by at least a few on the CG is to try and persuade CSS to add features for formatting mathematics, taking the magic out of particular element names. Some of mathematics layout is generally useful - e.g. aligning multiple displayed equations on the = sign (vaguely doable today with css grid, as are matrices) - or splitting of complex multi-line objects across lines (also useful possibly for the two-line Japanese) - or building up diacriticals and superscripts/subscripts, or (best of all perhaps) large brackets and braces made of multiple pieces.

Down sides to this strategy: (1) it doesn't work very well. CSS is too busy to pay attention to other people's needs. (2) there's a lot of details in mathematics formatting that don't apply elsewhere. (3) just because you can descrine an equation doesn't mean you can evaluate it. There's need for both. (4) mathml is really aimed too high :) and needs to cover elementary through high school (US "K12") enough for text books, exams, general writing. it needs to go for the 70% rather than the 5% of post-undergraduate mathemtaics and engineering needs.

Having said that, maybe we still don't have strong enough links with people like stmassoc.org - still a large and relatively wealthy publishing segment with a vested interest in having people be able to read their journal articles on the Web. Maybe they could be persuaded to fung Igalia's mathml effort?

[GeorgeKerscher]

Thinking about publishing, math is very important. Now that publishing is in scope for the W3C, a solution on how to present math is essential. Of course, accessibility is essential. Not only do people need to publish and read the math with their Assistive Technology, but there must be strategies for writing math. LaTex and ASCIImath have been mentioned and a standardized approach must be identified. The publishing community needs techniques they can use now and a longer term approach needs to be identified.

I view math as an essential part of the web and I suggest that the importance of math be elevated in the W3C team.

[sinabahram]

I think it's critical to get this problem right given how mixed reactions have always been to MathML. Easy extraction of semantics of the mathematics must be the priority here. Once that is achievable, everything else is virtually guaranteed to work. Styling based on meaning and appropriate identification of similar, but subtly different, pieces of mathematics would allow for publishers to use such a solution in their workflows instead of relying on image-based presentation of mathematics.

[clapierre]

I agree with what @GeorgeKerscher and @sinabahram have said. Publishers are begging for a solution, especially in the K-12 space, on how to put math in their publications in an accessible way. I support what the MathOnWeb CG is doing which I feel is a longer term solution. What publishers need is something is something now. Publishers have the MathML, or could obtain it, but are commenting it out or leaving out the mathML completely and replacing it with an inaccessible image of the math mainly due to the poor rendering of mathML and it inconsisten support accross browsers. I think a semantically rich SVG of math equations that would help low vision users zoom into complex equations without pixelation and can be explored by assistive technologies is an ideal long-term solution. But what does the publishers do in the meantime and want to make their math accessible?

[NSoiffer]

It seems like there are several threads here. I won’t address all of them, but here are my thoughts on some of them:

Math notation vs semantics – very few people seem to be willing to take the time to write semantic math; they are mainly interested in what it looks like for publishing. One can argue whether that is a good or bad thing, but 40(!) years of TeX and 30 years of direct edit math editors have shown that’s what people are most interested in. Readers don’t seem to have a problem understanding what the notation represents, but it is tricky for programs to do that, especially if they can’t get context from the textual environment and other expressions on the page. I suspect some sophisticated programs will get better and better at that, and so the ability to add semantic information to the presentation is something I think is important (those sophisticated programs could be run by publishers or perhaps used on the fly as a library). MathML provides for parallel markup of presentation and content, so it can handle a dual role. Perhaps a simpler mechanism of adding a (not currently supported) attribute such as “math-role” to presentation MathML would be sufficient. The devil is in the details.

Syntax is a red herring – some people have pushed for one math syntax over another because it is easier to write by hand, or it is more compact, or it is better able to manipulated by a program or on the web. Most proposals are relatively easy to convert from one form to another, although compact formats usually don’t allow for richer layout such as elementary math, spacing/positional tweaks, font and color changes, etc., nor do they typically allow for semantic specification (or vice-versa).

The real question is: who is the syntax meant to benefit. Only “insiders” actually modify raw web pages – virtually all HTML is created by some program that provides a better interface, whether it is a website design program, a full-blown document editor, a mark down language, or an email program. For this reason, I’m dubious about claims that a math markup web language needs to be human writable. For accessibility, the ability to highlight individual tokens and possibly subexpressions as such as a fraction as they are read is important. Being able to apply CSS to text has proven very popular and there is no reason to think the same shouldn’t apply for math. Hence, I tend to feel an HTML markup such as MathML is best in the web context.

CSS and Math – The Math on the Web CG has been discussing CSS “tricks” to do math layout. Some are very clever and MathJax found some clever CSS hacks also. However, it would be so much better if CSS added a few more features so that hacks weren’t needed. There really isn’t a lot that needs to be added so that CSS can be used to layout math. I’d love to see an update to both MathML and CSS so that one could use CSS on a MathML tag such as “mfrac” so that line thickness, length, color, font size and positioning of the numerator and denominator, etc., can be specified via CSS. That would allow moving some details/features in MathML to CSS where they belong. It would make the MathML spec cleaner.

Elementary math -- liamquin commented that MathML is aimed too high. I want to correct that impression: MathML 3.0 added support for elementary math. Unlike higher-level math notation, elementary math notation does vary a bit around the world and the design in MathML recognizes it. I implemented elementary math support in MathPlayer and so I can say with confidence that while supporting elementary is not trivial, it is not hard. The WIRIS editor also supports it. I can’t speak to why MathJax or other renderers haven’t added support. However, given that most of the user base long ago moved beyond elementary math, it probably isn’t surprising that most of the user base is pushing for support of other features. I’m sure textbook publishers are among those who would really like to see it supported in the MathJax, Firefox, and Safari renderers. Perhaps a little money would grease some wheels...

My bottom line wish is to see some improvements to CSS for Math and for MathML to be updated to align with those changes and CSS in general. With a bit more CSS support and a clean up of MathML, native implementations of MathML would be a lot easier.

In the meantime, accessibility support for MathML is pretty good. Even if it isn't used for display, embedding MathML in a page makes the math accessible well beyond what alt text on an image provides. For the sake of an inclusive web, please make use of it.

[clapierre]

1+ to @NSoiffer comments that accessibility support for MathML is pretty good and should be included by publishers. The DIAGRAM Center with help from @NSoiffer, @sinabahram, @GeorgeKerscher have been working on just this and will soon be testing a mathML with fallback EPUB test book we created on various reading systems with the results being recorded in https://msf.mathmlcloud.org and http://epubtest.org

[liamquin]

On Thu, 2018-04-12 at 18:48 +0000, NSoiffer wrote:

[...] Elementary math -- liamquin commented that MathML is aimed too high.

Not MathML itself - i was trying to say that giving the impression that what mattered most, or all that mattered, was research-level mathematics or even university-level mathematical notations, was making a mistake because elementary and middle-school and high-school is a massively larger market and is of course important. Sorry if i wasn't clear.

My bottom line wish is to see some improvements to CSS for Math and for MathML to be updated to align with those changes and CSS in general. With a bit more CSS support and a clean up of MathML, native implementations of MathML would be a lot easier. 100% agree.

Liam

-- Liam Quin, W3C, http://www.w3.org/People/Quin/ Staff contact for Verifiable Claims WG, SVG WG, XQuery WG Improving Web Advertising: https://www.w3.org/community/web-adv/ Personal: awesome vintage art: http://www.fromoldbooks.org/

[brewerj]

Resuming this old thread but potentially with a new focus, how can we advance MathML in a way that the potential of the spec to support accessibility is better realized? In some accessibility community brainstorming recently, we'd discussed the possibility that this topic might be a good candidate for a workshop, where people could come together to define the current state of the art, in terms of the spec itself, but also what is & isn't working in how MathML is implemented.

Relevant aspects of this could not only include advancing presentational as well as semantic aspects of how math accessibility is handled -- and what is the best path to pursue for doing that -- but also the broader topic of Math and publishing.

What are your thoughts on how we could move this area forward, potentially through a workshop and a new group?

[iherman]

I think setting up a group today would not work, for a lack of consensus on what the community needs. A Workshop may be a good idea trying to have clearer idea on how to move forward. A good representation of the CSS and, maybe, the SVG community at the Workshop would be essential, though.

[TzviyaSiegman]

I support the idea of a workshop. I think explicit invitations to SVG, CSS, and ARIA would be helpful.

[KimPatch]

I also support the idea of a workshop. It's clear that there's a big gap here. I think it's important to include speech input in the accessibility mix as well. I have some experience with speech input, accessibility and math - and how this dovetails with speech output and cognitive load - and might be able to help in this area.

[sinabahram]

I think this is a great idea and I agree that several issues such as presentation/semantics, speech input, surfacing to AT, etc. are all topics that must be explored further.

Is the following workshop on everyone's radar? Quite a number of us who have all been working on this problem as well as others in related spaces will all be there.

Web accessibility of mathematics

from May 21 to May 25, 2018.

San Jose, CA

Description:

This workshop, sponsored by AIM and the NSF, will be devoted to bringing together a diverse group of players in the field of accessibility to address the barriers that impede development and adoption of accessible web content for mathematics, particularly math education.

More details can be found at

http://aimath.org/workshops/upcoming/webmath/

take care,

Sina

President, Prime Access Consulting, Inc.

Twitter: @SinaBahram

Company Website: https://www.pac.bz https://www.pac.bz

Personal Website: https://www.sinabahram.com https://www.sinabahram.com

Blog: https://blog.SinaBahram.com https://blog.SinaBahram.com

From: Kim Patch notifications@github.com Sent: Wednesday, May 9, 2018 3:17 PM To: w3c/strategy strategy@noreply.github.com Cc: Sina Bahram sina@sinabahram.com; Mention mention@noreply.github.com Subject: Re: [w3c/strategy] Getting Math Onto Web Pages (#43)

I also support the idea of a workshop. It's clear that there's a big gap here. I think it's important to include speech input in the accessibility mix as well. I have some experience with speech input, accessibility and math how this dovetails with speech output and cognitive load, and might be able to help in this area.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/strategy/issues/43#issuecomment-387846139 , or mute the thread https://github.com/notifications/unsubscribe-auth/ABui7bzVnDwifKUShLKWtKiVyYqdLN51ks5tw0CpgaJpZM4KywhS .

[wseltzer]

@plehegar why did you move this forward?

[NSoiffer]

I believe it was moved forward because Igalia continues to move their MathML implementation (based on an evolving start to a MathML core rec) into Chrome. There are a few things such as potential new CSS properties, custom layout, and more that potentially extend beyond MathML.

There was going to be a MathML meeting in May where, among other things, we work on a charter to reestablish the MathML WG and develop a recommendation for MathML 4. Obviously, a F2F meeting won't happen in May, but I suspect we will be requesting the MathML WG be reformed sometime in the summer. If there are issues that we need to be thinking about, it would be good to know about them before we start writing a charter.

[iherman]

@NSoiffer, if you plan for a new charter, I would think you should contact the Publishing community. At the W3C, the primary access point may be the Publishing Business Group but it is also worth contacting by mail the Publishing Steering Committee (public-publishing-sc@w3.org). There are also non-W3C groups to contact, like BISG (US), BIS (UK), SNE (France), Börzenverein (DE), etc.

The publishing world has greatly suffered by the lack of MathML implementations in e-Readers as well on the Web, and having this issue solved is of a huge interest for them. Also, any further evolution should be coordinated with them: they are, potentially, major user of this and have probably lots of use cases of interest.

[wseltzer]

Thanks @NSoiffer and @iherman

To help the community evaluation, consider the guidelines linked from the top of the column. In particular, we'll be wondering about the critical mass of implementers to make the work succeed. Expressions of interest can help.

[plehegar]

@NSoiffer plan is to have a draft charter for a breakout session at TPAC 2020.

[plehegar]

We now have a proposed draft charter: https://github.com/w3c/charter-drafts/pull/295/files

[wseltzer]

Please review: https://w3c.github.io/charter-drafts/math-2020.html

[iherman]

(repeating the comments I made on https://github.com/w3c/charter-drafts/pull/295)

On the liaison statements:

• The Publishing Working Group (renamed Audiobooks Working Group, b.t.w.) is now in maintenance mode with a different scope. I am not sure it is worth listing it here.
• Instead, I would propose to add the EPUB Working Group to the list (https://www.w3.org/publishing/groups/epub-wg/). MathML is of a vital importance for the digital publishing community in general, and EPUB in particular. I would actually think it would be useful to have some sort of an ongoing relationship (try to have common WG members, for example, acting as liaisons) to ensure an active cooperation.
• I would also add the Publishing Community Group (https://www.w3.org/community/publishingcg/) to the list; that group, as a CG, does not have a strong charter control over its work, and is looking at digital publishing issues at large. MathML is a major consideration for that CG as well.

[liamquin]

On Tue, 2020-11-10 at 04:58 -0800, Wendy Seltzer wrote:

Please review: https://w3c.github.io/charter-drafts/math-2020.html

delighted to see Bert's involvement in this.

Two minor suggestions...

(1) change mission to, inclusion of mathematical notation on the Web

The difference between mathematics and mathematical notation was a major source of confusion in the past. E.g. playing audio files might be out of scope for a musicML working group, and animating equation solving or evaluating quadratics might be out of scope here. It actually follows from the rest of the document but... :)

(2)Insteaf of having changes to Content MathML entirely out of scope, state that the focus shall be on presentation MathML and that any changes to Content MathML should [not must] be limited to any changes as a result of other work, in this group or elsewhere.

Otherwise, any markup that can be used in both arguably can't be changed, and e.g. if you introduce an attribute (like aria-role) on all presentation elements you might want (or need) to add it to all content elements too for consistency.

Liam

-- Liam Quin, https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org

[r12a]

The Scope section includes the line

Enhancements and improvements to internationalization.

It's good to see this, but it's rather too vague to be able to comment on the value of that statement. I would have liked to see a line item under Other Deliverables that says something along the lines of "MathML Internationalization Requirements & Techniques". I think it would also be useful to include under the Success Criteria section a line that says that international requirements for MathML have been surveyed, documented, and specced (at least to some extent).

Without this we run the risk of producing something that is only a partial solution for many of the users around the world.

PS: This may be useful: https://www.w3.org/TR/2006/NOTE-arabic-math-20060131/

[himorin]

No further comment/request from i18n, other than @r12a (Richard)'s previous comment on adding a line for i18n to other deliverables as requirements and techniques, like math formula and/or chemistry presentation in wide variety of languages. Not adding 'i18n review completed' label for remaining request item.

[NSoiffer]

Apologies for the delay in responding to @r12a's comment --it apparently got buried in other email and I missed his comment.

The group has looked at the internationalization in some detail. MathML 3 supports RTL and we looked into math in vertical writing systems as a possible extension. See discussion in https://github.com/mathml-refresh/mathml/issues/18. Even if your eyes glaze over when looking at math, seeing some math examples (the images in the links) in vertical writing systems may be interesting to people on this thread.

Documenting that we have looked into the issue (and we may well take another look since the last look was over a year ago) is a good idea and so I will add something to the deliverables and create a PR. It would helpful to bring the examples and commentary together into a document for the next time someone wants to look into it.

[NSoiffer]

Replying to Liam's comments:

Two minor suggestions...

(1) change mission to, inclusion of mathematical notation on the Web

The difference between mathematics and mathematical notation was a major source of confusion in the past. E.g. playing audio files might be out of scope for a musicML working group, and animating equation solving or evaluating quadratics might be out of scope here. It actually follows from the rest of the document but... :)

IMHO, the line between math notation and math is fuzzy. Part of MathML Core is defining an interface for MathML elements so they can be manipulated by JS. So while we are not addressing a computation engine to solve the equation, we are allowing for JS to manipulate the equations in a manner that shows a solution. E.g., there might be a 'next step' button that when clicked highlights part of the equation and shows the next line with a highlight indicating where the highlighted part of the previous step moved to or maybe even a fancier animation that moves a subexpression from one place to another place.

Hopefully this isn't a bad analogy: HTML is not just about arranging text on a screen; MathML is not just about drawing MathML symbols on a screen either.

(2)Insteaf of having changes to Content MathML entirely out of scope, state that the focus shall be on presentation MathML and that any changes to Content MathML should [not must] be limited to any changes as a result of other work, in this group or elsewhere.

Otherwise, any markup that can be used in both arguably can't be changed, and e.g. if you introduce an attribute (like aria-role) on all presentation elements you might want (or need) to add it to all content elements too for consistency.

That is a good point. Will changing the statement to "Significant changes to Content MathML..." be a good way to convey that we might tweak a few things but we are not making design changes or planning to modify large chunks of Content MathML?

[liamquin]

On Wed, 2020-11-18 at 22:28 -0800, NSoiffer wrote:

Replying to Liam's comments:

Two minor suggestions...

(1) change mission to, inclusion of mathematical notation on the Web

The difference between mathematics and mathematical notation was a major source of confusion in the past.

IMHO, the line between math notation and math is fuzzy.

Sure. Although evaluating presentation MathML is not so easy as content MathML, but this also misses the point a little. Math on the Web includes topics such as animating graphs of functions, is much much broader than traditional notation, so i was trying to head off some of the long arguments that happened in one of the previous groups,e.g. where a participant wanted to abandon MathML and use SVG instead, by making the scope clearer.

But maybe not a big deal. I can live without the proposed change.

[...]

That is a good point. Will changing the statement to "Significant changes to Content MathML..." be a good way to convey that we might tweak a few things but we are not making design changes or planning to modify large chunks of Content MathML?

Yes, i'm fine with that, thanks.

-- Liam Quin, https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org

[NSoiffer]

Point taken that there is more to math than playing with mathematical expressions. Unifying MathML Core with the rest of the web platform will also mean we are unifying more with SVG. Potentially, this this could result in better integration between math and graphics. It's not the WG's planned focus though for this round.

[michael-n-cooper]

APA WG has no comments on this charter, and welcomes the group. Over to @brewerj to complete accessibility horizontal review.

[plehegar]

@NSoiffer , can we have https://w3c.github.io/mathml/ NOT say that this is a "W34C Working Draft"? It was never published as such on /TR and this creates confusion. It should stick to say that this is an "Editor's draft" for the time being. I'm certainly looking forward for the draft to become a Working Draft sooner rather than later.

[davidcarlisle]

@plehegar can you confirm that it's OK to use the w3c editors draft styling but say editors draft not working draft?

Specifically the fork of that spec in the MathML-Refresh Community Group github area at

https://mathml-refresh.github.io/mathml/

is converted to respec and styled as editor's draft.

If that is OK I can just push the changes back.

[samuelweiler]

Security and privacy reviews completed. No suggestions for the charter. Thank you very much for (apparently) starting from the current version of the charter template.

I'm a bit surprised to see only one chair; I prefer having at least two chairs for each group.

I'm a bit surprised to see long lists of codepoints in the docs rather than in registries. Opened an issue for the nascent WG to sort out. https://github.com/mathml-refresh/mathml/issues/238

Opened several other issues on the two docs. None are relevant to the charter. Since these are in other-than-W3C github repos, I can't directly tag them for tracking by our tools, so I'm including the list here.

https://github.com/mathml-refresh/mathml/issues/234 https://github.com/mathml-refresh/mathml/issues/235 https://github.com/mathml-refresh/mathml/issues/236 https://github.com/mathml-refresh/mathml/issues/237 https://github.com/mathml-refresh/mathml/issues/239 https://github.com/mathml-refresh/mathml/issues/240

[himorin]

From i18n, on the update by https://github.com/w3c/charter-drafts/pull/296,

i18n appreciates the inclusion of the item "Analysis of mathematical notation usage in non LTR writing systems" in the "Other Deliverables" section. However, we would like to see wording that points to analysis not only of RTL or vertical orthographies, but also symbols and conventions (if any) used in other orthographies around the world. For example, we heard mention today from a mathematician that there were (still are?) differences between the Russian and German conventions. Another possible example might be for Indian languages which draw on their Vedic traditions. We don't know whether these are valid examples of conventions that need to be acknowledged (if not expanded on) in the spec, because we don't have expertise in that area, but we'd like to at least see some research to ascertain whether W3C is neglecting some part of the world, so we would like you to look into it.

[NSoiffer]

Thanks for your comments. My memory is that the old MathML WG looked at math in India an we were told that (not surprisingly) what is used today follows standard western notations. Even Arabic math moves to LTR math by college. Speaking for myself, but I suspect the CG agrees, support for historic forms of math notation (Indian or otherwise) should not be in scope for this revision.

There are definitely differences among LTR countries, and there are many more differences for countries that don't use LTR writing systems. MathML 3 did considerable work in this regard already. It introduced RTL directionality into MathML. In addition, the MathML 3 WG outreach resulted in a few other internationalizations:

1. Russian math often breaks large expressions across lines by putting the operators at the break at both the end of the line and the start of the next line, so MathML 3 introduced a way to do this ( linebreakstyple="duplicate" https://www.w3.org/TR/MathML3/chapter3.html#presm.lbattrs). I suspect in MathML Core (Level 2), this will get migrated to a CSS property.
2. Long division looks very different around the world. MathML 3 introduced 10 different styles. https://www.w3.org/TR/MathML3/chapter3.html#presm.mlongdiv.ex 3 Even in the US, borrows and carries in 2D elementary math some parts of the country place them above the digit and other parts of the country place them to the NW of the digit. That was part of the support for elementary math introduced in MathML 3.

Around the world, there are many other notational differences, some big, some small. For example, France and Italy sometimes use "tg" instead of "tan" for the tangent. A slightly bigger difference is the open/close interval notation which in much of the world is written "(0,1]" (the numbers between 0 and 1, not including 0). InFrance, it would be written as "]0, 1]". Both of these alternate notations have always been able to be represented in MathML. The content side of MathML says nothing about how a concept is displayed and the presentational side of MathML has had support for most LTR notations for many years (now decades...). Because MathML has at least the same layout capabilities of WYSIWYG math editors and about the same as TeX's math layout capabilities, I feel pretty confident that at least for LTR, MathML is able to express all the math notations commonly now used except for some graphical ones.

I think there has been some coalescing of math layout notations among all writing systems in the last few decades because math typesetting software doesn't seem to have much support beyond horizontal writing systems. The MathML Refresh CG looked at vertical writing a year ago or so. For the most part, math was either written LTR, RTL, or LTR rotated 90 degrees. I don't think anyone in the group felt that we were done with our research and that is why we listed doing more work in the charter. We definitely have more work to do for vertical writing modes.

One issue though that can't be overlooked: getting browser support for math has been a challenge. Indeed, the MathML Core work is directly motivated by the challenge of browser support. Igalia has led the effort of getting MathML Core into Chrome and standardizing it across the other major browsers. The need to get browser support leads to a lot of pushback for adding new features unless the underlying technology stack cleanly supports the feature. So even if we uncover an i18n need, we are at the mercy of what is currently supported and also how difficult it is to adopt it to the needs of math. This extends to adding new Unicode symbols -- the old WG helped greatly expand the number of Unicode glyphs for math, but adding new glyphs takes a few years to get through the Unicode Technical Committee and then into fonts. For browsers, even the ability to stretch a parenthesis appropriately for math is tricky to fit into layout engines. If a writing system requires diagonally stretchy characters for math, that need will be noted but probably can't be added to the spec because that's not (AFAIK) supported by current browser layout engines (it's a 'width is a function of height' issue).

I hope the "we looked at this, we support most notations around the world, and we can't add more things" doesn't sound defensive or arrogant. I just mean to point out that the old WG and the current CG hasn't ignored i18n, we have embraced it. But we also have our hands tied as to what we can add in the near (proposed WG lifetime) future.

On Tue, Jan 12, 2021 at 8:46 PM himorin notifications@github.com wrote:

From i18n, on the update by w3c/charter-drafts#296 https://github.com/w3c/charter-drafts/pull/296,

i18n appreciates the inclusion of the item "Analysis of mathematical notation usage in non LTR writing systems" in the "Other Deliverables" section. However, we would like to see wording that points to analysis not only of RTL or vertical orthographies, but also symbols and conventions (if any) used in other orthographies around the world. For example, we heard mention today from a mathematician that there were (still are?) differences between the Russian and German conventions. Another possible example might be for Indian languages which draw on their Vedic traditions. We don't know whether these are valid examples of conventions that need to be acknowledged (if not expanded on) in the spec, because we don't have expertise in that area, but we'd like to at least see some research to ascertain whether W3C is neglecting some part of the world, so we would like you to look into it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/strategy/issues/43#issuecomment-759202320, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALZM3HNIL4MTZYD3YRGTJTSZUQRZANCNFSM4CWLBBJA .

[r12a]

@NSoiffer that summary is terrific. I think that if you included your previous comment (with very little change needed) into your document, perhaps under a section heading such as "MathML Internationalization", that would probably satisfy our request.

I think it's ok for historical approaches to be out of scope for the time being.

[davidcarlisle]

@samuelweiler thanks for the review,

I'm a bit surprised to see long lists of codepoints in the docs rather than in registries. Opened an issue for the nascent WG to sort out. mathml-refresh/mathml#238

Perhaps the document could make it clearer but the lists are explicit there to define the proposed text transform but the codepoints in each list come straight from Unicode so they can't be changed here, so I don't think setting up a new registry would be appropriate. The lists are specified in the math alphabet Unicode block and used for example in the existing W3C entity names REC

https://www.w3.org/TR/xml-entity-names/fraktur.html

as used in MathML3 and HTML5

is the same list as the list in mathml-core at

https://mathml-refresh.github.io/mathml-core/#fraktur-mappings

which necessarily matches the Unicode Math alphabet block at http://www.unicode.org/charts/PDF/U1D400.pdf

Opened several other issues on the two docs. None are relevant to the charter. Since these are in other-than-W3C github repos, I can't directly tag them for tracking by our tools, so I'm including the list here.

I will respond in the issues but summary responses to a couple here

mathml-refresh/mathml#234

[add a link to the github repo] The current one links to the git repo at https://w3c.github.io/mathml/ (which has the mathml-refresh one as an upstream repository and is synced manually) The WG (if it gets chartered) needs to normalise which repos we are using, having two and keeping them manually in sync isn't the long term plan.

mathml-refresh/mathml#235

[remove media type registrations] My first thought here was simply to agree, but one issue is the possible marking of the MathML3 REC as superseded or obsolete after MathML4 comes out. The media type registrations would presumably? need some stable non-obsoleted location. They could be extracted in to their own new document if that doesn't create issues with the registration. Basically I'm happy to go with whatever W3C policy is here, the current "MathML4" document is almost completely just a copy of MathML3 pending work to update it, so the fact that the current document copies the mime type registrations shouldn't be seen as an an intentional decision to repeat them.

[samuelweiler]

Oops. Two charter things after all:

• The github links in the draft charter are broken
• Does the group plan to use the "group publication status page"? If not, remove the link? (Maybe we should take this out of the template, too? See https://github.com/w3c/charter-drafts/issues/297.)

[davidcarlisle]

@samuelweiler do you mean the links in the section heads such as

<a href="#">MathML Core Level 1</a>

I suggest we simply drop the link here there are correct links to the editors drafts in the body of the section. (I can make a PR if that is what is intended)

Does the group plan to use the "group publication status page"?

That is text from the template we were asked to use for a charter. The WG doesn't of course exist yet pending charter renewal, so we have not discussed this at all. If that is in the template and a suggestion for something that WG should do I don't see any harm in us keeping the text and filling the page with sensible data, even though currently it is just an (automatically generated?) stub. If the W3C doesn't want this we can remove it before the charter is finalised, not really our call...?

[samuelweiler]

@samuelweiler do you mean the links in the section heads such as

<a href="#">MathML Core Level 1</a>

In addition to those being broken, there's a heading near the top of the charter with (broken) github links for the charter's github repo and issues on the charter. (And I don't remember which sets of those I noticed before. Sorry for being unclear.)

I suggest we simply drop the link here there are correct links to the editors drafts in the body of the section. (I can make a PR if that is what is intended)

I like also having links to the doc repos; why not just fix them?

Does the group plan to use the "group publication status page"?

That is text from the template we were asked to use for a charter. The WG doesn't of course exist yet pending charter renewal, so we have not discussed this at all. If that is in the template and a suggestion for something that WG should do I don't see any harm in us keeping the text and filling the page with sensible data, even though currently it is just an (automatically generated?) stub. If the W3C doesn't want this we can remove it before the charter is finalised, not really our call...?

It's not clear to me what WGs should do, but knowing that many groups do NOT use this, I'm encouraging the shepherd(s) for this charter to consider the question. @plehegar may have some input, and I point him at https://github.com/w3c/charter-drafts/issues/297...

[davidcarlisle]

I like also having links to the doc repos; why not just fix them?

the links to the current drafts are in the paragraph below the heading marked Draft state I can add those same links to the heading but it doesn't seem to add a lot so I thought better just to remove it, but I don't mind.

here's a heading near the top of the charter with (broken) github links for the charter's github repo and issues on the charter.

that's from the template and they are just have a relative URL of @@ I believe the intention is that W3C staff fix that to the correct URL when/if the WG is actually chartered and the document is moved from this charter-drafts repo to its allocated home. But if my understanding there is incorrect I can make a PR with this set to a real URL if I know what URL it should be.

[brewerj]

Following on Michael Cooper's accessibility horizontal review above, we welcome the specific attention to accessibility throughout this draft charter. In particular:

Increased accessibility of Presentation MathML for both mathematics and chemical formulas achieved by allowing a means of specifying relevant mathematical intent, as well as by providing guidelines for interpreting Presentation MathML in the absence of additional information.

This will help address an urgent gap in accessible online STEM curriculum and in professional use of accessible math on the web.

Separately there is a need for accessible semantic MathML. My understanding is that current circumstances do not support that additional area of focus . If any at point in the future this becomes feasible, this would be interesting to several groups in WAI.

In the meantime however, we are happy to support this proposed charter. I'm therefore marking this as 'accessibility review completed.'

[r12a]

Just a reminder that the i18n folks were hoping to widen the scope of the line in the charter that says:

Analysis of mathematical notation usage in non LTR writing systems.

to include worldwide writing systems in general, not just the RTL or vertical ones.