Planet MathML

I've posted up a rough agenda for the core meeting on Monday at
https://github.com/w3c/mathml-core/issues/154

It's also in the pad, please feel free to add to either and I'll see you
all Monday.


-- 
Brian Kardell :: @briankardell :: bkardell.com

On 01/08/2019 11:29, Frédéric Wang wrote:
> Hi everybody,
>
> Anyone know where one can get a collection of pages using MathML?
>
> That would be helpful to perform automate testing of MathML in Chromium
> in concrete documents to check for robustness, performance, etc
>
> There are some examples such as Wikipedia, arxiv
> (https://corpora.mathweb.org/corpus/arxmliv/tex_to_html), DLMF (
> https://dlmf.nist.gov/ ) etc However, most of them are:
>
> (1) Not appropriate for automation (e.g. not public).
>
> (2) Do not provide MathML to Chromium (or more generally browsers) by
> default, for native rendering.
>
> If anyone is interested in giving Igalia access to non-public
> collections for that purpose, please contact me.

For those who are interested, I published the script that was used in 
our downstream branch to run the collection in Blink's content_shell: 
https://github.com/fred-wang/blink-test-mathml-collections

-- 
Frédéric Wang

 We meet at our standard time on Thursday, 10am Pacific, 1pm Eastern,7pm
Central European Time.

The meeting details were sent to the W3C members-only "member-math" mailing
list <https://lists.w3.org/Archives/Member/member-math/2021May/0000.html>
for the group. The regulars for this group should have the meeting details
in their calendars.

Agenda
1. Announcements/Updates/Progress reports
   a) reminder about videos
   b) maction and MathJaX
   c) accessibility appendix

2. Potential presentation MathML items to deprecate in MathML 4
<https://github.com/w3c/mathml/issues#:~:text=Potential%20presentation%20MathML%20items%20to%20deprecate%20in%20MathML%204>

3. Resolve/close some intent issues
a) Relative paths <https://github.com/w3c/mathml/issues/252> -- resolved?
b) intent grammar -- should allow '.12' as a number
<https://github.com/w3c/mathml/issues/376>
c) intent and prefix/infix/postfix notations
<https://github.com/w3c/mathml/issues/376>
d) n-ary Intent discussion <https://github.com/w3c/mathml/issues/253>
<https://github.com/w3c/mathml/issues/253>
e) other issues?

 Attendees:

   - Louis Maher
   - Neil Soiffer
   - David Carlisle
   - Stephen Watt
   - Steve Noble
   - David Farmer
   - Bruce Miller
   - Sam Dooley
   - Cary Supalo
   - Paul Libbrecht
   - Murray Sargent

<https://sandbox.cryptpad.info/code/inner.html?ver=5.0.0-03#cp-md-0-regrets>
Regrets

   - Deyan Ginev
   - Patrick Ion

<https://sandbox.cryptpad.info/code/inner.html?ver=5.0.0-03#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

a) progress on spec

DC: Looked at chapter 3. Made a link to the spec with everything unfolded (
https://w3c.github.io/mathml/?open). He worked with the link checker.

DC: The polyfills had problems working in various browsers.

NS: will work with this. We may have to use images instead of MathML
polyfills for some.

SW: In terms of the overall design, what are we intending to do? We may
need to use images if an item is normative and polyfills are not supported
by all browsers.

NS: If we have a MathML spec, it should work with MathML.

NS: The core spec only uses images.

SW: Do we say that MathML is expected to work in the spec document?

BM: seconded SW's comments.

NS: Should we load the examples into the notes and take them out of the
spec?

NS: Who favors pulling the examples out of the full spec and putting them
into the notes? Only bm.

NS: will approve DC's PR and DC will clean it up.

NS: Igalia is going to file their "intent to ship" in Chrome (Edge) code to
support MathML.

NS: TPAC is looking for short (max two-minute) videos on technical subjects.

NS: I will do one on math accessibility showing it off so that people can
better understand what is possible.

PL: may do one on clipboards.

DC: feels that intent may need more development before it can have a video
demonstration.

NS: TPAC needs to know by July 11 if you are going to produce a video. The
video must be ready by August 26.

NS: We will talk about videos in the July 7 meeting.

NS: The videos will be collected and be available online.

b) media types FPWD?

PL: We should nudge BB on this. NS will send a note.

c) accessibility appendix

SN: Should we have only an appendix on accessibility, or should we also
have a notes document?

NS: We must get past the review. We should discuss elements that have an
accessibility problem.

NS: Should we talk about the role of ARIA on accessibility?

NS: We need to have some text to discuss.

SN: He will put all his material in the appendix. The committee will then
edit the appendix deciding on what should go into the notes document.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.0.0-03#cp-md-0-2-maction-resolution->2.
maction -- resolution?

MUS: is pushing for maction.

There was a discussion on how AT can track the motion of a cursor during
reading and editing.

NS: described a method to track the cursor without using maction.

MUS: has been shipping some of NS's ideas. MUS has not implemented this for
input.

MUS had written a blog on this in December 2020. NS asked MUS to make sure
the blog was added to the pertinent issue.

MUS: It is important to track the cursor; for example, you must know when
you are at the end of a numerator.

NS: There are IDs on every MathML element, and these IDs can be used to
give you your position.

NS Should we deprecate maction? MUS said no because of interactive
scenarios. Maction may not be used currently.

NS MathML is a superset of core. We do not have to list all the exceptions.
Say the maction element is legal, but its behavior is not defined.

NS: maction is there but its actions depends on the environment you are in.

NS: We have agreement to drop the listed actions and just say whatever is
used is implementation dependent and can be ignored if not understood.

Next week, we will go through the list of what else we want to deprecate.
We did some of this earlier, but didn't record the results. One such thing
is malign, etc.

DC: Aligning equations can be done by using tables instead of malign
attributes.

NS would like to show an intent video for TPAC.

 We meet at our standard time on Thursday, 10am Pacific, 1pm Eastern,7pm
Central European Time.

The meeting details were sent to the W3C members-only "member-math" mailing
list <https://lists.w3.org/Archives/Member/member-math/2021May/0000.html>
for the group. The regulars for this group should have the meeting details
in their calendars.

Agenda
1. Announcements/Updates/Progress reports
   a) progress on spec
   b)  media types FPWD?
   c) accessibility appendix

2. maction -- resolution?

3. deprecated MathML 3 <https://github.com/w3c/mathml/issues/304> -- need
to record decision in minutes

FYI for those thinking about attending TPAC...

