Minutes: MathML Full meeting 17 Nov, 2022

   - David Carlisle
   - Louis Maher
   - Bruce Miller
   - Bert Bos
   - Deyan Ginev
   - Steve Noble
   - David Farmer
   - Dennis Müller
   - Murray Sargent
   - Paul Libbrecht
   - Neil Soiffer
   - Sam Dooley

<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.0-rc2#cp-md-0-regrets>
Regrets
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.0-rc2#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.0-rc2#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.0-rc2#cp-md-0-2-a-href-https-github-com-w3c-mathml-core-issues-173-remove-deprecate-none-from-mathml-core-and-full-a->2.
Remove /Deprecate from MathML, core and full
<https://github.com/w3c/mathml-core/issues/173>

DC: Wants to drop None from core and full. He wants to do it before the CR.
He would like to do it now.

NS: has not checked polyfills.

NS: should write a polyfill for the "none element" if we take it out of
core.

MUS: Why is None a problem? If we remove it, we might break something.
Perhaps leave well enough alone?

DC: Core is aggressively minimalist.

MUS: Thinks we should leave it alone.

DC: It is not an unreasonable argument to say that you need None in office
products.

MUS: We could modify the writers to not use it.

MUS: If it's just a sort of an aesthetic minor improvement, it might be
better just to call it a day and just leave it.

MUS: Does not have strong feelings about removing None.

DC: We do not want to change our decision after going to CR.

DF: It is good to get rid of things you do not need.

DG: It is an element that has outlived its usefulness. If we break
something, the effect will be irrelevant.

LM: Let us get rid of it.

DC: Does anyone object to deprecating none?

SN: Does anyone know how many publishers are using it? If they are using
none, he would like to get their perspectives. He does not know if Pearson
is using it.

DC: Its main use is in multiscripts. In core, none does not do anything.

SN: Does it change anything in elementary math?

DC: None generates an empty row. It has no effect.

MUS: Sub-sup has a different placement from just super-sub, and our
renderers just mimics, TeX.

SD: When we deprecated elements in MathML3, what happens to the schemas?
Will the schemas become invalid, Or is there a way to use the schemas to
say, allow deprecated elements?

SD: I'm thinking of publishers that may have large collections of documents
that may have "nones" in their presentation.

DC: If something is deprecated, it would be removed from the core schema,
and put it back in the presentation schema. Publishers use legacy schemas
and are OK.

MUS: Checked his writer. He puts out the attribute notation None.

DC: Will remove none from core and deprecate it in the full spec.

DC: will make a pull request against the spec to remove none in some places
and deprecate it where necessary. Three repositories need updating.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.0-rc2#cp-md-0-3-neil-39-s-simplified-core-intent-list-suggestion-a-href-https-w3c-github-io-mathml-docs-minimal-intent-core-see-quot-minimal-core-quot-and-quot-defaults-quot-a->3.
Neil's simplified core intent list suggestion see "Minimal Core" and
"Defaults" <https://w3c.github.io/mathml-docs/minimal-intent-core>

NS: BM and DG had objected to superscripts being read as power in most
cases. Neil discussed adding an attribute saying that a generator will use
intent. The AT would see this attribute and would speak using intent if
this attribute were set, or the AT would use its default behavior if the
attribute was not set.

NS: discussed having this attribute have three values: defaults, common,
and structure.

BM: is concerned with a legacy document that has no intent and does not
have any assertion about the ability to default.

BM: suggests that we do not assume that a superscript is a power unless the
reader tells his/her reading agent to do so.

BM: If you do add intense, then you use intense, or if you do assert, you
can apply these default rules, you know then it could be red as power, but
the defaulting of the default thing shouldn't be power from my perspective.

NS: If you say intent equals common then superscripts are read as powers.

DG: We want to annotate a directive to AT to speak superscripts as power or
not to do that. We want to annotate, but where? In one archive that DG
examined, there were 300 million MathML elements with super script elements
where an intent would be added.

DG: It would be better to add a meta element to a document than to change
every formula in a document.

MUS: We should change document properties and not change individual
formulas. meta is good for HTML, but does it work for other scenarios?

DC: We could use JavaScript in the head to do these changes if we decided
to change all the expressions.

PL: The JavaScript polyfill modifies the dom. If you have a style attribute
early in the document, then you would save a great deal of effort changing
the document.

DC: We've got to invent a new protocol to get from one to the other, which
is not very popular.

BM: We should use the math element or some other declarative element. Do
people use standalone math expressions? It probably would not be a good
idea to use an existing html element for our purposes because it might be
used in things not html related. We must have a new element that covers
other languages.

PL: says CSS is good.

DG: Has the group considered a meta element for MathML?

DC: Getting a new element in HTML5 is unlikely.

MUS: One can have a math element initially in the document somewhere, and
all it has is a bunch of attributes specifying these document defaults.

MUS: I don't think that it would break anything, but it would allow you to
convey document math properties.

DG: use the original meta element for HTML and make a MathML element for
other non-HTML systems. Meta may have child elements that give more
information to AT.

From murrays to Everyone:
https://learn.microsoft.com/en-us/archive/blogs/murrays/default-document-math-properties

MUS: Does CSS allow just users to define CSS, or do we have to go through
their committee?

BM: Whether it's the map element, or some new declarative element that the
historical issue is that MathML is both a standalone thing, and it is
embedded in non-HTML documents.

BM: Perhaps this feature is not in the scope for MathML4.

BM: It would probably not be a good idea to get too fixated on reusing an
existing HTML element for our purposes, or necessarily even using
JavaScript or CSS.

BM: But we do need some extra MathML component where we can park this
declarative information that applies to an entire document.

DG: The group has considered an mmeta element with a little em in front of
it just for MathML.

DC: The chances for us to get a new element into the head of documents are
small.

DC: We need a definite proposal about a high-level parameter.

MUS: CSS classes are not used that much. You have a style attribute on an
element Maybe this is just in word. Have a style element on every mrow. It
seems inefficient.

DC: We should make a proposal on this. At some point, we should probably
write down a low-level document giving the properties that we want. We
should write some syntax.

DC: We have a functional form. Intent is meant to drive AT. if you put
intent in content you could put enough information to go roundtrip to
content to presentation and back. This might turn math into words for
speech. We lose what intent was used for if only the purpose of intent is
to generate speech.

DF: discussed how the J Bessel function should be spoken. It's not just a
capital J. That happens to be a function with a subscript, and so I might
call it Jay Bessel, or I might call it Bessel J. How will we coordinate so
that all people speak it the same way.

DC: This is what the list is for. This is in the open list. People can add
whatever they want to the open list.

DF: Does not want to invent notation, he wants to look it up. He does not
want people to make it up on their own.

DG: What happens when you create too many new names, and no one wants to
use them? He has an alias column when there are different names for the
same content. It would be difficult to maintain this.

We then had a discussion on the use of strings and underscores.

DG: We need a speech override option, or we will always have to wait for
the AT people to change.

The next meeting will be on December 1.