The
Planet MathML aggregates posts from various blogs that
concern MathML. Although it is hosted by W3C, the content of the
individual entries represent only the opinion of their respective
authors and does not reflect the position of
W3C.
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.
I mentioned in a previous post that Igalia organized the Web Engines Hackfest 2022 last week. As usual, fonts were one of the topic discussed. Dominik Röttsches presented COLRv1 color vector fonts in Chrome and OSS (transcript) and we also settled a breakout session on Tuesday morning. Because one issue raised was the availability of OpenType MATH fonts on operating systems, I believe it’s worth giving an update on the latest status…
There are only a few fonts with an OpenType
MATH table. Such fonts can be used for math layout e.g. modern
TeX engines to render LaTeX, Microsoft Office
to render
OMML or Web engines to render MathML. Three of such
fonts are interesting to consider, so I’m providing a quick
overview together with screenshots generated by XeTeX from the LaTeX
formula $${\sqrt{\sum_{n=1}^\infty
{\frac{10}{n^4}}}} = {\int_0^\infty \frac{2x dx}{e^x-1}} =
\frac{\pi^2}{3} \in {\mathbb R}$$
:
Recently, Igalia has been in touch with Myles C. Maxfield who has helped with internal discussion at Apple regarding inclusion of STIX Two Math in the list of fonts on macOS. Last week he came back to us announcing it’s now the case on all the betas of macOS 13 Ventura 🎉 ! I just tested it this morning and indeed STIX Two Math is now showing up as expected in the Font Book. Here is the rendering of the last slide of my hackfest presentation in Safari 16.0:
Obviously, this is a good news for Chromium and Firefox too. For the former, we are preparing our MathML intent-to-ship and having decent rendering on macOS by default is important. As for the latter, we could in the future finally get rid of hardcoded tables to support the deprecated STIXGeneral set.
Another interesting platform to consider for Chromium is Android. Last week, there has been new activity on the Noto fonts bug and answers seem more encouraging now… So let’s hope we can get a proper math font on Android soon!
Finally, I’m not exactly sure about the situation on Linux and it may be different for the various distributions. STIX and Latin Modern should generally be available as system packages that can be easily installed. It would be nicer if they were pre-installed by default though…
This week, I finally went back to A Coruña for the Web Engines Hackfest and internal company meetings. These were my first on-site events since the COVID-19 pandemic. After two years of non-super-exciting virtual conferences I was so glad to finally be able to meet with colleagues and other people from the Web.
Igalia has grown considerably and I finally get to know many new hires in person. Obviously, some people were still not able to travel despite the effort we put to settle strong sanitary measures. Nevertheless, our infrastructure has also improved a lot and we were able to provide remote communication during these events, in order to give people a chance to attend and participate !
Work on the Madrid–Galicia high-speed rail line finally completed last December, meaning one can now travel with fast trains between Paris - Barcelona - Madrid - A Coruña. This takes about one day and a half though and, because I’m voting for the Legislative elections in France, I had to shorten a bit my stay and miss nice social activities 😥… That’s a pity, but I’m looking forward to participating more next time!
Finally on the technical side, my main contribution was to present our upcoming plan to ship MathML in Chromium. The summary is that we are happy with this first implementation and will send the intent-to-ship next week. There are minor issues to address, but the consensus from the conversations we had with other attendees (including folks from Google and Mozilla) is that they should not be a blocker and can be refined depending on the feedback from API owners. So let’s do it and see what happens…
There is definitely a lot more to write and nice pictures to share, but it’s starting to be late here and I have a train back to Paris tomorrow. 😉
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.
Planet MathML features:
If you own a blog with a focus on MathML, and want to be added or removed from this aggregator, please get in touch with Bert Bos at bert@w3.org.