---------- Forwarded message ---------
From: Alexandra Lacourba <alex@w3.org>
Date: Fri, Jun 3, 2022 at 6:33 AM
Subject: TPAC 2022 - Logistics details
To: W3C Members <w3c-ac-members@w3.org>, ab@w3.org <ab@w3.org>, <tag@w3.org>,
<chairs@w3.org>, <group-evangelists@w3.org>, <chapter-all@w3.org>
Cc: tp <w3t-tpregister@w3.org>, w3t@w3.org <w3t@w3.org>


Dear Advisory Committee Representative,
AB, TAG, Chairs,
Group participants (bcc'ed),
Evangelists and W3C Chapters,

The first logistics details about TPAC 2022 are now available at:
https://www.w3.org/2022/09/TPAC/Overview.html

---------------------------------------
Schedule
---------------------------------------

Groups have shown great interest, so we are currently finalizing the
general schedule including WG, BG, IG and CG meetings, breakout sessions,
plenary meetings, AC meeting and Developers meetup.

---------------------------------------
Registration and registration fees
---------------------------------------

Registration will open end of June 2022.

In order to ensure a good experience both for remote and in-person
participation, we are investing substantially in the audio-visual equipment.
Participation all week long will be encouraged. An Event fees for in-person
and remote attendees will apply.
Details are below:

In-person participation

   - Early Bird rate – until 31 July: *EUR 290 *[Rate limited to the 4
   first persons of a same company]
- Standard rate – until 31 August: *EUR 550*
   - Late/on-site rate – starting 1 September: *EUR 720*
   - Fee Waiver Option: No Fee (see below for more details)

Remote participation

   - Early Bird rate – until 31 July: *EUR 95 *[Rate limited to the 4 first
   persons of a same company]
   - Standard rate – until 31 August: *EUR 185*
   - Late rate – starting 1 September: *EUR 240*
   - Fee Waiver: No Fee (see below for more details)

Participation fee waiver

We understand that not everyone can afford the TPAC registration fee for a
variety of reasons and we do not want any of these to be a barrier to
participation. For this reason, we will offer an unlimited number of fee
waivers. The fee waiver operates on a trust basis, making no checks on
eligibility. If you are planning to participate in-person or remotely and
cannot afford the registration fee, please contact w3t-tpregister@w3.org to
benefit from the fee waiver.

See more details at https://www.w3.org/2022/09/TPAC/registration.html

You will find below information about in-person participation:

---------------------------------------
Accommodation
---------------------------------------

W3C has arranged a block of guest rooms for TPAC attendees at the Sheraton
Wall Centre hotel. September is a busy month in Vancouver. Hotels often
sell out by mid summer.

*Guest room rate: CA $259 plus 17.5% taxes to total CA $304*.
Group rate is available from Saturday, 7 September through Friday,
20 September and is subject to availability.

See booking method and more information at:
https://www.w3.org/2022/09/TPAC/venue.html

---------------------------------------
Health rules
---------------------------------------

As the health situation is changing rapidly, we are constantly looking at
the guidance of health authorities and government and trying to make
decisions that can accommodate all of our attendees and ensure a safe
gathering. The safety of our attendees is a priority. We will continue to
assess our health and safety rules until the event starts.

All TPAC participants are expected to comply with the health & safety
requirements.

See: https://www.w3.org/2022/09/TPAC/health.html

For any questions please contact w3t-tpregister@w3.org

Best regards,
Alexandra Lacourba
W3C Global Events Coordinator

See email below. There's an obvious video to be made about MathML in
Chrome/Edge working.

I'm thinking of one demoing what math accessibility is about (with MathCAT
of course :-). At the meeting on Thursday, if you are interested in doing a
video, let's spend a few minutes talking about it. The videos are supposed
to be very short (2 min or less). I think there is an opportunity to show
off authoring that generates 'intent' to produce better speech if anyone
wants to take that challenge on.

    Neil


---------- Forwarded message ---------
From: Dominique Hazael-Massieux <dom@w3.org>
Date: Mon, Jun 13, 2022 at 8:36 AM
Subject: [TPAC 2022] Call for Group updates and Technical Demos
To: chairs@w3.org <chairs@w3.org>
Cc: Marie-Claire Forgue <mcf@w3.org>


Dear Chairs,

As in previous years [1], Marie-Claire and I are calling for W3C groups
to produce videos that would benefit from being shared with the broader
W3C community by:
* giving updates from the groups' work
* and/or creating technical demos illustrating the latest developments
in the groups

These videos will be shared online from the TPAC website [2]. For demos
specifically, we will also organize a physical show-and-tell session
during TPAC week for demo-ers that will be physically attending TPAC.

If someone in your group is willing to record such a video:
* Please contact us with the name of the volunteer by July 11th (sooner
is better!).
* We also want a proposed title of the demo and ideally a description of
what the demo will be about.
* We would then expect to receive the recorded videos by August 26th for
publication after post-processing around beg of September.

Based on the experience, we've built a collection of best practices to
help build impactful videos:

https://www.w3.org/wiki/TPAC2021/Demos_and_Group_updates#Best_Practices_for_Recording_Videos

Many thanks for your contributions in bringing more exposure to the
import work your groups are pushing forward!

Dom

[1] https://www.w3.org/2021/10/TPAC/group-updates.html
[2] https://www.w3.org/2022/09/TPAC/

 Attendees:

   - Louis Maher
   - Neil Soiffer
   - David Carlisle
   - Cary Supalo
   - Stephen Watt
   - Sam Dooley
   - Deyan Ginev
   - Patrick Ion
   - Murray Sargent
   - Moritz Schubotz
   - Paul Libbrecht
   - Bruce Miller
   - Steve Noble

<https://sandbox.cryptpad.info/code/inner.html?ver=5.0.0-03#cp-md-0-regrets>
Regrets
<https://sandbox.cryptpad.info/code/inner.html?ver=5.0.0-03#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

NS: We did get feedback from the ARIA group. They said let MathML do what
MathML wants to do.

DG: Use ARIA as a stopgap, otherwise use MathML.

MOS: Intent is going to be used in Wikipedia.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.0.0-03#cp-md-0-2-a-href-https-w3c-github-io-mathml-docs-mathml-media-types-advance-media-types-to-fpwd-a->2.
Advance media types to FPWD
<https://w3c.github.io/mathml-docs/mathml-media-types/>?

PL: All the comments have been addressed. The references have been updated.
The document is ready to become an FPWD.

NS: Are we ready to go to the FPWD stage?

DC: The MathML spec 4 has not yet gone to the first draft stage.

NS: proposed, and DC seconded, making the Media Type document an FPWD.
Consensus to move it to FPWD.

*ACTION* NS will send BB a note to this effect.

NS: Sections 6.3 and 6.4 need work. He would like them to be smaller.

PL: We could move some of the discussion to notes. We could use folding. We
could try to go for more thinning. He does not think the content should be
thinned.

NS: Some of the examples can be eliminated.

NS: Does the CSS section in chapter 6 need updating to align with core?
<https://sandbox.cryptpad.info/code/inner.html?ver=5.0.0-03#cp-md-0-3-issues-of-the-week>3.
Issues of the week

a) Use character entity reference or character directly in spec
<https://github.com/w3c/mathml/issues/381>.

MUS: It is dramatically easier if you have the Unicode characters there.
You could add a comment if you wanted to show the actual code.

DG: We could have a JavaScript polyfill showing you whatever view you
wanted.

DC: There is a MathML 3 (non-rec) version with checkboxes to do this. We
generally do not put JavaScript code in the spec.

Conclusion: Use characters instead of character entity references.

b) Intent Grammar (recursive heads
<https://github.com/w3c/mathml/issues/380>,

floating point numbers <https://github.com/w3c/mathml/issues/376>,

DC discussed CSS numbers. They allow leading '+' along with 'e' notation.
Do we wish to allow this format?

NS: Do we allow leading decimal points?

NS: What floating point numbers should we allow?

DG: What is this for? There is a benefit in having a small grammar.

DG: Allowing multiple syntaxes for the same thing makes the spec grow, and
thus harder to understand.

DG: The decimal comma is alive and well.

DG What do we achieve by having two ways to write floating-point numbers?

SW: It is nice to allow international radix. If we cannot have a leading
decimal than we cannot have a trailing decimal.

DG: Rust and Javascript object to leading decimals points.

Let CSS figure this out and accept their spec.

SW: Do we expect intent to refer to colors in numeric syntax including
hex-based characters?

NS: No.

SW: Will intent use colors represented by numbers?

NS: We will use the color name and not the number.

BM: Some small complications with the grammar should not bother
programmers.

Most of the time when you read a number, it is in the presentation tree.

NS: sometimes you want to say .12 or 0.12.

??: Should we use ARIA for something like this?

NS: We will not be using aria to read these numbers.

PI: There will be few numbers in intent. Therefore, we can allow 0.12 or
.12; or could insist on 0.12 and even 1.0 without causing much harm.

NS: When NS worked with the Educational Testing Service (ETS), there were
AT issues about how you would speak numbers that were in scientific
notation so as not to bias the answer or make it easier or harder for a
student using AT vs a sighted user. Hence, controlling the speech for
numbers is important in that situation.

NS: NS and DG will settle this.

empty arguments <https://github.com/w3c/mathml/issues/378>).

NS: does not have a position on this issue.

DG: Showed an example of a random number generator function which did not
have arguments.

DC: We use functions that test to see if you have a license to run certain
software. Some of these functions do not have arguments.

NS: It is a small amount of work to handle this.

DG: Just wanted to make sure that there was a reason to accept functions
with empty argument lists.

The committee decided to accept functions with empty argument lists.

Intent: implicit functions allowed in function names
<https://github.com/w3c/mathml/issues/380>

NS: Arg ref let you implicitly do this. BM pointed out that it required
adding an mrow, so explicitly allowing functions in the head would be good
so remediators don't have to change the mathml.

DC: Should we add another level of parens so look ahead is not needed to
determine where the head ends?

NS: I don't like that idea. MS and I are working on intent -- let's see if
we have a problem with the implementation.

Agreement to add complex heads to intent

c) Media Types -- remove appendix and update chapter 6

NS: Get rid of the media type appendix.

d) Use images in appendix F <https://github.com/w3c/mathml/issues/383>?

DC: Is ok with dropping the images in appendix F. SD agrees.

DC will do this.

SN: will work on the accessibility appendix. The result should be in HTML.
DC will help SN put the appendix in HTML format. Our group has a Wikipedia
page describing this process


.

NS: Topics for next week: maction, location and format for known and
unknown intent

Neil, your recommendations are contained in the post MathML and OMML User Selection Attributes - Math in Office (microsoft.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevblogs.microsoft.com%2Fmath-in-office%2Fmathml-and-omml-user-selection-attributes%2F&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cb06c7b7a9caf421cc96908da4a19cf80%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637903771979916758%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cFdq%2B30hMrwD%2F51RiNNPCc%2BQuk1LxAphI%2BzEr7GslUA%3D&reserved=0>. The maction post deals with a different use: fine-grained speech specifically aimed at revealing what’s at the insertion point. A person editing a math zone needs to know the nature of the insertion point. E.g., “end of the numerator” or “start of the denominator”. This is conveyed via the selection attributes, but to get the same speech, one would have to compare the current MathML from the MathML from the previous selection.

Here's a scenario where the maction approach works better: the user enters a → key. The IP moves to the right. We want to here what’s at the new IP. We don’t want to get the whole math-zone MathML all over again. If you edit a math zone in Word with Narrator on you can hear how this works. It enables you to edit a math zone just hearing the speech, that is, without seeing the screen. That’s what we want to enable via a MathML conduit. The Word math editing experience works directly with the OfficeMath backing store and doesn’t use MathML. But we want to be able to offer ATs MathML that can be used to offer the same editing experience.

Thanks,
Murray

From: Stephen Watt <smwatt@gmail.com>
Sent: Thursday, June 9, 2022 6:13 AM
To: Neil Soiffer <soiffer@alum.mit.edu>
Cc: Murray Sargent <murrays@exchange.microsoft.com>; Paul Libbrecht <paul@hoplahup.net>; www-math@w3.org
Subject: Re: [EXTERNAL] Deprecate maction?

Neil,

You made the reasonable statement

> changing the structure of the MathML representation as you change a selection seems wrong to me

I think this depends on the editor in use.  Some will limit selections to be consistent with the mathematical structure.   Others can allow selections that aren't, for example allowing selection in text presentation order:

a b c + d e f

The editor may allow replacement of c+d with x.   I just tried this in Maple 2017 and it was allowed.

Stephen

On Thu, Jun 9, 2022 at 1:31 AM Neil Soiffer <soiffer@alum.mit.edu<mailto:soiffer@alum.mit.edu>> wrote:
Murray,

I agree that being able to communicate a selection or insertion point (a degenerative case of selection) could be useful. However, changing the structure of the MathML representation as you change a selection seems wrong to me. The math hasn't changed, just the selection. Hence, I think it makes sense to add two attributes: selection-start and selection-end (or maybe some shorter names) and add them to the start/end elements (which might be the same). My worry with my suggestion is that selections aren't unique. For example, if I had a 2d fraction '1 / 2', you could have:

  *   selection-start on the '1' and selection-end on the '2'
  *   selection-start and selection-end on the mfrac
There is an additional problem though: what if there are multiple characters in the leaf element. For example "123 / 3". Your maction idea (I think) would break the digits up, which is really drifting away from the spirit of proper MathML. For my solution to work, I have to introduce another attribute: selection-offset. For example, suppose the insertion point is after the '1', then we would have
<mfrac>
  <mn selection-start  selection-end selection-offset=1>123</mn>
  <mn>3</mn>
</mfrac>

Note: in HTML, boolean valued attributes are true if they are present and false if they are absent. Hence, I didn't give them a value in the above example.

The default value of selection-offset would be 0 when on selection-start and after the last char on selection-end.

There are a number of additional things to consider:

  1.  Are multiple selections allowed? Can they overlap?
  2.  Can a selection be part of a structure? For example, can the selection start in the middle of a numerator and end in the middle of a denominator?
  3.  What should be done if selection-end is before selection-start?
It is probably not too hard to come up with additional issues, but all of these likely can be resolved by declaring certain uses illegal and meaningless.

    Neil


On Thu, Jun 2, 2022 at 11:10 AM Murray Sargent <murrays@exchange.microsoft.com<mailto:murrays@exchange.microsoft.com>> wrote:
My blog post Editing Math using MathML for Speech | Microsoft Docs<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Farchive%2Fblogs%2Fmurrays%2Fediting-math-using-mathml-for-speech&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cb06c7b7a9caf421cc96908da4a19cf80%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637903771979916758%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iJLkNaR%2BgEPUqCv6aSNbNp4c5foeP4VUJY3gU90lXf0%3D&reserved=0> describes how <maction> could be used in generating math speech for editing math. Most MathML usage concentrates on math display, speech, braille, or computation. But creating technical documents involves editing math, so it’s worthwhile for MathML to be usable for editing. In the post, <maction> is used to produce the speech for the math at the insertion point. A related post MathML and OMML User Selection Attributes - Math in Office (microsoft.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevblogs.microsoft.com%2Fmath-in-office%2Fmathml-and-omml-user-selection-attributes%2F&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cb06c7b7a9caf421cc96908da4a19cf80%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637903771979916758%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cFdq%2B30hMrwD%2F51RiNNPCc%2BQuk1LxAphI%2BzEr7GslUA%3D&reserved=0> defines selection attributes that reveal the user selection within a math zone.

Thanks,
Murray

From: Paul Libbrecht <paul@hoplahup.net<mailto:paul@hoplahup.net>>
Sent: Tuesday, May 24, 2022 5:28 AM
To: www-math@w3.org<mailto:www-math@w3.org>
Subject: [EXTERNAL] Deprecate maction?


Dear WWW-Math mailing-list,

Within the W3C-Math-Working-Group, we have as charter to revise what was proposed in MathML3 to make it current and sharper-readable. Among the elements who appear to be candidate for a deprecation process are the maction element.

The MathML3 (current) spec says<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FMathML%2Fchapter3.html%23presm.maction&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cb06c7b7a9caf421cc96908da4a19cf80%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637903771979916758%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=b0OA4yV0OrBdoWUHDGOc%2B1u%2BLVj8bMoaPQO3Pg004CM%3D&reserved=0> that maction can be used to mark a sub-expression so that interactions of particular types can happen: toggle (switch between alternatives), statusline (show in the status-line) and tooltip (show a tooltip on top), and input (show a textfield).

It appeared to us that neither statusline nor tooltip are current and that toggle is likely of little use. Is maybe input too?
All of this can be performed in a more browser- and user-relevant fashion using javascript listeners, albeit in a less declarative fashion.

I would like, thus, to suggest to enter maction into a deprecation process: it would make this element valid (but deprecated) in MathML 4 and it would be removed in MathML 5.

What do people on this list think of this proposal?
If you have other uses of maction, is this going to be a problem and can you describe the use that you make?

Thanks in advance for your answers.

Paul

PS: implementations I know of include Safari and Firefox: they can be checked in the MathML3 test-suite: highlight<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FMath%2Ftestsuite%2Fbuild%2Fmain%2FPresentation%2FDynamicExpressions%2Fmaction%2FmactionBhigh1-full.xhtml&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cb06c7b7a9caf421cc96908da4a19cf80%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637903771979916758%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gyDKGIUEwoiiSScoUX%2FozIgjcsTrhLPVsZwEj%2FJcRJ8%3D&reserved=0>, statusline<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FMath%2Ftestsuite%2Fbuild%2Fmain%2FPresentation%2FDynamicExpressions%2Fmaction%2FmactionBstatus1-full.xhtml&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cb06c7b7a9caf421cc96908da4a19cf80%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637903771979916758%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SIy%2FkV7et9%2BsQRN6sgN94L12iu3RLrL37RbrSp5IKjk%3D&reserved=0>, toggle<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FMath%2Ftestsuite%2Fbuild%2Fmain%2FPresentation%2FDynamicExpressions%2Fmaction%2FmactionBtoggle1-full.xhtml&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cb06c7b7a9caf421cc96908da4a19cf80%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637903771979916758%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7TVMm%2FpL0VWSttPZ9Py%2FNKGxPXokrXsbYEa4NF7YuDs%3D&reserved=0>, tooltip<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FMath%2Ftestsuite%2Fbuild%2Fmain%2FPresentation%2FDynamicExpressions%2Fmaction%2FmactionBtooltip1-full.xhtml&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cb06c7b7a9caf421cc96908da4a19cf80%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637903771979916758%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oWFvsQ%2BNuGg6TTqGBYBs2jITpmaZK7WTIcgHCNAjfL8%3D&reserved=0>.

Neil,

You made the reasonable statement

> changing the structure of the MathML representation as you change a
selection seems wrong to me

I think this depends on the editor in use.  Some will limit selections to
be consistent with the mathematical structure.   Others can allow
selections that aren't, for example allowing selection in text presentation
order:

a b c + d e f

The editor may allow replacement of c+d with x.   I just tried this in
Maple 2017 and it was allowed.

Stephen

On Thu, Jun 9, 2022 at 1:31 AM Neil Soiffer <soiffer@alum.mit.edu> wrote:

> Murray,
>
> I agree that being able to communicate a selection or insertion point (a
> degenerative case of selection) could be useful. However, changing the
> structure of the MathML representation as you change a selection seems
> wrong to me. The math hasn't changed, just the selection. Hence, I think it
> makes sense to add two attributes: selection-start and selection-end (or
> maybe some shorter names) and add them to the start/end elements (which
> might be the same). My worry with my suggestion is that selections aren't
> unique. For example, if I had a 2d fraction '1 / 2', you could have:
>
>    - selection-start on the '1' and selection-end on the '2'
>    - selection-start and selection-end on the mfrac
>
> There is an additional problem though: what if there are multiple
> characters in the leaf element. For example "123 / 3". Your maction idea (I
> think) would break the digits up, which is really drifting away from the
> spirit of proper MathML. For my solution to work, I have to introduce
> another attribute: selection-offset. For example, suppose the insertion
> point is after the '1', then we would have
> <mfrac>
>   <mn selection-start  selection-end selection-offset=1>123</mn>
>   <mn>3</mn>
> </mfrac>
>
> Note: in HTML, boolean valued attributes are true if they are present and
> false if they are absent. Hence, I didn't give them a value in the above
> example.
>
> The default value of selection-offset would be 0 when on selection-start
> and after the last char on selection-end.
>
> There are a number of additional things to consider:
>
>    1. Are multiple selections allowed? Can they overlap?
>    2. Can a selection be part of a structure? For example, can the
>    selection start in the middle of a numerator and end in the middle of a
>    denominator?
>    3. What should be done if selection-end is before selection-start?
>
> It is probably not too hard to come up with additional issues, but all of
> these likely can be resolved by declaring certain uses illegal and
> meaningless.
>
>     Neil
>
>
> On Thu, Jun 2, 2022 at 11:10 AM Murray Sargent <
> murrays@exchange.microsoft.com> wrote:
>
>> My blog post Editing Math using MathML for Speech | Microsoft Docs
>> <https://docs.microsoft.com/en-us/archive/blogs/murrays/editing-math-using-mathml-for-speech>
>> describes how <maction> could be used in generating math speech for editing
>> math. Most MathML usage concentrates on math display, speech, braille, or
>> computation. But creating technical documents involves editing math, so
>> it’s worthwhile for MathML to be usable for editing. In the post, <maction>
>> is used to produce the speech for the math at the insertion point. A
>> related post MathML and OMML User Selection Attributes - Math in Office
>> (microsoft.com)
>> <https://devblogs.microsoft.com/math-in-office/mathml-and-omml-user-selection-attributes/>
>> defines selection attributes that reveal the user selection within a math
>> zone.
>>
>>
>>
>> Thanks,
>>
>> Murray
>>
>>
>>
>> *From:* Paul Libbrecht <paul@hoplahup.net>
>> *Sent:* Tuesday, May 24, 2022 5:28 AM
>> *To:* www-math@w3.org
>> *Subject:* [EXTERNAL] Deprecate maction?
>>
>>
>>
>> Dear WWW-Math mailing-list,
>>
>> Within the W3C-Math-Working-Group, we have as charter to revise what was
>> proposed in MathML3 to make it current and sharper-readable. Among the
>> elements who appear to be candidate for a deprecation process are the
>> maction element.
>>
>> The MathML3 (current) spec says
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FMathML%2Fchapter3.html%23presm.maction&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cfa3e98c7537e4341962608da3d80fa50%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637889921444449898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CrnkAi3fXk14UL3qylLdFyS7F2e%2B9m5FDBEBr1sIeH8%3D&reserved=0>
>> that maction can be used to mark a sub-expression so that interactions
>> of particular types can happen: toggle (switch between alternatives),
>> statusline (show in the status-line) and tooltip (show a tooltip on top),
>> and input (show a textfield).
>>
>> It appeared to us that neither statusline nor tooltip are current and
>> that toggle is likely of little use. Is maybe input too?
>> All of this can be performed in a more browser- and user-relevant fashion
>> using javascript listeners, albeit in a less declarative fashion.
>>
>> I would like, thus, to suggest to enter maction into a deprecation
>> process: it would make this element valid (but deprecated) in MathML 4 and
>> it would be removed in MathML 5.
>>
>> What do people on this list think of this proposal?
>> If you have other uses of maction, is this going to be a problem and can
>> you describe the use that you make?
>>
>> Thanks in advance for your answers.
>>
>> Paul
>>
>> PS: implementations I know of include Safari and Firefox: they can be
>> checked in the MathML3 test-suite: highlight
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FMath%2Ftestsuite%2Fbuild%2Fmain%2FPresentation%2FDynamicExpressions%2Fmaction%2FmactionBhigh1-full.xhtml&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cfa3e98c7537e4341962608da3d80fa50%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637889921444449898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cDizZj90IFnsZ0I3WyYvsgGGYcHzDq7cIaChC8PdN78%3D&reserved=0>,
>> statusline
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FMath%2Ftestsuite%2Fbuild%2Fmain%2FPresentation%2FDynamicExpressions%2Fmaction%2FmactionBstatus1-full.xhtml&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cfa3e98c7537e4341962608da3d80fa50%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637889921444449898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=G%2FraNh1R5fFBp%2FBYLFXanjAywzaT8NZUBaFN3CqtiZQ%3D&reserved=0>,
>> toggle
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FMath%2Ftestsuite%2Fbuild%2Fmain%2FPresentation%2FDynamicExpressions%2Fmaction%2FmactionBtoggle1-full.xhtml&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cfa3e98c7537e4341962608da3d80fa50%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637889921444449898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vuiLXE319U5%2FZJ7VATSqYtJWvJA%2Bkh%2BKmJRh%2FOTmyA0%3D&reserved=0>,
>> tooltip
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FMath%2Ftestsuite%2Fbuild%2Fmain%2FPresentation%2FDynamicExpressions%2Fmaction%2FmactionBtooltip1-full.xhtml&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cfa3e98c7537e4341962608da3d80fa50%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637889921444449898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GSTy6OHwBE%2B4Dubmd5rVE7fztfV7c82rCCXKXitDKmQ%3D&reserved=0>
>> .
>>
>

Murray,

I agree that being able to communicate a selection or insertion point (a
degenerative case of selection) could be useful. However, changing the
structure of the MathML representation as you change a selection seems
wrong to me. The math hasn't changed, just the selection. Hence, I think it
makes sense to add two attributes: selection-start and selection-end (or
maybe some shorter names) and add them to the start/end elements (which
might be the same). My worry with my suggestion is that selections aren't
unique. For example, if I had a 2d fraction '1 / 2', you could have:

   - selection-start on the '1' and selection-end on the '2'
   - selection-start and selection-end on the mfrac

There is an additional problem though: what if there are multiple
characters in the leaf element. For example "123 / 3". Your maction idea (I
think) would break the digits up, which is really drifting away from the
spirit of proper MathML. For my solution to work, I have to introduce
another attribute: selection-offset. For example, suppose the insertion
point is after the '1', then we would have
<mfrac>
  <mn selection-start  selection-end selection-offset=1>123</mn>
  <mn>3</mn>
</mfrac>

Note: in HTML, boolean valued attributes are true if they are present and
false if they are absent. Hence, I didn't give them a value in the above
example.

The default value of selection-offset would be 0 when on selection-start
and after the last char on selection-end.

There are a number of additional things to consider:

   1. Are multiple selections allowed? Can they overlap?
   2. Can a selection be part of a structure? For example, can the
   selection start in the middle of a numerator and end in the middle of a
   denominator?
   3. What should be done if selection-end is before selection-start?

It is probably not too hard to come up with additional issues, but all of
these likely can be resolved by declaring certain uses illegal and
meaningless.

    Neil


On Thu, Jun 2, 2022 at 11:10 AM Murray Sargent <
murrays@exchange.microsoft.com> wrote:

> My blog post Editing Math using MathML for Speech | Microsoft Docs
> <https://docs.microsoft.com/en-us/archive/blogs/murrays/editing-math-using-mathml-for-speech>
> describes how <maction> could be used in generating math speech for editing
> math. Most MathML usage concentrates on math display, speech, braille, or
> computation. But creating technical documents involves editing math, so
> it’s worthwhile for MathML to be usable for editing. In the post, <maction>
> is used to produce the speech for the math at the insertion point. A
> related post MathML and OMML User Selection Attributes - Math in Office
> (microsoft.com)
> <https://devblogs.microsoft.com/math-in-office/mathml-and-omml-user-selection-attributes/>
> defines selection attributes that reveal the user selection within a math
> zone.
>
>
>
> Thanks,
>
> Murray
>
>
>
> *From:* Paul Libbrecht <paul@hoplahup.net>
> *Sent:* Tuesday, May 24, 2022 5:28 AM
> *To:* www-math@w3.org
> *Subject:* [EXTERNAL] Deprecate maction?
>
>
>
> Dear WWW-Math mailing-list,
>
> Within the W3C-Math-Working-Group, we have as charter to revise what was
> proposed in MathML3 to make it current and sharper-readable. Among the
> elements who appear to be candidate for a deprecation process are the
> maction element.
>
> The MathML3 (current) spec says
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FMathML%2Fchapter3.html%23presm.maction&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cfa3e98c7537e4341962608da3d80fa50%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637889921444449898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CrnkAi3fXk14UL3qylLdFyS7F2e%2B9m5FDBEBr1sIeH8%3D&reserved=0>
> that maction can be used to mark a sub-expression so that interactions of
> particular types can happen: toggle (switch between alternatives),
> statusline (show in the status-line) and tooltip (show a tooltip on top),
> and input (show a textfield).
>
> It appeared to us that neither statusline nor tooltip are current and that
> toggle is likely of little use. Is maybe input too?
> All of this can be performed in a more browser- and user-relevant fashion
> using javascript listeners, albeit in a less declarative fashion.
>
> I would like, thus, to suggest to enter maction into a deprecation
> process: it would make this element valid (but deprecated) in MathML 4 and
> it would be removed in MathML 5.
>
> What do people on this list think of this proposal?
> If you have other uses of maction, is this going to be a problem and can
> you describe the use that you make?
>
> Thanks in advance for your answers.
>
> Paul
>
> PS: implementations I know of include Safari and Firefox: they can be
> checked in the MathML3 test-suite: highlight
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FMath%2Ftestsuite%2Fbuild%2Fmain%2FPresentation%2FDynamicExpressions%2Fmaction%2FmactionBhigh1-full.xhtml&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cfa3e98c7537e4341962608da3d80fa50%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637889921444449898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cDizZj90IFnsZ0I3WyYvsgGGYcHzDq7cIaChC8PdN78%3D&reserved=0>,
> statusline
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FMath%2Ftestsuite%2Fbuild%2Fmain%2FPresentation%2FDynamicExpressions%2Fmaction%2FmactionBstatus1-full.xhtml&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cfa3e98c7537e4341962608da3d80fa50%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637889921444449898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=G%2FraNh1R5fFBp%2FBYLFXanjAywzaT8NZUBaFN3CqtiZQ%3D&reserved=0>,
> toggle
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FMath%2Ftestsuite%2Fbuild%2Fmain%2FPresentation%2FDynamicExpressions%2Fmaction%2FmactionBtoggle1-full.xhtml&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cfa3e98c7537e4341962608da3d80fa50%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637889921444449898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vuiLXE319U5%2FZJ7VATSqYtJWvJA%2Bkh%2BKmJRh%2FOTmyA0%3D&reserved=0>,
> tooltip
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FMath%2Ftestsuite%2Fbuild%2Fmain%2FPresentation%2FDynamicExpressions%2Fmaction%2FmactionBtooltip1-full.xhtml&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cfa3e98c7537e4341962608da3d80fa50%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637889921444449898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GSTy6OHwBE%2B4Dubmd5rVE7fztfV7c82rCCXKXitDKmQ%3D&reserved=0>
> .
>

We meet at our standard time on Thursday, 10am Pacific, 1pm Eastern,7pm
Central European Time.

The meeting details were sent to the W3C members-only "member-math" mailing
list <https://lists.w3.org/Archives/Member/member-math/2021May/0000.html>
for the group. The regulars for this group should have the meeting details
in their calendars.

Agenda
1. Announcements/Updates/Progress reports

2. Advance media types to FPWD
<https://w3c.github.io/mathml-docs/mathml-media-types/>?

3. Issues of the week
   a)  Use character entity reference or character directly in spec
<https://github.com/w3c/mathml/issues/381>
   b)  Intent Grammar (recursive heads
<https://github.com/w3c/mathml/issues/380>, floating point numbers
<https://github.com/w3c/mathml/issues/376>, empty arguments
<https://github.com/w3c/mathml/issues/378>)
   c) Media Types -- remove appendix and update chapter 6
   d) Use images in appendix F <https://github.com/w3c/mathml/issues/383>?

4. maction

I hope that this week we will finally get a chance to vote on whether there
is consensus to move the media types spec to FPWD.

Please take 10 minutes to read it and note any comments/problems:
https://w3c.github.io/mathml-docs/mathml-media-types/

 Attendees:

   - Sam Dooley
   - Bert Bos
   - Steve Noble
   - Louis Maher
   - David Farmer
   - Patrick Ion
   - Stephen Watt
   - Murray Sargent
   - Paul Libbrecht

<https://sandbox.cryptpad.info/code/inner.html?ver=5.0.0-02#cp-md-0-regrets>
Regrets

   - Deyan Ginev
   - Cary Supalo
   - David Carlisle

<https://sandbox.cryptpad.info/code/inner.html?ver=5.0.0-02#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

NS: ARIA WG is has our issue (https://github.com/w3c/aria/issues/1723)
about ARIA and MathML on their agenda today

NS: Still some discussion about intent grammar (what is a number
https://github.com/w3c/mathml/issues/376, functions with no args
https://github.com/w3c/mathml/issues/378)
<https://sandbox.cryptpad.info/code/inner.html?ver=5.0.0-02#cp-md-0-1-1-deprecating-maction>1.1
Deprecating maction

PL: He requested comments on deprecating maction. He made this request on
the www-math list. He did not receive any responses.

*ACTION:* PL will request comments deprecating maction on the MathJax list.

MUS: There is more than just the web to support. How can input be handled
without maction?

NS: Can't you do this with attributes?

MUS: is "data-" in the spec?

NS: You can always add it. However, it is private to the author.

MUS: If you are doing an interactive thing, you might need maction.

MUS: wrote a blog post about this:
https://docs.microsoft.com/en-us/archive/blogs/murrays/editing-math-using-mathml-for-speech.
This post mentions some possible uses of maction for editing MathML using
speech.

MUS: should respond to the mailing list on how he wants to use maction.

NS: wants someone to comb the web to see if maction was ever used.

NS: Is there someone who has a searchable version of the web?

MUS: Someone has studied the frequency of how often certain Emojis Are used.

It might be worth asking if Google can provide a searchable web.

*ACTION* PL will ask for comments on deprecating maction on the MathJax
list, and MUS will post his input needs using maction and attributes.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.0.0-02#cp-md-0-2-continue-reviewing-the-a-href-https-w3c-github-io-mathml-mathml-4-doc-a-and-issues>2.
Continue reviewing the MathML 4 doc <https://w3c.github.io/mathml/> and
issues

SD: rewrote section 4.1

SW: asked for a discussion on the issues surrounding intent.

NS: DG is a major participant in this discussion.

NS: We might get back to the intent discussion in two weeks, depending on
where we are in spec writing.

BM: We should leave the intent discussion parked until we totally
understand what intent intends.

NS: Chapter 4 is in good shape. Chapter 3 needs work. The spec is almost
ready for editorial work.

NS It is OK if the first public working draft does not have all issues
settled.

SD: showed his rewrite of the beginning of the content chapter. People are
welcome to comment on SD's work.

SD: will delete the paragraph about coverage that NS did not like.

SD: will review the rewritten appendices F and G.

SD: is not satisfied with the titles of sections 4.2 and 4.3. He wants the
titles to do a better job of describing what those sections cover.

NS: asked people to review chapter 4, which is the content chapter.

DC: did a lot of work on chapter 4.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.0.0-02#cp-md-0-3-media-types>3.
Media types

   - Proposed rec: https://w3c.github.io/mathml-docs/mathml-media-types/
   - Issues: https://github.com/w3c/mathml-docs/issues/38
   - ]Current preview](https://w3c.github.io/mathml-docs/mathml-media-types/
   )

PL: Thanked DG for his media type comments.

NS: I just clicked through to RFC3023 and sees that it only has
Application/mathml+xml. This doc is 2001. Is there a better/more up-to-date
reference?

DC had written: 3023 is just the general foo+xml scheme, it does not get
updated for specific instances of xml media types. The currently registered
up to date reference for the 3 MathML types is the appendix in MathML3 that
this would replace. There is no corresponding +html scheme, you'd use
text/html to get html parsed 3023 MathML

NS: The rec points to the 2002 standard . This has been superseded but the
new document has not been fully approved. The 2002 standard is also not
fully approved.

NS: The document says that MathML will be added in the future. I think it
would be a good idea to include the IANA ref/link so that people can easily
find that the registration has been completed.

IANA registry:
https://www.iana.org/assignments/media-types/media-types.xhtml (currently
uses MathML3 as specification)

PL and NS came to agreement on the references.

SW: The 3023 reference is ancient. He wondered how other specs handled this
situation.

NS: looked into the SVG documents to see if they had this ancient reference
issue. He did not find anything in the short time he had during the meeting.

PL: We can reference 2033 and any follow-up references.

PL: will continue to work on the Math Type document. We will consider
voting on it next week.

NS: Does anyone expect to have objections to voting on it next week? No one
responded.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.0.0-02#cp-md-0-4-common-core-attributes-and-what-they-do-on-non-core-elements>4.
Common core attributes and what they do on non-core elements

See issue
<https://sandbox.cryptpad.info/code/(https://github.com/w3c/mathml/issues/361>
.

We have common attributes on core. What would we do about non-core
documents?

NS: What do we say about attributes in non-browser settings? Do they apply
to presentation MathML?

SW: Do we want core to be a subset of MathML 4? We still want MathML to 3
to be valid. Every core document should be valid MathML 4.

NS: event handlers may not make sense in non-browser applications. We
should say that the behavior is implementation defined. Core never says
that it is only for browsers.

BM: MathML 4 is a superset of core. There are things in MathML 4 which are
not accepted in MathML 3.

SW: If we do not know if an attribute should be accepted in full MathML,
perhaps the attribute is not designed properly.

SW: We should have a comment saying that some non-normative things are
there for completeness although they may not be used.

BM: I'm in favor of MathML 4 being a proper superset of Core. The group
seems to have agreed with this.

NS: The full MathML spec is a superset of core. we should add a paragraph
saying non browser renderers are free to do what they need to do.

*ACTION** NS: people should review chapter 4 which is the content chapter.

My blog post Editing Math using MathML for Speech | Microsoft Docs<https://docs.microsoft.com/en-us/archive/blogs/murrays/editing-math-using-mathml-for-speech> describes how <maction> could be used in generating math speech for editing math. Most MathML usage concentrates on math display, speech, braille, or computation. But creating technical documents involves editing math, so it's worthwhile for MathML to be usable for editing. In the post, <maction> is used to produce the speech for the math at the insertion point. A related post MathML and OMML User Selection Attributes - Math in Office (microsoft.com)<https://devblogs.microsoft.com/math-in-office/mathml-and-omml-user-selection-attributes/> defines selection attributes that reveal the user selection within a math zone.

Thanks,
Murray

From: Paul Libbrecht <paul@hoplahup.net>
Sent: Tuesday, May 24, 2022 5:28 AM
To: www-math@w3.org
Subject: [EXTERNAL] Deprecate maction?


Dear WWW-Math mailing-list,

Within the W3C-Math-Working-Group, we have as charter to revise what was proposed in MathML3 to make it current and sharper-readable. Among the elements who appear to be candidate for a deprecation process are the maction element.

The MathML3 (current) spec says<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FMathML%2Fchapter3.html%23presm.maction&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cfa3e98c7537e4341962608da3d80fa50%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637889921444449898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CrnkAi3fXk14UL3qylLdFyS7F2e%2B9m5FDBEBr1sIeH8%3D&reserved=0> that maction can be used to mark a sub-expression so that interactions of particular types can happen: toggle (switch between alternatives), statusline (show in the status-line) and tooltip (show a tooltip on top), and input (show a textfield).

It appeared to us that neither statusline nor tooltip are current and that toggle is likely of little use. Is maybe input too?
All of this can be performed in a more browser- and user-relevant fashion using javascript listeners, albeit in a less declarative fashion.

I would like, thus, to suggest to enter maction into a deprecation process: it would make this element valid (but deprecated) in MathML 4 and it would be removed in MathML 5.

What do people on this list think of this proposal?
If you have other uses of maction, is this going to be a problem and can you describe the use that you make?

Thanks in advance for your answers.

Paul

PS: implementations I know of include Safari and Firefox: they can be checked in the MathML3 test-suite: highlight<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FMath%2Ftestsuite%2Fbuild%2Fmain%2FPresentation%2FDynamicExpressions%2Fmaction%2FmactionBhigh1-full.xhtml&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cfa3e98c7537e4341962608da3d80fa50%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637889921444449898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cDizZj90IFnsZ0I3WyYvsgGGYcHzDq7cIaChC8PdN78%3D&reserved=0>, statusline<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FMath%2Ftestsuite%2Fbuild%2Fmain%2FPresentation%2FDynamicExpressions%2Fmaction%2FmactionBstatus1-full.xhtml&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cfa3e98c7537e4341962608da3d80fa50%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637889921444449898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=G%2FraNh1R5fFBp%2FBYLFXanjAywzaT8NZUBaFN3CqtiZQ%3D&reserved=0>, toggle<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FMath%2Ftestsuite%2Fbuild%2Fmain%2FPresentation%2FDynamicExpressions%2Fmaction%2FmactionBtoggle1-full.xhtml&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cfa3e98c7537e4341962608da3d80fa50%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637889921444449898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vuiLXE319U5%2FZJ7VATSqYtJWvJA%2Bkh%2BKmJRh%2FOTmyA0%3D&reserved=0>, tooltip<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FMath%2Ftestsuite%2Fbuild%2Fmain%2FPresentation%2FDynamicExpressions%2Fmaction%2FmactionBtooltip1-full.xhtml&data=05%7C01%7Cmurrays%40exchange.microsoft.com%7Cfa3e98c7537e4341962608da3d80fa50%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637889921444449898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GSTy6OHwBE%2B4Dubmd5rVE7fztfV7c82rCCXKXitDKmQ%3D&reserved=0>.

I forgot that we weren't able to discuss the media types issues last week,
so I've added them to the agenda.


On Wed, Jun 1, 2022 at 3:21 PM Neil Soiffer <soiffer@alum.mit.edu> wrote:

> A number of people have sent regrets. Most notably David C and Deyan.
> Since they have advocated for/against some of the recent issues on github,
> it isn't appropriate to discuss them at this meeting. Because of their
> absence, I only have one item for the agenda (it is something that David C
> raised but I don't think he needs to be part of the call to discuss it). I
> suspect this will be a short meeting.
>
> Agenda
> 1. Announcements/Updates/Progress reports
> 2. Continue reviewing the MathML 4 doc <https://w3c.github.io/mathml/>
> and issues
>     a) Common core attributes and what they do on non-core elements
> <https://github.com/w3c/mathml/issues/361>
>
>

 A number of people have sent regrets. Most notably David C and Deyan.
Since they have advocated for/against some of the recent issues on github,
it isn't appropriate to discuss them at this meeting. Because of their
absence, I only have one item for the agenda (it is something that David C
raised but I don't think he needs to be part of the call to discuss it). I
suspect this will be a short meeting.

Agenda
1. Announcements/Updates/Progress reports
2. Continue reviewing the MathML 4 doc <https://w3c.github.io/mathml/> and
issues
    a) Common core attributes and what they do on non-core elements
<https://github.com/w3c/mathml/issues/361>

 Attendees:

   - David Carlisle
   - Sam Dooley
   - Bert Bos
   - Steve Noble
   - Louis Maher
   - Deyan Ginev
   - Cary Supalo
   - David Farmer
   - Patrick Ion
   - Stephen Watt

<https://sandbox.cryptpad.info/code/inner.html?ver=4.14.1-00#cp-md-0-regrets>
Regrets

   - Bruce Miller
   - Paul Libbrecht

<https://sandbox.cryptpad.info/code/inner.html?ver=4.14.1-00#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

NS: TPAC name confusion -- there is a conference with the same name in
Vancouver at the same time.

NS: Steve and Neil had a brief conversation with Jania, the chair of APA
(Accessible platform architecture), and she is good with our approach of
using an appendix and producing a separate document for best practices for
accessibility. They produce a rec track document.

From David Carlisle to Everyone: EPUB Accessibility 1.1
<https://www.w3.org/TR/epub-a11y-11/>.

NS: Deyan pinged ARIA about our open issue (
https://github.com/w3c/aria/issues/1723). No response yet.

DC: Got a ReSpec version to have live examples using polyfills. The
polyfill output may be browser dependent.

Core is assumed to be implemented correctly in all browsers. When you get
away from core, the polyfills become unreliable.

MUS: You should know when you are reading math. When reading math, turn
your punctuation on. If you do not, things like "f(x)" will be read
incorrectly.

NS: We have not decided to leave the polyfills in or not.

Because PL is not here, we will not discuss media types. References in the
Media Type document need to be updated.
<https://sandbox.cryptpad.info/code/inner.html?ver=4.14.1-00#cp-md-0-2-continue-reviewing-the-a-href-https-w3c-github-io-mathml-mathml-4-doc-a-and-issues>2.
Continue reviewing the MathML 4 doc <https://w3c.github.io/mathml/> and
issues

a) Nailing down the intent grammar
<https://github.com/w3c/mathml/issues/252>

NS: Are positional references important?

DG: The ARG scheme is the only way to reference arguments.

NS: Do we drop numbers?

SD: Drop numeric references. Keep literal numbers.

DG: Drop the dashes or minus signs. Dashes are used to form compound words.

CONSENSUS: We will keep minus signs.

NS: hopes that internationalization will not be upset by not using decimal
commas.

DC: if we did allow them, that would be a problem because we use commas as
arg separaters.

From Patrick D F Ion to Everyone: xml - What is an xs:NCName type and when
should it be used?
<https://stackoverflow.com/questions/1631396/what-is-an-xsncname-type-and-when-should-it-be-used>

DC: What punctuation is allowed in a name?

DG: Can we agree that "-", "_", and "." are name separators for speech? For
example, "real-part".

CONSENSUS: yes.

b) Nailing down names for known/unknown intent value (previously level 1/3
and core/level 3).

NS: What are we calling things: level one and three, or core and open.

DG: supports core and open.

DG: Core should be known to all AT. He likes Open for other items not in
core.

NS: Could there be confusions with MathML core?

NS: is OK with core and open.

SD: Likes core. WE will need to say what symbols are in intent.

PI: At least 'core' does not have too many mathematical meanings.

CONSENSUS: refer to the levels as Core and Open in the recommendation.

NS: Next week we will talk about media types and core and non-core
attributes.

SD: Is proofing chapter 4. So is DC.