Planet MathML

At the end of the call, I mentioned that next week there might be a
conflict with the Digitization and E-Inclusion in Mathematics and Science
2024 (DEIMS2024) conference
<https://workshop.sciaccess.net/deims2024/DEIMS2024Program_19Dec2023.pdf>.
I checked, and the talks do not overlap with our call, although they extend
into the wee hours/early morning for those on the east coast/Europe.

Hopefully people won't be too tired to participate in the call.

    Neil

 We meet on Thursday at: 10am Pacific, 1pm Eastern, 7pm Central European Tim
*e*.

The regulars for this group should have the meeting details in their
calendars. For everyone else, the details can be found on the members-only
W3C Math WG calendar
<https://www.w3.org/events/meetings/d6f2b73d-34fc-4276-b164-bdc62a675dcc/20230713T130000/>.


Agenda
1. Announcements/Updates/Progress reports
2. Core concept list updates
<https://w3c.github.io/mathml-docs/intent-core-concepts/>
       i. Deyan's original spreadsheet
<https://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit#gid=1358098730>
(done)
       ii. David F's wish list
<https://docs.google.com/spreadsheets/d/1cLPaIy9kX5K-67RG6rjSAXErDSB-_iYmgZaTKQjShVg/edit#gid=0>
(done)
       iii. Deyan's Physics list
<https://gist.github.com/dginev/825078ae316c32c312436f42061b3d05> and Chemistry
list <https://gist.github.com/dginev/ff7e6e090b79a0389fc2eff2b9961331>, Biology
List, <https://gist.github.com/dginev/d6367f53cb7b1fbed8abfa6bddd4f2c0> Earth
Science and Engineering
<https://gist.github.com/dginev/cec6eb44f8c3fdffbffe546448049981> (finished
first part of physics list)
       iv: Neil's MathCAT intent list and MathPlayer's rules list (subject
area inferences <https://github.com/w3c/mathml/issues/476>, units
<https://github.com/w3c/mathml/issues/475>)
3. Derivatives (first, higher order, different notations):[473
<https://github.com/w3c/mathml/issues/473>]

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - David Farmer
   - Patrick Ion
   - Deyan Ginev
   - Cary Supalo
   - Murray Sargent
   - Paul Libbrecht
   - Stephen Watt
   - Bert Bos

<https://sandbox.cryptpad.info/code/inner.html?ver=5.7.0-rc1#cp-md-0-introduction>
Introduction

This week we will devote two hours to a topic that has reared its head
several times and one that we still need to resolve conflicts in: concept
names.

There is a tension between concept names wanting to speak in a natural way
(which can lead to idiosyncratic names) and concept names being less ad-hoc
so that they follow some naming convention based on the concept they
represent (encyclopedic name).

This conflict sometimes shows itself in names for the Unicode characters
also. For example, "ellipsis" vs "dot-dot-dot" or maybe even "equals" vs
"equals-sign".

The naming problem is less of an issue for core concepts because AT can
speak to them as they see fit since they can know how the concept might be
spoken, but for open concepts, that ability is not likely present. We
agreed core and open should follow similar if not identical naming rules
because open concepts potentially will migrate into core. Also, some AT may
not implement all of core, so the speech issues for open are potentially
present for core.

One more facet related to naming: fixity properties. We have function
(default), prefix, infix, postfix, and silent. My belief is we need a few
more to allow for more natural speech in some cases, but I don't think
everyone shares that opinion. To throw out what is certainly a wild idea:
we could add a matchfix property that takes everything before the first "_"
or "-" (or both) and speaks it first and speaks the remainder after the
last item (e.g., "open-close" for parens). This potentially extends to a
notation with multiple "-"/"_" and multiple arguments. Of course, literals
can also be used, but that removes freedom from AT.

Apologies for any prejudice I may have shown in the above description of
the problem. We hopefully will have time to thoroughly discuss multiple
ideas related to naming during the call. This is a difficult topic to solve
(IMHO), but I hope we can at least make some significant progress towards a
solution even if we don't reach a final solution.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.7.0-rc1#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=5.7.0-rc1#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

NS: reports that BK has started the horizontal review as part of the CR
process.

DG writes: Following active encouragement, the group tried to pitch a small
Interop 2024 issue on MathML+CSS back in October:
https://github.com/web-platform-tests/interop/issues/556

With 65 netizens taking time from their busy days to upvote the issue and
indicate MathML has continued relevance.

And today we were officially ignored:
https://webkit.org/blog/14955/the-web-just-gets-better-with-interop/

NS: DF has done work on intent.

DF: wants to create a new markup language for math called Space Math using
ideas from Python and LaTeX. It's like writing math as a plain text email.

DF has shared a demo with NS.

NS: MuS is doing something similar except he is relying on people to be
able to enter Unicode.

MuS: Well, I made some significant progress. I've written a converter from
MathML back to Unicode Math. Since Unicode math and speech are similar, I
wrote a translator that converts MathML back into speech. I have a pretty
good implementation already. It is nice to have a public JavaScript
implementation that takes MathML and speaks it.

DG: From Deyan Ginev to Everyone: Moritz has a new preprint out documenting
their MathML Intent work in Wikipedia: https://arxiv.org/abs/2401.16786v1
<https://sandbox.cryptpad.info/code/inner.html?ver=5.7.0-rc1#cp-md-0-2-concept-names>2.
Concept names

NS: What is a concept name? Is it the way someone speaks it, or does it
represent the semantic (encyclopedic) name?

DG: Our big challenge is that we have a lot of notation that needs
accessibility treatment. This treatment may require a concept or keyword.
It is hard to select a lot of keywords without a guiding principle.

DG: To keep the spec simple, you need an organizing keyword naming
principle. If the core list has 100-200 items, we do not need an organizing
principle. If you want an open list that might have ten thousand items, you
need an organizing naming principle.

DG: Your principle should also give you guidance on the structure of the
application such as the order of the arguments.

DG: One principle is to use the encyclopedic name that everyone knows.

DG: People want us to keep intents simple.

DG: If we must decide every time about how prepositions are used, it
becomes hard to make the naming decisions.

DG said that BM suggested that the lists are more trouble than they are
worth. BM suggested just having a generic naming principle!

NS: There are 223 concepts already.

DC said he was all right not having a system for naming things.

DC assumed that anything in the open list will be read as is.

NS: We will probably adopt open names. It is not good to have different
ways to think up names for core and open. The names should be speakable and
understandable as spoken.

NS: "By" has the concept name of dimension. This is not how English
speakers would use it.

NS: "By" may work for a cross, but it might not work for an mrow.

DC: If there is a core concept, we can have a speech template.

NS: By being in core, these are the names we should use, and consumers
should expect to hear them. We must have a translation to other languages.

NS: By default, everything is spoken as a function. We have fixity names to
make things sound OK. Maybe we should use fixity in more cases.

PL: What does it mean to solve the issues? We have two solutions. One is to
have a strategy for naming things that can be used in open and core. The
other solution is to do what is convenient in open knowing that open is
open.

PL: We should aim at something that is speakable if it is understandable,
or except encyclopedic names.

NS: In the core list, it should have an encyclopedia name with a note to
say how it should be spoken.

PL: discussed the case of times in French.

SW: One of the things we discussed is that the first time we read a term,
we may use a long name. After the first time, we may use a terser name. Can
the AT be trained to do this?

NS: The core list should have a concept name and a speech hint or template
to give a more detailed reading.

NS: Should it be that the first time the AT reads a term, the AT should
read a long term followed by using a shorter term, or should the author
have to do this?

NS: Should the author control whether the AT reads a long or short
description?

NS: says that the reader generally selects whether he wants the AT to give
a long description or a terse description.

MuS: should you have a hot key asking for a full explanation of a term?

NS: MathCAT has terse and verbose readings upon user request. The AT does
not do this automatically.

DF: Authors would not be able to figure this out. The AT is the only way
for the reader to get what is needed.

MuS The reader will find a couple of good ATs to do this. You cannot get
authors to do this.

PL: Thought that authors could handle speech output. If we had a property,
then it would be useful.

PI: I do not have the experience of what the blind need to hear. Screen
reader authors do have this experience.

NS: Authors cannot know what the audience wants. Move the speech control as
close to the audience as possible.

DG: If we get a core backbone reading capability in MathML4, we can enhance
it in MathML5.

DG: It's easier to ask for a brief readout of something I know than it is
to ask for a long description of something I do not know. If you want to go
in both directions, you will have to provide more meaningful names.

NS: It's easier to look at a long name and come up with a short name than
vice versa.

DC: We do not have any way in the spec of providing two names in the
syntax. There is no fallback except to read the notation literally, like J0
for a Bessel function.

DC: We decided not to require different levels of verbosity.

DC: We cannot redo the basic intent design.

MuS: talked about the digital library of mathematical functions. A lot of
work has been done to provide background information. You can hover your
mouse over something, and you receive more information about that object,
so perhaps part of what we want to do isn't going to be done by intent at
all.

SW: Much of our mathematical notation is written in shorthand so we can
capture as much detail as possible at a glance. It may not be well-suited
for speech. We need to give enough information to be understood. He likes
encyclopedic names if the speech can be made terse.

SW: The way things are laid out usually may guide the speech explanation of
it.

MuS: Trying to force it all on intent may not be good. There are other
attributes like title which might help.

SW: We need an organized scheme to help name things, and we need a method
to shorten the reading when desired.

DG: We must annotate individual formulas. Things fit better as a global
implementation so you do not have to annotate it every time it is used. You
do want to have it spoken hundreds of times. You want a global intent, so
the author does not have to write it every time it is used.

DG: There should be a table that would help everyone speak the same things
identically. This would be an open list that everyone could use.

NS: It would be good to have a column in an open list that would give
computer guidance on how an intent should be spoken.

NS: wants to focus on the naming topic to get a concrete solution to help
name remaining concepts.

DG: He has a different point of view. It is more valuable to have a
systematic method to generate many names than it is to have a series of
names.

If you have names in a systematized system you can build what you need. Our
default position is to just read what is there.

DG: We can gradually implement enough important concepts from the open list
to grow at least to bachelor level, maybe when the early master's level
concepts.

NS: what do you mean by implementing the open list?

DG: It's funny you would ask that because you've done this for core. Do the
exact same thing for concepts that are not in core but are in the open list
that need special treatment.

DG: If you have an interval that is not an open interval, but is something
like an extended conjugated interval of something, you will just change the
function name, but you will still use the form to Construction for the
application. If you're doing it completely symbolically with classical
linguistic methods, you would have a dictionary of little symbolic
constructs that build phrases up with different prepositions in different
connector words.

From Patrick D F Ion to Everyone: Is there a YouTube, or other record of
someone reading out math as a screen reader client? I remain very ignorant
of what the target audience for screen reading might appreciate.

DF: Talk about dimension which is "by". It must be in core. Say m by n
matrix. The intent dimension is not the best name according to DF. If AT
knows about core and the intent that is dimension, then AT will call it by.
Then he could accept dimension.

NS: He will take the MathCAT list and do the best job to read intents. He
cannot say what Apple would do. They may use the very basics (read the
syntax) and just read the words used for intent.

DF: What is the point of making intent if they do not implement it? Why
have a standard if any product doesn't follow the core descriptions?

NS: In MathML history, they added two ideas alt text and alt image to make
it trivial to support MathML. No one bothered to do that.

NS is worried about putting more load on developers.

DC: what does it mean for arXiv to implement a list.

DC: We should not have a common naming system for both core and open. If
it's in core, people should implement it. If it is open, they do what is
reasonable, like using by instead of dimension. If a name changes when it
goes to core, then so be it.

You should not put up with a suboptimal description of matrices because it
might get to core one day.

NS: Then is it a concept or literal?

DC: It is a concept.

DC: The only way to get many systems to read the same is to have a concept
name that is followed.

DC: Believes in making up concept names as you go along. It's still a
concept if it is a function.

DG: Literals are designed to control exact speech. The bigger threat is
that people do not use the spec at all. If I do not like the design of the
spec, then just use another system, and ignore the spec. The spec must be
compelling.

NS: Wants a name that can be spoken well when used with fixity, so you get
a good reading even with an open name.

DC: If arXiv decided to put in ten millions of intents, then they will be
spoken by a default reader. The reader does not implement these names.

DG: The point of openness is so that systems going beyond core have some
place to go.

NS: There are 2 authors. There's the authoring software and there's the
author who's writing the document.

DC: But neither has any control over the reader which is what matters here.

Ns: If we have something that is complicated to implement, people will not
use it. Err on the side of simplicity. It still must provide a good reading
experience.

NS: The names in core are almost irrelevant because you have a dictionary
that looks up the names.

PL: We need a column for the core for a speech template to accompany the
concept name.

NS: By having the speech template, the concept name does not have to be
spoken so we can use the encyclopedic name.

SW: Maybe we do not need a speech template, the name of the argument is
fine. Do something lightweight where something following a colon is
ignored. After the colon is how you prefer it to be spoken.

NS: Magnitude does not have a template because it is simple enough. Other
terms need a template if they are more complicated.

SW: The discussion is if someone does not give a speech template, what do
you do? Give systematic names for the concepts that can be spoken.

DC: These speech templates have no MathML semantics.

If the names are not in core you can suggest speech, if not you cannot do
anything in MathML.

NS: You can force them to speak with literals. This is not using a concept
name.

DC: We cannot change the intent syntax and get it out this year.

NS: You can use a concept name, followed by silent, followed with literals.

From Deyan Ginev to Everyone: Is the suggestion to have literal properties
suggesting speech?

intent="dimension:by"

From Deyan Ginev to Everyone: that seems to abbreviate the existing
solution:

intent="dimension:silent(_by)"

This could bypass the concept name.

PL: What is the implementation problem? We say how we can pronounce the
concept name without a template. If there is a problem, use a speech
template. We do not want to have a template for all cases.

SW: It is not completely implementable.

NS: DG may be happy because we should push towards encyclopedic names in
core because it is a dictionary look up to make better speech.

PL: We want to avoid a speech template and use a name that is expressive
enough.

PL: We want to avoid, if possible, putting a speech template and keep a
name that is pronounceable for some of these things.

NS: There seems to be some agreement that we should be pushing towards
encyclopedic names in the core list to be used because it's just simply a
table lookup to a dictionary.

NS: What is an example?

PL: tangent instead of tan.

DC: Encyclopedic may not be good because two encyclopedias may have
different descriptions for the same name.

DG: wrote a note on this subject (
https://w3c.github.io/mathml-docs/concept-lists/). The idea there was that
he would just read it. Each core list concept is represented by its English
encyclopedic name.

DG: There is a clear line where language starts and STEM starts, and
there's a grey zone where they overlap a little, and there you can choose
the most pleasing, speakable concept names.

*Summary* NS: We will use encyclopedic names that are well known that may
not be good for speech in the core list. There will be a speech template
column which may use different names.

DF: The value of the intent is an encyclopedic name accept when there is a
well-known name like max ... Encyclopedic names backed up by speech
templates.

DC recommends the Open Concept List as a reference source.
https://w3c.github.io/mathml-docs/intent-open-concepts/

NS: You would say that this is a good list to start building a core and an
open list.

DG: Notice that intent is becoming increasingly relying on speech hints.

DG: The speech hints are now crucial in 2 different ways. One is that any
time the encyclopedic name is uncomfortable you must have as hints to
rescue the user experience of that intent value, and the second is the
argument order of intent described applications are pretty much determined
by the way the speech hint is written in the list.

NS: The speech templates are hints, not requirements.

DG: Presentation MathML specifies the order of the arguments.

DC: This is only for simple cases like fractions. You cannot say anything
about an arbitrary function.

DC: If you do not know what the function is, you cannot say what the
arguments are. If you know the arguments, you can know the order.

DG: In practice, while we cannot mandate anything, the speech hints give an
anticipation of the order.

DG: Sometimes the order is obvious, but it may not be for other languages.

next week, we will not due chemistry because CS is gone.

NS: We will work on properties list or finish off the rest of the list.

NS wants a session on units. We will talk about units in a week or so.

NS: Let us finish the lists we have.

Today we can put a bow on this www-math thread.

Following active encouragement, the group tried to pitch a small Interop
2024 issue on MathML+CSS back in October:
https://github.com/web-platform-tests/interop/issues/556

With 65 netizens taking time from their busy days to upvote the issue and
indicate MathML has continued relevance.

And today we were officially ignored:
https://webkit.org/blog/14955/the-web-just-gets-better-with-interop/

Then again, JPEG XL was also shelved, and they even pleaded in song:
https://www.youtube.com/watch?v=VJaa1Le4W7c

Better luck next time?

Greetings,
Deyan


On Wed, Sep 27, 2023 at 6:57 PM Brian Kardell <bkardell@gmail.com> wrote:

> It does seem that it would be harder to claim that it is important and
> should be paid attention to and prioritized if  - when the vendors say
> "here we are, what do you need?" we get like 180 submissions and none of
> them are about MathML-Core interop.  How would you see it?
>
>
>
> On Wed, Sep 27, 2023 at 6:51 PM Neil Soiffer <soiffer@alum.mit.edu> wrote:
>
>> I plan on having this on the agenda for Thursday.
>>
>> @Brian: is it at all helpful if we identify the problems caused by the
>> lack of interop? Or is a more positive "this is what it enables" tone
>> better?
>>
>>     Neil
>>
>>
>> On Wed, Sep 27, 2023 at 3:27 PM Deyan Ginev <deyan.ginev@gmail.com>
>> wrote:
>>
>>> Hi Brian,
>>>
>>> Yes, "interop" is a great mechanism. But browser vendors don't care what
>>> is "important to me" - they didn't in 2013, and they still don't today.
>>>
>>> The realistic question in my mind is what needs to be strategically
>>> accomplished/prepared by the WG for an interop request to succeed in
>>> September 2024 (or 2025, or 2026...).
>>> Securing funding and recruiting browser representatives to join the Math
>>> WG are indeed highly impactful (and high difficulty).
>>>
>>> To quote your own words (which I agree with):
>>> "We are very likely to face the same thing that we faced last year: that
>>> math is no one's priority."
>>>
>>> (minuted at
>>> https://github.com/w3c/mathml-core/issues/206#issuecomment-1736177722 )
>>>
>>> I would certainly support a group vote that selects a small MathML
>>> implementation issue, with very narrow technical scope, which we then
>>> collectively offer for "interop" consideration.
>>> I suspect it still won't be picked up, but at least we'll maximize our
>>> chances if we suggest something that looks really painless to fix.
>>>
>>> Deyan
>>>
>>>
>>> On Wed, Sep 27, 2023 at 4:41 PM Brian Kardell <bkardell@gmail.com>
>>> wrote:
>>>
>>>> Interop is the single best venue you have to make a case to all of the
>>>> vendors at once that something is important to you.  Not only that, but new
>>>> stuff + interop are taking priorities so getting something beyond those is
>>>> extra hard unless we find someone to fund the work - which, while we have
>>>> done it thanks to a few sources -  seems to have limits for math :)
>>>>
>>>>
>>>>
>>>> On Mon, Sep 18, 2023 at 10:51 AM Deyan Ginev <deyan.ginev@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Neil, all,
>>>>>
>>>>> Is the interop effort a good place for Math WG members to
>>>>> independently start filing new issues? I am a little hesitant, myself.
>>>>>
>>>>> Wouldn't it make more sense to first see if we have buy-in from the
>>>>> respective browser vendors (and meet any conditions to gain that)?
>>>>> Once we hear back a "soft yes" from the right vendors, we could file
>>>>> an interop issue to make things official.
>>>>> Experience seems to show that "cold outreach" requests don't move the
>>>>> needle too much in MathML browser land.
>>>>>
>>>>> I can certainly imagine making CSS support for MathML Core a public
>>>>> "implementation priority" for the Math WG, where we do enough liaison work
>>>>> to have backing for a small number of features to gain parity.
>>>>> At which point there may be a then-successful interop issue for 2025
>>>>> (or 2026,...)
>>>>>
>>>>> Just thinking out loud,
>>>>> Deyan
>>>>>
>>>>>
>>>>> On Mon, Sep 18, 2023 at 1:23 AM Neil Soiffer <soiffer@alum.mit.edu>
>>>>> wrote:
>>>>>
>>>>>> To give a little context to Brian's message, the interop effort is an
>>>>>> effort to make browsers behave the same/have the same features so
>>>>>> developers can count on a feature working in all main browsers when they
>>>>>> use the feature.
>>>>>>
>>>>>> MathML core has some significant features missing from Webkit/Safari
>>>>>> and Gecko/Firefox. This means that you can't really use a number of
>>>>>> features in MathML core. For example, you can't use CSS with MathML in
>>>>>> Safari or Firefox. This is a major frustration for me as a MathML full
>>>>>> polyfill author because I can't do some of the polyfills without having to
>>>>>> target each browser separately. I know I've seen others complain about this
>>>>>> and other issues.
>>>>>>
>>>>>> This is your chance to make the case for why some of the top
>>>>>> implementers in the browser world should concentrate on some feature. As
>>>>>> Brian has said more than once, there are A LOT of things outside of math
>>>>>> that need attention. We need to make a little noise if we are ever going to
>>>>>> get some math features to rise to the level of even being considered. If
>>>>>> you have bumped your head into some cross-platform issue with MathML Core,
>>>>>> say something by filing a Focus Area Proposal issue. The odds of it getting
>>>>>> addressed are not high, but the odds are zero if you don't file an issue.
>>>>>>
>>>>>>     Neil
>>>>>>
>>>>>>
>>>>>> On Fri, Sep 15, 2023 at 11:11 PM Brian Kardell <bkardell@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Is now open:
>>>>>>> https://github.com/web-platform-tests/interop/issues/new/choose
>>>>>>>
>>>>>>> The core group had requested i let them know when it was.
>>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Brian Kardell :: @briankardell :: bkardell.com
>>>>
>>>
>
> --
> Brian Kardell :: @briankardell :: bkardell.com
>

 We meet on Thursday at: 10am Pacific, 1pm Eastern, 7pm Central European Tim
*e*. The meeting will *end *at noon Pacific, 3pm Eastern, 9pm CET.
Apologies to those who will be working late.

The regulars for this group should have the meeting details in their
calendars. For everyone else, the details can be found on the members-only
W3C Math WG calendar
<https://www.w3.org/events/meetings/d6f2b73d-34fc-4276-b164-bdc62a675dcc/20230713T130000/>
.

This week we will devote two hours to a topic that has reared its head
several times and one that we still need to resolve conflicts in: concept
names.

There is a tension between concept names wanting to speak in a natural way
(which can lead to idiosyncratic names) and concept names being less ad-hoc
so that they follow some naming convention based on the concept they
represent (encyclopedic name).

This conflict sometimes shows itself in names for the unicode characters
also. For example "ellipsis" vs "dot-dot-dot" or maybe even "equals" vs
"equals-sign".

The naming problem is less of an issue for core concepts because AT can
speak them as they see fit since they can know how the concept might be
spoken, but for open concepts, that ability is not likely present. I think
we agreed core and open should follow similar if not identical naming rules
because open concepts potentially will migrate into core. Also, some AT may
not implement all of core, so the speech issues for open are potentially
present for core.

One more facet related to naming: fixity properties. We have function
(default), prefix, infix, postfix, and silent. My belief is we need a few
more to allow for more natural speech in some cases, but I don't think
everyone shares that opinion. To throw out what is certainly a wild idea:
we could add a matchfix property that takes everything before the first "_"
or "-" (or both) and speaks it first, and speaks the remainder after the
last item (e.g, "open-close" for parens). This potentially extends to a
notation with multiple "-"/"_" and multiple arguments. Of course literals
can also be used, but that removes freedom from AT.

Apologies for any prejudice I may have shown in the above description of
the problem. We hopefully will have time to thoroughly discuss multiple
ideas related to naming during the call. This is a difficult topic to solve
(IMHO), but I hope we can at least make some significant progress towards a
solution even if we don't reach a final solution.

Agenda
1. Announcements/Updates/Progress reports
2. Concept names

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Murray Sargent
   - David Farmer
   - Moritz Schubotz
   - Patrick Ion
   - Bruce Miller
   - Cary Supalo
   - Dennis Müller
   - Deyan Ginev
   - Bert Bos

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

   - Paul Libbrecht

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

Next week, February 1, 2024, will be a two-hour meeting to discuss concept
naming.

The W3C is having a conference in April. They asked for contributions. NS
did not think our group had anything ready at this time. If anyone is
interested in preparing a talk for the conference, let NS know, and he will
forward the conference announcement. Once there is a conference agenda, NS
will let us know.

DC: I'm making progress with getting PDF readers to read MathML.

After the meeting, NS wrote: The 5th International Workshop on
"Digitization and E-Inclusion in Mathematics and Science 2024" (DEIMS2024)
15-17 February 2024, at Nihon University, Tokyo, Japan There are several
papers that might be of interest to members. Registration for remote
attendance is free, but you are supposed to register. The procedure to
register is here
<https://workshop.sciaccess.net/deims2024/registration.html>. The program
is here <https://workshop.sciaccess.net/deims2024/program.html>. Times are
UTC + 9 hours.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.7.0-rc1#cp-md-0-2-newly-opened-issues->2.
Newly opened issues:
<https://sandbox.cryptpad.info/code/inner.html?ver=5.7.0-rc1#cp-md-0--a-href-https-github-com-w3c-mathml-issues-486-intent-for-quot-by-quot-as-in-3-4-matrix-486-a->Intent
for "by" (as in 3×4 matrix) (#486)
<https://github.com/w3c/mathml/issues/486>
<https://sandbox.cryptpad.info/code/inner.html?ver=5.7.0-rc1#cp-md-0--a-href-https-github-com-w3c-mathml-issues-487-non-math-intents-487-a->Non-math
intents (#487) <https://github.com/w3c/mathml/issues/487>

DF Came up with the physics related terms of Center-of-mass-of and
antiparticle-of to go into the Non-math intents list in issue 487. We will
revisit this list and see which of these Non-math terms should be concepts.

NS has added the categories of physics, chemistry, and biology. He suggests
that people might want to add other categories.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.7.0-rc1#cp-md-0-3-a-href-https-github-com-w3c-mathml-issues-482-large-operators-482-a-integral-sum-union-etc-max-5-minutes>3
Large operators (482) <https://github.com/w3c/mathml/issues/482> (integral,
sum, union, etc.): max 5 minutes

NS: Any new ideas? These symbols are not ambiguous, so naming them is not a
big deal, but we probably need to list them.

MuS agreed that we should list them.

NS: We do have to account whether they have one or two variables, such as
integrating over a domain, or over a range.

DF: There also might be operators that people are not familiar with such as
a plus with a circle around it which could stand for a direct sum.

NS: There could be a large operator for that.

DF: You might not want to pronounce it as a plus with a circle around it.

NS: Did not think that plus with a circle around it is in core.

MuS: There are at least nine large integral signs. There are many large
operators.

NS: How do we name them? The large operators all follow the same pattern.
They could be in a list and not separate concepts.

MuS: For example, ∫_-∞^∞ 𝑒^-𝑥² ⅆ𝑥=√𝜋 gets the intents

We had a discussion on MathML properties that get inherited upwards such as
integration limits.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.7.0-rc1#cp-md-0-4-a-href-https-w3c-github-io-mathml-docs-intent-core-concepts-core-concept-list-updates-a->4.
Core concept list updates
<https://w3c.github.io/mathml-docs/intent-core-concepts/>
<https://sandbox.cryptpad.info/code/inner.html?ver=5.7.0-rc1#cp-md-0-i-a-href-https-docs-google-com-spreadsheets-d-1eswou1k5nxbdlpvqapdoa9h-s8lg_qjn8fjh64g9izq-edit-gid-1358098730-deyan-39-s-original-spreadsheet-a->i.
Deyan's original spreadsheet
<https://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit#gid=1358098730>

(done)
<https://sandbox.cryptpad.info/code/inner.html?ver=5.7.0-rc1#cp-md-0-ii-a-href-https-docs-google-com-spreadsheets-d-1clpaiy9kx5k-67rg6rjsaxerdsb-_iymgzatkqjshvg-edit-gid-0-david-f-39-s-wish-list-a->ii.
David F's wish list
<https://docs.google.com/spreadsheets/d/1cLPaIy9kX5K-67RG6rjSAXErDSB-_iYmgZaTKQjShVg/edit#gid=0>

(done)
<https://sandbox.cryptpad.info/code/inner.html?ver=5.7.0-rc1#cp-md-0-iii-a-href-https-gist-github-com-dginev-825078ae316c32c312436f42061b3d05-deyan-39-s-physics-list-a-and-a-href-https-gist-github-com-dginev-ff7e6e090b79a0389fc2eff2b9961331-chemistry-list-a-and>iii.
Deyan's Physics list
<https://gist.github.com/dginev/825078ae316c32c312436f42061b3d05> and Chemistry
list <https://gist.github.com/dginev/ff7e6e090b79a0389fc2eff2b9961331> and

Biology List
<https://gist.github.com/dginev/d6367f53cb7b1fbed8abfa6bddd4f2c0> (finished
first part of physics list) We began in the Misc section with separators
which we do not need to add.

We next considered the arrows. some uses of ↔ and → which had unclear
terminology, used in physics relationships ◦ would have been equilibrium
and yields in chemistry ◦ or potentially if-and-only-if and maps-to in
mathematics

*ACTION:** Add the arrows to the Non-math list.

We did not make a concept name for the arrows because we do not know what
they mean.

NS: suggested an equilibrium concept which would work for both physics and
chemistry.

PI: Arrows show a transition from one state to another state.

MuS: https://en.wikipedia.org/wiki/Feynman_diagram shows arrows used in
Feynman diagrams. The electron–positron annihilation interaction: e+ + e− →
2γ

NS: We have not decided to add anything on units yet.

NS: wants to group all the units discussion into one call.

Consider chemistry: atomic-mass and isotopes. CS says they are core.

*ACTION* atomic-mass and isotopes go into the Non-math list (issue 487).

CS: wants to add electron and positron to the Non-math list. The symbols
are: electron e to the minus one and positron e to the plus one.

Next we considered properties.

DG had forgotten why he included quotient as a property. We will come back
to it.

There was a discussion on how to write multi-scripts for chemical equations.

NS: Multi-scripts is the right way to do chemistry. Many people use
subscripts and superscripts and just don't worry about aligning things.

NS: discussed scripting as a property.

NS to CS: Did the chemical group come up with a list of symbols that could
be used in a chemical formula?

*ACTION:* Cary will see if the chemical group has created a grammar for
chemical equations. Carry is looking for symbols that can be used in
chemical equations and chemical formulas. We will create an issue where CS
can put the chemistry grammar.

We discussed having " :system-of-equations" as a property.

If you have the equation: ax squared + bx + c = 0, it can be shown as the
matrix row "A b c 0". A matrix of such rows can be treated as a system of
equations and processed as a matrix.

The :system-of-equations property could help you process the matrix
correctly.

*ACTION* For DC: Decide whether matrix or systems of equations covers the
way that that would be spoken; and, if not, propose a different name.

DG: Oh, I'm happy to close this work out, we don't need a new entry. I just
wanted to raise awareness that this exists as a notation to check whether
we thought about it.

NS: It sounds like it's covered under matrix as the way you would probably
speak it.

NS: did we add a grouping concept?

NS: Yes, we have fence group.

NS: Is charge a property or concept?

NS: Charge is a property.

DG: A positive charge of +q does not need to be in core.

From Patrick D F Ion to Everyone: That was The Green Book, Quantities,
Units, and Symbols in Physical Chemistry by the International Union of Pure
and Applied Chemistry

NS: We're going to skip charge and if it shows up, either give it to the
literal intent or will get spoken as plus Q.

matrix is a property telling how you read it.

From Deyan Ginev to Everyone: the cycle notation for permutations allows
multiple parenthetical groups:
https://en.wikipedia.org/wiki/Permutation#Cycle_notation

NS could not find the permutation concept. The permutation cycle concept is
missing.

The PR did not work.

*ACTION:* for NS: The permutation-cycle entry is missing.

Permutation may be a list of cycles. A permutation cycle can take any
number of arguments.

NS: two row version of permutation and the cycle form of permutations

**ACTION:* create an issue for two-row permutation and a group of
permutation cycles.

NS: Do we need to add anything for permutation or for groups of permutation
cycles, like something that's just called permutation that's takes children
that are permutation cycles?

DG: So, the official cycle notation admits multiple parenthetical blocks.
At least it's considered to be a single cycle. Well, it's a single piece of
notation in the This is the way I see it documented.

NS: We have the issue of what do we do with sequence of cycles.

NS: Do we need another name, another thing called permutation which is a
group of cycles?

DG: Can we not use permutation cycle?

NS: Should we put permutation into an issue and resolve it there?

NS: There's the 2-row version of permutations where the top row maps to the
bottom row, and then there's the cycle You map left to right and wrap
around. And they're different.

NS: And I don't think we support the second one yet, which is probably a
mistake. And I do not think that we support multiple cycles.

*ACTION:* NS: So put down an issue about permutations that talks about
these 2 and maybe there's an effective way to unify all these things.

Finished DG's physics list.

Open DG's chemistry list.

We have a cancel property. DC: Is the cancel property on the thing that is
being canceled, or the thing that is doing the canceling.

NS: The thing that's doing it so typically an Menclose I would put a cancel
property on it.

We are putting row 17 aside: Row 17 unknown (???)

Consider row 24 "embellished-name"

NS: add a concept of embellished-name

NS: There is always exactly 2 Things: there's the thing being embellished
and there's the name that's given to it and that tends to mean to make it
more of a concept name than a property because you can point to the 2
things; whereas, a property, you know, the AT needs to sort of figure stuff
out and Do something. So, I'm thinking it's a concept name.

Add row 28: obtained-from? (←, inverse to "maps-to")

NS: If we do not like the name, we can change it later.

done with DG's chemistry list.

Issues
------
* w3c/html-aam (+1/-0/💬7)
  1 issues created:
  - Update UIA mappings for the <label> element (by benbeaudry)
    https://github.com/w3c/html-aam/issues/524 

  3 issues received 7 new comments:
  - #524 Update UIA mappings for the <label> element (1 by benbeaudry)
    https://github.com/w3c/html-aam/issues/524 
  - #523 Clarification on <th> contextual mapping (3 by JAWS-test, rahimabdi)
    https://github.com/w3c/html-aam/issues/523 
  - #370 Consider: hidden <label> can still name associated form control (3 by accdc, pkra, scottaohara)
    https://github.com/w3c/html-aam/issues/370 [accName &amp; Desc] 

* w3c/webcomponents (+3/-1/💬17)
  3 issues created:
  - What's the right target of anchor link inside shadowDom (by woody-li)
    https://github.com/WICG/webcomponents/issues/1048 
  - April 2024 DOM Parts Quarterly Meeting (by rniwa)
    https://github.com/WICG/webcomponents/issues/1047 
  - Why is the focus visible when a lightDom element in a web component is clicked? (by Garcia-Christophe)
    https://github.com/WICG/webcomponents/issues/1046 

  2 issues received 17 new comments:
  - #1027 Jan 2024 DOM Parts Quarterly Meeting (16 by EisenbergEffect, eemeli, justinfagnani, mfreed7, rictic, rniwa)
    https://github.com/WICG/webcomponents/issues/1027 
  - #624 Custom 'void' or self-closing elements (HTML parser changes) (1 by ngdangtu-vn)
    https://github.com/WICG/webcomponents/issues/624 [custom-elements] [needs implementer interest] 

  1 issues closed:
  - Jan 2024 DOM Parts Quarterly Meeting https://github.com/WICG/webcomponents/issues/1027 

* whatwg/html (+15/-6/💬71)
  15 issues created:
  - Session history step of top level navigable when child navigables traverse history (by ADKaster)
    https://github.com/whatwg/html/issues/10106 
  - "run a classic script" returns completion records and throws (by Ms2ger)
    https://github.com/whatwg/html/issues/10104 
  - Can a task throw exceptions? (by Ms2ger)
    https://github.com/whatwg/html/issues/10103 
  - Proposal:  (by gouldcs)
    https://github.com/whatwg/html/issues/10101 [addition/proposal] [needs implementer interest] 
  - `<callout>` element for callouts/alerts/admonitions (by LeaVerou)
    https://github.com/whatwg/html/issues/10100 [addition/proposal] [needs implementer interest] 
  - Navigation: DocumentState request referrer is not set for about:srcdoc (by ADKaster)
    https://github.com/whatwg/html/issues/10099 
  - Should dir=auto with no strong characters inherit directionality from parent or be ltr? (by dbaron)
    https://github.com/whatwg/html/issues/10097 [i18n-alreq] [i18n-hlreq] 
  - Upcoming WHATNOT meeting on 2/8/2024 (by past)
    https://github.com/whatwg/html/issues/10094 [agenda+] 
  - Navigation: Clarification on `ever populated` flag of DocumentState during apply the history step (by ADKaster)
    https://github.com/whatwg/html/issues/10093 
  - `html` end tag omission (by j9t)
    https://github.com/whatwg/html/issues/10092 
  - Ability to configure whether script elements should execute for setHTMLUnsafe() (by zcorpan)
    https://github.com/whatwg/html/issues/10090 [addition/proposal] [needs implementer interest] [topic: parser] [topic: script] 
  - Scrolling when near the edge of the viewport while dragging (by jpzwarte)
    https://github.com/whatwg/html/issues/10089 
  - navigationType in apply the history step used without a null check (by ADKaster)
    https://github.com/whatwg/html/issues/10086 
  - Should showPicker() consume user activation? (by josepharhar)
    https://github.com/whatwg/html/issues/10084 
  - Labeled control when moving the mouse around is inconsistent accross UAs (by pygy)
    https://github.com/whatwg/html/issues/10083 

  25 issues received 71 new comments:
  - #10101 Proposal: HTML Attribute to state non-consent when scraping for training datasets (1 by keithamus)
    https://github.com/whatwg/html/issues/10101 [addition/proposal] [needs implementer interest] 
  - #10097 Should dir=auto with no strong characters inherit directionality from parent or be ltr? (8 by annevk, aphillips, dbaron, jfkthame, smaug----)
    https://github.com/whatwg/html/issues/10097 [i18n-tracker] [i18n-alreq] [i18n-hlreq] 
  - #10093 Navigation: Clarification on `ever populated` flag of DocumentState during apply the history step (1 by ADKaster)
    https://github.com/whatwg/html/issues/10093 
  - #10092 `html` end tag omission (3 by annevk, cwilso, j9t)
    https://github.com/whatwg/html/issues/10092 
  - #10089 Scrolling when near the edge of the viewport while dragging (2 by domenic, jpzwarte)
    https://github.com/whatwg/html/issues/10089 
  - #10086 navigationType in apply the history step used without a null check (1 by domenic)
    https://github.com/whatwg/html/issues/10086 
  - #10084 Should showPicker() consume user activation? (5 by evilpie, josepharhar, lukewarlow)
    https://github.com/whatwg/html/issues/10084 [security/privacy] [topic: forms] [security-tracker] 
  - #10081 Three-valued Button state (type=three-valued) of the type attribute of the input element (1 by sergeyprokhorenko)
    https://github.com/whatwg/html/issues/10081 [addition/proposal] [needs implementer interest] 
  - #10078 Ergonomic way to move data between workers (3 by asutherland, jakearchibald, josephrocca)
    https://github.com/whatwg/html/issues/10078 [addition/proposal] [needs implementer interest] [topic: workers] 
  - #10077 Allowing UA to do <source> selection for media element (13 by dalecurtis, domenic, jernoble, jyavenard, marcoscaceres, smaug----, zcorpan)
    https://github.com/whatwg/html/issues/10077 [needs implementer interest] [topic: media] 
  - #10052 Upcoming WHATNOT meeting on 1/25/2024 (1 by past)
    https://github.com/whatwg/html/issues/10052 [agenda+] 
  - #10032 Change when button has activation behavior (2 by annevk, vinhill)
    https://github.com/whatwg/html/issues/10032 [topic: forms] [topic: events] [topic: popover] 
  - #9799 Stylable `<select>` element (1 by brechtDR)
    https://github.com/whatwg/html/issues/9799 [addition/proposal] [topic: parser] [topic: forms] [stage: 0] 
  - #9776 popover=hint (2 by mfreed7, yisibl)
    https://github.com/whatwg/html/issues/9776 [topic: popover] 
  - #9332 [View Transitions] Extend render-blocking to support Document (14 by domenic, khushalsagar, noamr, vmpstr, zcorpan)
    https://github.com/whatwg/html/issues/9332 [addition/proposal] [topic: rendering] 
  - #9046 Timing of `<dialog>` 'close' event, popover 'toggle' event, `<details>` 'toggle' event (1 by keithamus)
    https://github.com/whatwg/html/issues/9046 [topic: dialog] [topic: popover] 
  - #8867 Add `getInnerHTML()` that optionally serializes declarative Shadow DOM (3 by annevk, mfreed7)
    https://github.com/whatwg/html/issues/8867 [addition/proposal] [topic: shadow] [topic: parser] 
  - #8538 An iframe whose history can be transferred across parent navigations (1 by Howard13Kam)
    https://github.com/whatwg/html/issues/8538 
  - #8228 Should <button> have `user-select: none;` by default? (1 by karlcow)
    https://github.com/whatwg/html/issues/8228 [topic: forms] [interop] [topic: style] 
  - #5488 <input type="time"> : Time vs. duration (2 by StephanLuis, aphillips)
    https://github.com/whatwg/html/issues/5488 [addition/proposal] [needs implementer interest] [topic: forms] [i18n-tracker] 
  - #4923 add attribute  max-size to input type file (1 by faisalsaifii)
    https://github.com/whatwg/html/issues/4923 [addition/proposal] [needs implementer interest] [topic: forms] 
  - #3257 Consider recording the "duplicate-attribute" error state. (1 by evilpie)
    https://github.com/whatwg/html/issues/3257 [topic: parser] [security/privacy] 
  - #2404 A tag to display date and/or time to the user in his preferred format. (1 by aphillips)
    https://github.com/whatwg/html/issues/2404 [addition/proposal] [needs implementer interest] [i18n-tracker] 
  - #2368 Mouse events & disabled form controls (1 by saschanaz)
    https://github.com/whatwg/html/issues/2368 [topic: forms] [topic: events] [interop] 
  - #2364 Should we allow delaying video preload until it becomes visible? (1 by patrick-mcdougle)
    https://github.com/whatwg/html/issues/2364 [topic: media] 

  6 issues closed:
  - Proposal: HTML Attribute to state non-consent when scraping for training datasets https://github.com/whatwg/html/issues/10101 [addition/proposal] [needs implementer interest] 
  - Clarify or remove note on units of related browsing contexts and units of related similar-origin browsing contexts https://github.com/whatwg/html/issues/7169 
  - Upcoming WHATNOT meeting on 1/25/2024 https://github.com/whatwg/html/issues/10052 [agenda+] 
  - `html` end tag omission https://github.com/whatwg/html/issues/10092 
  - Scrolling when near the edge of the viewport while dragging https://github.com/whatwg/html/issues/10089 
  - Should MathML references be to MathML-Core instead of full? https://github.com/whatwg/html/issues/9795 [normative change] 

* whatwg/dom (+0/-0/💬2)
  2 issues received 2 new comments:
  - #1219 clone with clone children flag set should append clone before cloning children (1 by rniwa)
    https://github.com/whatwg/dom/issues/1219 [topic: nodes] 
  - #808 Side effects due to tree insertion or removal (script, iframe) (1 by domfarolino)
    https://github.com/whatwg/dom/issues/808 [web reality] 



Pull requests
-------------
* whatwg/html (+9/-3/💬29)
  9 pull requests submitted:
  - fixed typo from null to path (whatwg#10053) (by chaburk)
    https://github.com/whatwg/html/pull/10105 
  - Editorial: Remove outdated reference to ParseScript (by Ms2ger)
    https://github.com/whatwg/html/pull/10102 [editorial] 
  - Make showPicker consume user activation (by josepharhar)
    https://github.com/whatwg/html/pull/10098 
  - Rendering: define progress, meter, range input's value layout with vertical writing-mode to support direction (by dizhang168)
    https://github.com/whatwg/html/pull/10096 
  - Editorial: Fix incorrect heading level in example (by MarcusOtter)
    https://github.com/whatwg/html/pull/10095 
  - dispatch toggleevents for dialog open/close (by keithamus)
    https://github.com/whatwg/html/pull/10091 
  - Editorial: reduce the use of class="brief" (by domenic)
    https://github.com/whatwg/html/pull/10088 
  - Navigation: Consistently fire a traverse Navigate event at a Navigation (by ADKaster)
    https://github.com/whatwg/html/pull/10087 
  - Navigation: Use NavigationHistoryBehavior in Location object navigate AO (by ADKaster)
    https://github.com/whatwg/html/pull/10085 

  17 pull requests received 29 new comments:
  - #10105 fixed typo from null to path (whatwg#10053) (1 by annevk)
    https://github.com/whatwg/html/pull/10105 
  - #10098 Make showPicker consume user activation (1 by evilpie)
    https://github.com/whatwg/html/pull/10098 
  - #10095 Editorial: Fix incorrect heading level in example (1 by MarcusOtter)
    https://github.com/whatwg/html/pull/10095 
  - #10091 dispatch toggleevents for dialog open/close (1 by josepharhar)
    https://github.com/whatwg/html/pull/10091 
  - #10069 Modify the logic for double-declarative shadow root attachment (1 by mfreed7)
    https://github.com/whatwg/html/pull/10069 
  - #10060 fix/typo issue-#10053 (1 by domenic)
    https://github.com/whatwg/html/pull/10060 
  - #10048 Don't always consume user activation for close watchers (1 by domenic)
    https://github.com/whatwg/html/pull/10048 [do not merge yet] 
  - #10022 Implement dangling markup injection mitigation (2 by annevk, shhnjk)
    https://github.com/whatwg/html/pull/10022 [security/privacy] [integration] [security-tracker] 
  - #10018 Add a new attribute called `writingsuggestions` to control UA-provided writing assistance (3 by dandclark, domenic, marcoscaceres)
    https://github.com/whatwg/html/pull/10018 
  - #10015 Hide all popovers when beforetoggle shows a popover (4 by josepharhar, mfreed7, nt1m)
    https://github.com/whatwg/html/pull/10015 [topic: popover] 
  - #9996 Defer persisted state restore when view transition is started (4 by domenic, noamr)
    https://github.com/whatwg/html/pull/9996 
  - #9898 Fix plural typo (1 by domenic)
    https://github.com/whatwg/html/pull/9898 
  - #9880 Revert recent changes to rendering of <slot>, and some of the corresponding changes to its directionality and language (1 by dbaron)
    https://github.com/whatwg/html/pull/9880 
  - #9546 Add switch attribute to the input element to allow for a two-state switch control. (2 by mfreed7, nt1m)
    https://github.com/whatwg/html/pull/9546 [addition/proposal] [needs implementer interest] [topic: forms] 
  - #9425 Allow elements with display:contents to be focusable. (1 by dbaron)
    https://github.com/whatwg/html/pull/9425 [topic: focus] 
  - #9387 Fix user-agent style rules for top layer transitions (3 by domenic, josepharhar, mfreed7)
    https://github.com/whatwg/html/pull/9387 [topic: rendering] [topic: popover] 
  - #9360 Add back/forward cache NotRestoredReasons (1 by rubberyuzu)
    https://github.com/whatwg/html/pull/9360 [addition/proposal] [topic: navigation] [needs tests] 

  3 pull requests merged:
  - Navigation: Use NavigationHistoryBehavior in Location object navigate AO
    https://github.com/whatwg/html/pull/10085 
  - Revert recent changes to rendering of <slot>, and some of the corresponding changes to its directionality and language
    https://github.com/whatwg/html/pull/9880 
  - Update mathml-related references to use MathML-Core instead of Full…
    https://github.com/whatwg/html/pull/9804 

* whatwg/dom (+2/-1/💬2)
  2 pull requests submitted:
  - Meta: update repository files (by annevk)
    https://github.com/whatwg/dom/pull/1248 
  - Draft integration with Trusted Types, take 2. (by koto)
    https://github.com/whatwg/dom/pull/1247 

  2 pull requests received 2 new comments:
  - #1246 Enforce same parameters for attachShadow on declarative shadow root (1 by mfreed7)
    https://github.com/whatwg/dom/pull/1246 
  - #809 Add attribute validate steps. (1 by koto)
    https://github.com/whatwg/dom/pull/809 [needs tests] 

  1 pull requests merged:
  - Meta: update repository files
    https://github.com/whatwg/dom/pull/1248 


Repositories tracked by this digest:
-----------------------------------
* https://github.com/w3c/html-aam
* https://github.com/w3c/html-aria
* https://github.com/w3c/html-extensions
* https://github.com/w3c/htmlwg
* https://github.com/w3c/webcomponents
* https://github.com/whatwg/html
* https://github.com/whatwg/dom


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

At the meeting today I mentioned the following conference and said I would
send details...
The 5th International Workshop on
"Digitization and E-Inclusion in Mathematics and Science 2024" (DEIMS2024)

15-17 February 2024, at Nihon University, Tokyo, Japan

There are a number of papers that might be of interest to members.
Registration for remote attendance is free, but you are supposed to
register. The procedure to register is here
<https://workshop.sciaccess.net/deims2024/registration.html>.

The program is here.
<https://workshop.sciaccess.net/deims2024/DEIMS2024Program_19Dec2023.pdf>
Times are UTC + 9 hours.

 We meet on Thursday at: 10am Pacific, 1pm Eastern, 7pm Central European Tim
*e*.

The regulars for this group should have the meeting details in their
calendars. For everyone else, the details can be found on the members-only
W3C Math WG calendar
<https://www.w3.org/events/meetings/d6f2b73d-34fc-4276-b164-bdc62a675dcc/20230713T130000/>.


Agenda
1. Announcements/Updates/Progress reports
    Next week will be a two hour meeting to discuss concept naming
2. Newly opened issues:
    Intent for "by" (as in 3×4 matrix)
<https://github.com/w3c/mathml/issues/486> #486
    Non-math intents <https://github.com/w3c/mathml/issues/487> #487
3. Large operators <https://github.com/w3c/mathml/issues/482> (482)
(integral, sum, union, etc): max 5 minutes
4. Core concept list updates
<https://w3c.github.io/mathml-docs/intent-core-concepts/> (finished the
first item so we will start on David F's wish list)
       i. Deyan's original spreadsheet
<https://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit#gid=1358098730>
(done)
       ii. David F's wish list
<https://docs.google.com/spreadsheets/d/1cLPaIy9kX5K-67RG6rjSAXErDSB-_iYmgZaTKQjShVg/edit#gid=0>
(done)
       iii. Deyan's Physics list
<https://gist.github.com/dginev/825078ae316c32c312436f42061b3d05> and Chemistry
list <https://gist.github.com/dginev/ff7e6e090b79a0389fc2eff2b9961331>, Biology
List <https://gist.github.com/dginev/d6367f53cb7b1fbed8abfa6bddd4f2c0>(finished
first part of physics list)
       iv: Neil's MathCAT intent list and MathPlayer's rules list (subject
area inferences <https://github.com/w3c/mathml/issues/476>, units
<https://github.com/w3c/mathml/issues/475>)
5. 4. Derivatives (first, higher order, different notations):[473
<https://github.com/w3c/mathml/issues/473>]

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - David Farmer
   - Moritz Schubotz
   - Bruce Miller
   - Murray Sargent
   - Bert Bos
   - Paul Libbrecht
   - Deyan Ginev
   - Cary Supalo

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

NS: We will have a two-hour meeting on February 1, 2024.

NS: International Conference on Computers Helping People with Special
Needs, (ICCHP) submission
<https://icchp.org/sites/default/files/ICCHP_CALL_2024.pdf> (Feb 2
deadline)?

NS: asked for people to help him with writing a paper for this conference.
The following individuals said they would help: DC, MoS, and PL. NS will
send his draft to them.

MuS: Added a demo mode to UnicodeMathML site (
https://murrayiii.github.io/UnicodeMathML/playground/) and conversion from
MathML to UnicodeMath. Have tested conversion from DLMF pMML examples.

DC: He has software that will translate LaTex into accessible pdf (
https://github.com/latex3/tagging-project/discussions/56). Some examples
showing initial attempts at tagging LaTeX math. Each math expression is
tagged with two associated files, one with the original LaTeX source
fragment, and one with MathML. No explicit tagging markup needs to be added
to the document body. The PDF are produced using lualatex-dev built from a
feature branch of the latex2e/latex-lab code. Currently the TeX sources are
not shown but uncompressed PDF are provided here to allow commenting on the
PDF tagging structure used and to allow testing. The files have been tested
with ngpdf and nvda+mathcat screen reader.

DC: is trying to encourage vendors to get accessible pdf to work.
Currently, pdf readers don't support accessible pdf.

NS: was asked by the head of NVDA research to incorporate MathCAT into the
NVDA core. He asked if there were things he could do to help NS get this
done.

DG: I'm curious about which LaTeX are you adding.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-f#cp-md-0-2-a-href-https-github-com-w3c-mathml-issues-485-tends-to-485-a->2.
tends-to (485) <https://github.com/w3c/mathml/issues/485>

DG: We agreed to use the above and below variants.

DG: I just wanted to clarify the issue that, even if you guys solve it for
"core", it is quite likely that it will come up for "open".

*ACTION* Close issue 485.

Now let us jump to DF's list.

<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-f#cp-md-0-5-a-href-https-w3c-github-io-mathml-docs-intent-core-concepts-core-concept-list-updates-a->5.
Core concept list updates
<https://w3c.github.io/mathml-docs/intent-core-concepts/>

(finished the first item so we will start on David F's wish list)
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-f#cp-md-0-i-a-href-https-docs-google-com-spreadsheets-d-1eswou1k5nxbdlpvqapdoa9h-s8lg_qjn8fjh64g9izq-edit-gid-1358098730-deyan-39-s-original-spreadsheet-a->i.
Deyan's original spreadsheet
<https://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit#gid=1358098730>

(done)
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-f#cp-md-0-ii-a-href-https-docs-google-com-spreadsheets-d-1clpaiy9kx5k-67rg6rjsaxerdsb-_iymgzatkqjshvg-edit-gid-0-david-f-39-s-wish-list-a->ii.
David F's wish list
<https://docs.google.com/spreadsheets/d/1cLPaIy9kX5K-67RG6rjSAXErDSB-_iYmgZaTKQjShVg/edit#gid=0>

NS: DF will walk us through this.

DF: These are ambiguous, and I know that I'll need to provide markup for.

DF: I tried to group them by appearance.

We propose to add these concepts to core.

Consider cell a5: times, cross-product, by, direct-product

*ACTION* Open an issue for "by" as in a 3 by 4 matrix.

Add direct-product (the direct-product of vector a and vector b is a vector
c whose elements are: (a1*b1, a2*b2,…an*bn))

DF: I don't think we want to distinguish between direct products of groups
and direct products of sets without a structure.

Consider cell a7: (center-of-mass-of)

*ACTION* NS: make an issue to keep track of non-math things.

BM: This list could be exceptionally large.

NS: We do not have expertise in the sciences. We don't know which terms
should be put in core.

Center-of-mass-of will go into this non-math list.

Put antiparticle-of in the non math list.

Add (cell a10) cardinality.

Add norm (cell a11).

From Deyan Ginev to Everyone: name(L,2) vs _(L,2)

add round.

add permutation-cycle

From Deyan Ginev to Everyone:
https://en.wikipedia.org/wiki/Cyclic_permutation

Add span (linear algebra, cell a19).

Add identically-equals (cell a24).

*ACTION* similar-to (cell a25) has a typo. Add similar-to

Note that keeping the word "to", in several of our concepts, will be
reconsidered when we go back through the concept list once we have made our
initial list.

From Deyan Ginev to Everyone: Easy to wonder about :superfix and :subfix

Note that "superscript" and "subscript" (rows 26 and 27) will be saved for
a separate discussion.

 This time I have a pretty good excuse for the late reminder: my
power/internet came back a few hours ago after being out since early
Saturday morning. That was an unpleasant five days! At least none of the
big trees that came down hit my house.

We meet on Thursday at: 10am Pacific, 1pm Eastern, 7pm Central European Tim
*e*.

The regulars for this group should have the meeting details in their
calendars. For everyone else, the details can be found on the members-only
W3C Math WG calendar
<https://www.w3.org/events/meetings/d6f2b73d-34fc-4276-b164-bdc62a675dcc/20230713T130000/>.


Agenda
1. Announcements/Updates/Progress reports
2. tends-to <https://github.com/w3c/mathml/issues/485> (485)
3. Large operators <https://github.com/w3c/mathml/issues/482> (482)
(integral, sum, union, etc): max 5 minutes (issue opened at the last
minute, so not much discussion)
4. Derivatives (first, higher order, different notations):[473
<https://github.com/w3c/mathml/issues/473>] max 10 minutes (lots of
discussion)
5. Core concept list updates
<https://w3c.github.io/mathml-docs/intent-core-concepts/> (finished the
first item so we will start on David F's wish list)
       i. Deyan's original spreadsheet
<https://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit#gid=1358098730>
(done)
       ii. David F's wish list
<https://docs.google.com/spreadsheets/d/1cLPaIy9kX5K-67RG6rjSAXErDSB-_iYmgZaTKQjShVg/edit#gid=0>
       iii. Deyan's Physics list
<https://gist.github.com/dginev/825078ae316c32c312436f42061b3d05> and Chemistry
list <https://gist.github.com/dginev/ff7e6e090b79a0389fc2eff2b9961331>
(finished first part of physics list)
       iv: Neil's MathCAT intent list and MathPlayer's rules list (subject
area inferences <https://github.com/w3c/mathml/issues/476>, units
<https://github.com/w3c/mathml/issues/475>)

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Moritz Schubotz
   - Bruce Miller
   - Bert Bos
   - Deyan Ginev
   - Paul Libbrecht
   - Cary Supalo

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

International Conference on Computers Helping People with Special Needs,
(ICCHP) submission
<https://icchp.org/sites/default/files/ICCHP_CALL_2024.pdf> (Feb 2
deadline)?

NS: asked for people to help him with writing a paper for this conference.
The following individuals said they would help: DC, MoS, and PL.

NS will try to come up with an outline this weekend.

PL: We should attend conferences and publicize our MathML work.

PL: Are there technical sessions on Math in the ICCHP?

NS: They have a special session on math and science. This conference is
held every other year. They have about 30-50 people in the math and science
session.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-2-a-href-https-github-com-w3c-mathml-issues-484-mixed-fractions-in-core-484-a->2.
mixed-fractions in core (484) <https://github.com/w3c/mathml/issues/484>

PL: This needs to go in core. Not sure what name it should have.

PL: You should not say mixed-fraction one and one half. You should leave
out the word mixed-fraction. You should just say one and one half.

NS: Use "and" as the linker word.

NS: Do not say mixed-fraction and do not say "comma": "one comma one half"
is not good.

NS: This issue (484) can be closed.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-3-a-href-https-github-com-w3c-mathml-issues-483-ellipsis-483-a->3.
Ellipsis (483) <https://github.com/w3c/mathml/issues/483>

NS: I did use what DG pointed out is an encyclopedic name for ellipsis. You
can see it towards the top of the concept list. There are names for
ellipses going in different directions.

DG: The Unicode name is better than what NS chose because it gives the full
information.

There was a discussion on what the proper names for directions would be.

NS: What do other people think? Is Downright better than downwards and to
the right, and is upright better than upwards and to the right?

DC: Do the directions have any mathematical meaning? Can they all just say
ellipsis?

NS: If you cannot see the characters, then you are losing some of the
meaning of the symbol.

NS: If you had a matrix, you could have a diagonal ellipsis in the middle.
The directions could tell you that there is some type of structure in your
matrix.

NS: Since the ellipsis with different directions gives you information,
they should be named.

NS is unsure if this issue should be closed.

PL: You should speak the directions for the ellipses.

NS: This would give the blind the same information that the sighted have.

From Deyan Ginev to Everyone: directionality will come up often with
arrows, e.g., \upmapsto and \downmapsto could be up-maps-to and
down-maps-to https://tex.stackexchange.com/a/54639

DG: We need to have a method to select concept names for symbols that have
directional information.

NS wants to have a meeting on naming.

NS: We are ok with the names for the ellipsis.

DG: Agrees with the current naming scheme in the short term. He wants to
come back and revisit our naming strategy.

NS: Okay. Well, we are going with sort of the encyclopedic names. Your
objection was that the Unicode name was a better choice, but I think
they're both falling in the category of an encyclopedic name.

DG: So, this is great. The tiny detail that is left is when and how we add
topographic information on top of the encyclopedic name.

DG: The concept is ellipsis. Sometimes we should give directional
information.

DG: You do not want to give directional information all the time because
sometimes it is superfluous information.

NS: This really comes up in the cases involving arrows. The convention that
they used in Unicode for the Arrows is basically trying to just describe
what the arrows are. The arrow names do not try to say what the symbol
means.

DC: The directional ellipsis case, where the direction makes a difference,
is rare, and we do not have to worry about it.

DC: We give names to arrows which describe what the arrows do. We do not
have to describe what the arrows look like.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-4-a-href-https-github-com-w3c-mathml-issues-485-tends-to-485-a->4.
tends-to (485) <https://github.com/w3c/mathml/issues/485>

NS: Summarized the issue.

It breaks down into three different cases. One is generic tends-to. Another
is one where it tends-to from a certain direction, Either from below or
left, or from above and to the right. This is one way to name the
directions.

NS: DG suggested adding a third optional argument of above or below.

NS: AT can read things poorly.

DG: There's a fourth example if you open the Wikipedia page on one sided
limits that doesn't use an arrow. I didn't quote it, but it's in the
comment. If you open that link, there's this beautiful example with the
superscript.

NS is not a fan of using three concept names.

NS: There is a notion that, if AT doesn't know about it, then the AT should
simply read what is there. It still should speak it in a comprehensible way.

NS asked DG if there was another case where you could throw on an added
argument.

DG: I was thinking of maps-to since we just discussed arrows. Because
maps-to can point: top to bottom, or bottom to top, or left to right, or
right to left.

DG: I found a good counter-argument to my own point, and in support of
Neil's suggestion for multiple names, which is that we have precedent for
adding multiple entries for the same concept with different boundary
conditions. Namely for the same interval concept, we have open-interval,
open-closed-interval, closed-open-interval and closed-interval. So, based
on that precedent, it is reasonable to do the same kind of branching for
tends-to. Thinking about this some more, the interval example highlights
both points. 1. We have done it before, so we can do it again (multiple
concepts varying on boundary conditions). 2. Without better argument
support, various adverb phrases arguments will require branching into
multiple concepts.

NS: We ended up saying there's really 2 arguments. And they are very
related concepts, but they're not the same concept. So, I think that
argument would apply here for the tends-to.

DC: Do you have a proposal for the names?

NS: I am open to tends-to or approaches left to right.

DC: I prefer tends-to rather than approaches, and above and below to left
and right.

NS: DG, do you agree with this?

DG: To me they're all arbitrary so any ones you pick are fine. I'm just
wondering whether it's even worse than what I thought in the sense that
above and below are just the same as left and right but it's just the
y-axis instead of the x-axis.

NS: I do not have an effective way to choose between up and down and left
and right.

NS will remove "approaches" from issue 485.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-5-a-href-https-github-com-w3c-mathml-issues-482-large-operators-482-a-integral-sum-union-etc-max-5-minutes-issue-opened-at-the-last-minute-so-not-much-discussion->5
Large operators (482) <https://github.com/w3c/mathml/issues/482> (integral,
sum, union, etc.): max 5 minutes (issue opened at the last minute, so not
much discussion)
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-6-derivatives-first-higher-order-different-notations-a-href-https-github-com-w3c-mathml-issues-473-473-a->6.
Derivatives (first, higher order, different notations):473
<https://github.com/w3c/mathml/issues/473>

max 10 minutes (lots of discussion)
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-7-a-href-https-w3c-github-io-mathml-docs-intent-core-concepts-core-concept-list-updates-a->7.
Core concept list updates
<https://w3c.github.io/mathml-docs/intent-core-concepts/>

(finished the first item so we will start on David F's wish list)
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-i-a-href-https-docs-google-com-spreadsheets-d-1eswou1k5nxbdlpvqapdoa9h-s8lg_qjn8fjh64g9izq-edit-gid-1358098730-deyan-39-s-original-spreadsheet-a->i.
Deyan's original spreadsheet
<https://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit#gid=1358098730>

(done)
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-ii-a-href-https-docs-google-com-spreadsheets-d-1clpaiy9kx5k-67rg6rjsaxerdsb-_iymgzatkqjshvg-edit-gid-0-david-f-39-s-wish-list-a->ii.
David F's wish list
<https://docs.google.com/spreadsheets/d/1cLPaIy9kX5K-67RG6rjSAXErDSB-_iYmgZaTKQjShVg/edit#gid=0>
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-iii-a-href-https-gist-github-com-dginev-825078ae316c32c312436f42061b3d05-deyan-39-s-physics-list-a-and-a-href-https-gist-github-com-dginev-ff7e6e090b79a0389fc2eff2b9961331-chemistry-list-a->iii.
Deyan's Physics list
<https://gist.github.com/dginev/825078ae316c32c312436f42061b3d05> and Chemistry
list <https://gist.github.com/dginev/ff7e6e090b79a0389fc2eff2b9961331>

(finished first part of physics list)

discussed line 78 in DG's table which was: "name (do we use
_($piece1,$piece2,...$piecen) or name($piece1,...)?)"

start with Misc

NS: So, we have several separators Listed there. I know Murray was like, oh
you can't use time because time is so location dependent on how it's
spoken, but this is more about just specifying what say the colon means.

NS: What is "list-separator"?

DG: There was an example with a nested list where you had colon, semicolon
and comma as the separators.

NS: Maybe it is a property more than a concept.

time-separator

NS You would have hours minutes and seconds, thus you would have three
arguments.

Interval-separator

DG: So, consider integral from 1.1 to 1.9. It could be the integral from
1,1 to 1,9.

NS: We already named "interval:, so we do not need an "interval-separator".

NS: We maybe need something about time. Would it just be called time?

DG: Time is complicated.

*ACTION* Neil will set up a time issue.

NS: Is still trying to figure out what a list-separator is.

NS: The fourth one is where-separator ( : such-that?)

NS: This is some sort of "set" concept and does not matter.

DG: So maybe we do not need any of them. We only must figure out time.

NS: Will set up an issue for "time", and that is where we are stopping for
today.

PL: We need to tell the outside world about our work. We need to put out
another snapshot of our status. NS's ICCHP paper may be such a status
report.

NS: has a paper describing how he got pdf accessibility to work.

NS: There is an accessibility conference in Japan from February 14-16 that
is virtual.

NS: Next meeting, NS will discuss having two-hour meetings. That will allow
us to have our discussion on naming.

 I forgot to include recent issue discussion in the agenda I previously
sent out. They have been added to this agenda.

We meet on Thursday at: 10am Pacific, 1pm Eastern, 7pm Central European Tim
*e*.

The regulars for this group should have the meeting details in their
calendars. For everyone else, the details can be found on the members-only
W3C Math WG calendar
<https://www.w3.org/events/meetings/d6f2b73d-34fc-4276-b164-bdc62a675dcc/20230713T130000/>.


Agenda
1. Announcements/Updates/Progress reports
    ICCHP submission
<https://icchp.org/sites/default/files/ICCHP_CALL_2024.pdf> (Feb 2
deadline)?
2. mixed-fractions in core <https://github.com/w3c/mathml/issues/484> (484)
3. Ellipsis <https://github.com/w3c/mathml/issues/483>(483)
4. tends-to <https://github.com/w3c/mathml/issues/485> (485)
5. Large operators <https://github.com/w3c/mathml/issues/482> (482)
(integral, sum, union, etc): max 5 minutes (issue opened at the last
minute, so not much discussion)
6. Derivatives (first, higher order, different notations):[473
<https://github.com/w3c/mathml/issues/473>] max 10 minutes (lots of
discussion)
7. Core concept list updates
<https://w3c.github.io/mathml-docs/intent-core-concepts/> (finished the
first item so we will start on David F's wish list)
       i. Deyan's original spreadsheet
<https://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit#gid=1358098730>
(done)
       ii. David F's wish list
<https://docs.google.com/spreadsheets/d/1cLPaIy9kX5K-67RG6rjSAXErDSB-_iYmgZaTKQjShVg/edit#gid=0>
       iii. Deyan's Physics list
<https://gist.github.com/dginev/825078ae316c32c312436f42061b3d05> and Chemistry
list <https://gist.github.com/dginev/ff7e6e090b79a0389fc2eff2b9961331>
(finished first part of physics list)
       iv: Neil's MathCAT intent list and MathPlayer's rules list (subject
area inferences <https://github.com/w3c/mathml/issues/476>, units
<https://github.com/w3c/mathml/issues/475>)
2 Attachments • Scanned by Gmail

 We meet on Thursday at: 10am Pacific, 1pm Eastern, 7pm Central European Tim
*e*.

The regulars for this group should have the meeting details in their
calendars. For everyone else, the details can be found on the members-only
W3C Math WG calendar
<https://www.w3.org/events/meetings/d6f2b73d-34fc-4276-b164-bdc62a675dcc/20230713T130000/>.


Agenda
1. Announcements/Updates/Progress reports
    ICCHP submission
<https://icchp.org/sites/default/files/ICCHP_CALL_2024.pdf> (Feb 2
deadline)?
2. Large operators <https://github.com/w3c/mathml/issues/482> (482)
(integral, sum, union, etc): max 5 minutes (issue opened at the last
minute, so not much discussion)
3. Derivatives (first, higher order, different notations):[473
<https://github.com/w3c/mathml/issues/473>] max 10 minutes (lots of
discussion)
4. Core concept list updates
<https://w3c.github.io/mathml-docs/intent-core-concepts/> (finished the
first item so we will start on David F's wish list)
       i. Deyan's original spreadsheet
<https://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit#gid=1358098730>
(done)
       ii. David F's wish list
<https://docs.google.com/spreadsheets/d/1cLPaIy9kX5K-67RG6rjSAXErDSB-_iYmgZaTKQjShVg/edit#gid=0>
       iii. Deyan's Physics list
<https://gist.github.com/dginev/825078ae316c32c312436f42061b3d05> and Chemistry
list <https://gist.github.com/dginev/ff7e6e090b79a0389fc2eff2b9961331>
(finished first part of physics list)
       iv: Neil's MathCAT intent list and MathPlayer's rules list (subject
area inferences <https://github.com/w3c/mathml/issues/476>, units
<https://github.com/w3c/mathml/issues/475>)

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Patrick Ion
   - Bruce Miller
   - Cary Supalo
   - Deyan Ginev

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

   - Paul Libbrecht

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

DG: At our December 21, 2023 meeting, DG announced that arXiv was putting
out papers in MathML. The announcement at:
https://blog.arxiv.org/2023/12/21/accessibility-update-arxiv-now-offers-papers-in-html-format/

DG: said this release was going well. We are at 75% successful conversions
and 97% conversions that produce some HTML.

DG: We are releasing the PERL version. The Rust version will be released
next year.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0#cp-md-0-2-a-href-https-github-com-w3c-mathml-issues-482-large-operators-482-a-integral-sum-union-etc-max-5-minutes-issue-opened-at-the-last-minute-so-not-much-discussion->2
Large operators (482) <https://github.com/w3c/mathml/issues/482> (integral,
sum, union, etc.): max 5 minutes (issue opened at the last minute, so not
much discussion)

NS: There are about 10 large operators that probably make sense to go into
core (maybe integral, double integral, triple integral, contour integral,
surface integral, volume integral, sum, product, coproduct, union,
intersection). Likely what result is decided for core should be extended to
open for the other large operators (e.g., ⊍). These are all remarkably
similar in structure in that intent potentially goes on msub/munder with
one argument (typically specifying a domain for the "index") and
msubsup/munderover with two arguments ("... from xxx to yyy"). Or they go
on a containing mrow with an additional argument (e.g., "... from xxx to
yyy of zzz"). If they go on one of the scripting elements, then there is no
need for intents for indefinite integration or sums that don't have limits.
If they go on an mrow, then maybe it makes sense to have an intent for them
although Neil felt the speech needs no intent because there is no other
sensible speech for "integral", "sum", etc.

NS: In the December 21, 2023 meeting, Neil felt that listing these all out
both uses up a lot of space (and hence appears complicated) and more
importantly, obscures their similarity making it harder on both generators
and consumers of the spec. His suggestion is to create another list between
the "Core Concept Default Fixity properties" and the "Core Concept
Templates". Others were not enthusiastic about that idea.

DC: His worry is that by having a list, we will end up with a more
compressed list, but every sort of section has its own format.

NS: The difference with the trig ones is that there are diverse ways to
pronounce them; for example, the tangent function can be pronounced diverse
ways.

NS: Although again, I think it could be significantly compressed. I think
there are 24 of those entries.

NS: There aren't diverse ways of speaking "sum" or large operators.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0#cp-md-0-3-derivatives-first-higher-order-different-notations->3.
Derivatives (first, higher order, different notations):[

473 <https://github.com/w3c/mathml/issues/473>] max 10 minutes (lots of
discussion)

BM: We have in the intent the ability for the head to have parenthesis, and
then arguments.

BM: The head can be complex. It doesn't have to be just a simple token like
a parenthesis.

NS: That is correct.

BM: It can be f squared applied to x. And so, you have this level of
abstraction. Which One could take the point of view, that with both
derivatives and big ops, they're always to be thought of as operators that
get applied to something, In which case, which is potentially something
that simplifies the options for derivatives.

NS: This makes it too complicated. Use properties to help it speak
properly. Have a property that says this thing is a derivative.

PI: This is about generating pronounceable material. This is not for the
semantics. It is just for the pronunciation.

PI: It's just for deciding whether you have a terse or verbose reading.

NS: The verbose readings are all kind of the same, and the terse reading
simply follows the notation. You need to be able to produce both verbose
and terse readings.

NS: Once you recognize the material you are reading, you want to increase
your speed until you reach the denser material which might require a lower
reading speed.

From Cary Supalo to Everyone: Neil, I do totally agree. I like to plow
through my material as fast as possible.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0#cp-md-0-4-a-href-https-w3c-github-io-mathml-docs-intent-core-concepts-core-concept-list-updates-a->4.
Core concept list updates
<https://w3c.github.io/mathml-docs/intent-core-concepts/>

(finished the first item so we will start on David F's wish list)
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0#cp-md-0-i-a-href-https-docs-google-com-spreadsheets-d-1eswou1k5nxbdlpvqapdoa9h-s8lg_qjn8fjh64g9izq-edit-gid-1358098730-deyan-39-s-original-spreadsheet-a->i.
Deyan's original spreadsheet
<https://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit#gid=1358098730>

We have finished this section.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0#cp-md-0-ii-a-href-https-docs-google-com-spreadsheets-d-1clpaiy9kx5k-67rg6rjsaxerdsb-_iymgzatkqjshvg-edit-gid-0-david-f-39-s-wish-list-a->ii.
David F's wish list
<https://docs.google.com/spreadsheets/d/1cLPaIy9kX5K-67RG6rjSAXErDSB-_iYmgZaTKQjShVg/edit#gid=0>

We will consider this section when DF can come to the meeting.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0#cp-md-0-iii-a-href-https-gist-github-com-dginev-825078ae316c32c312436f42061b3d05-deyan-39-s-physics-list-a-and-a-href-https-gist-github-com-dginev-ff7e6e090b79a0389fc2eff2b9961331-chemistry-list-a->iii.
Deyan's Physics list
<https://gist.github.com/dginev/825078ae316c32c312436f42061b3d05> and Chemistry
list <https://gist.github.com/dginev/ff7e6e090b79a0389fc2eff2b9961331>

Things to be added to core.

vertical-ellipsis (Put its Unicode characters in the core list.)

repeating-decimal

From Deyan Ginev to Everyone: intent="_(7, repeating-digits(14))"

From Patrick D F Ion to Everyone: See rep digit in Wikipedia for something
that needs this markup.

list

tends-to

defined-as (NS: defined-as needs to get fixed up.)

directed-line segment

Return to line 78: name (do we use _($piece1,$piece2,...$piecen) or
name($piece1,...)?)

scalar-product (dot-product)

polar-coordinate

tuple

del-operator (used for gradient, diverge and curl)

We reached line 96 which ended this section.

Start with the Misc section.

Issues
------
* w3c/webcomponents (+0/-0/💬17)
  4 issues received 17 new comments:
  - #1042 Observing slotchange mutation records: a `SlotChangeObserver` API similar to `MutationObserver` with `childList:true` (2 by Westbrook, smaug----)
    https://github.com/WICG/webcomponents/issues/1042 
  - #1031 Quarterly Face to Face Scheduling (10 by Westbrook, alice, behowell, justinfagnani, rniwa, zcorpan)
    https://github.com/WICG/webcomponents/issues/1031 
  - #1027 DOM Parts Quarterly Meeting (3 by Westbrook, eemeli, rniwa)
    https://github.com/WICG/webcomponents/issues/1027 
  - #809 Need a callback for when children changed or parser finished parsing children (2 by justinfagnani, smaug----)
    https://github.com/WICG/webcomponents/issues/809 [custom-elements] [html-dom] [needs concrete proposal] 

* whatwg/html (+6/-2/💬51)
  6 issues created:
  - A way to disable animation of cancelled drag for editor apps like VS Code (by zcbenz)
    https://github.com/whatwg/html/issues/10039 [addition/proposal] [needs implementer interest] 
  - Should past user activations be kept after refresh? (by CanadaHonk)
    https://github.com/whatwg/html/issues/10038 
  - ARIA attribute reflection uses DOMString? but they are not enumerated attributes (by domenic)
    https://github.com/whatwg/html/issues/10037 [a11y-tracker] [topic: reflect] 
  - VT (by VTVENNILAVAN)
    https://github.com/whatwg/html/issues/10036 
  - Render-blocking scripts should also work for inline scripts (by noamr)
    https://github.com/whatwg/html/issues/10034 
  - Change when button has activation behavior (by vinhill)
    https://github.com/whatwg/html/issues/10032 

  23 issues received 51 new comments:
  - #10038 Should past user activations be kept after refresh? (2 by CanadaHonk, domenic)
    https://github.com/whatwg/html/issues/10038 
  - #10037 ARIA attribute reflection uses DOMString? but they are not enumerated attributes (1 by nolanlawson)
    https://github.com/whatwg/html/issues/10037 [a11y-tracker] [topic: reflect] 
  - #10034 Render-blocking scripts should also work for inline scripts (3 by noamr, zcorpan)
    https://github.com/whatwg/html/issues/10034 [addition/proposal] 
  - #10030 Is HTML stagnated? (2 by alejsanc)
    https://github.com/whatwg/html/issues/10030 
  - #10029 Should `:target` match after elements are removed and reattached to the document? (2 by domenic, josepharhar)
    https://github.com/whatwg/html/issues/10029 
  - #10026 Detached OffscreenCanvas is underspecified (2 by Kaiido, junov)
    https://github.com/whatwg/html/issues/10026 [topic: canvas] [interop] 
  - #10013 User interacted flag gets set when change events are set, but tests disagree (2 by josepharhar, mitunshikder123)
    https://github.com/whatwg/html/issues/10013 [agenda+] [topic: selectors] 
  - #9993 Upcoming WHATNOT meeting on 1/11/2024 (2 by annevk, zcbenz)
    https://github.com/whatwg/html/issues/9993 [agenda+] 
  - #9987 Editorial: link the Promise<T> type throughout (1 by mitunshikder123)
    https://github.com/whatwg/html/issues/9987 [good first issue] [editorial] 
  - #9960 <hr> in <select> size >1 (1 by motari54)
    https://github.com/whatwg/html/issues/9960 [topic: rendering] [topic: forms] 
  - #9935 Cookie API (14 by kettanaito, marco-ippolito, mkarajohn, pilcrowOnPaper)
    https://github.com/whatwg/html/issues/9935 [addition/proposal] [needs implementer interest] [topic: cookie] 
  - #9776 popover=hint (3 by kizu, yisibl)
    https://github.com/whatwg/html/issues/9776 [topic: popover] 
  - #9702 [View Transition] Event on old Document to set transition state (1 by khushalsagar)
    https://github.com/whatwg/html/issues/9702 
  - #8413 Clarify value direction for elements "progress" and "meter" with vertical writing mode (1 by dizhang168)
    https://github.com/whatwg/html/issues/8413 [topic: rendering] [i18n-tracker] [i18n-jlreq] [i18n-clreq] [i18n-mlreq] 
  - #7485 Modernized version of window.open() API (1 by jimmywarting)
    https://github.com/whatwg/html/issues/7485 [addition/proposal] [needs implementer interest] 
  - #6759 How should timers account for system sleep/suspend? (1 by dotproto)
    https://github.com/whatwg/html/issues/6759 
  - #4177 Rendering <input type=range> vertically (1 by dizhang168)
    https://github.com/whatwg/html/issues/4177 [topic: rendering] [topic: forms] 
  - #3705 Split source file into sections (2 by alejsanc)
    https://github.com/whatwg/html/issues/3705 [spec tooling] 
  - #3230 Should "script-src 'none'" CSP in HTTP headers count as scripting being disabled? (1 by jimmywarting)
    https://github.com/whatwg/html/issues/3230 [topic: script] 
  - #2358 A use case for cursor control for number inputs (1 by Tolluset)
    https://github.com/whatwg/html/issues/2358 [topic: forms] 
  - #2177 Setting headers for EventSource (2 by ThiefMaster, jschoch)
    https://github.com/whatwg/html/issues/2177 [addition/proposal] [needs implementer interest] [topic: fetch] [topic: eventsource] 
  - #1568 'run authentic click activation steps' doesn't deal with the case when activation behavior changes during click event dispatch (4 by vinhill, zcorpan)
    https://github.com/whatwg/html/issues/1568 [needs tests] [topic: events] 
  - #1567 <button> shouldn't have activation behavior when it is not in a form (1 by zcorpan)
    https://github.com/whatwg/html/issues/1567 [clarification] [topic: forms] [topic: events] 

  2 issues closed:
  - Should past user activations be kept after refresh? https://github.com/whatwg/html/issues/10038 
  - VT https://github.com/whatwg/html/issues/10036 [spam] 



Pull requests
-------------
* whatwg/html (+2/-0/💬4)
  2 pull requests submitted:
  - Allow render-blocking inline scripts (by noamr)
    https://github.com/whatwg/html/pull/10035 
  - Add argument labels when invoking "apply the history step" (by awesomekling)
    https://github.com/whatwg/html/pull/10033 

  3 pull requests received 4 new comments:
  - #9958 typo (1 by annevk)
    https://github.com/whatwg/html/pull/9958 
  - #9804 Update mathml-related references to use MathML-Core instead of Full… (2 by bkardell, emilio)
    https://github.com/whatwg/html/pull/9804 
  - #8028 Add new UA style rules for overflow changes; see w3c/csswg-drafts#7144 (1 by mitunshikder123)
    https://github.com/whatwg/html/pull/8028 [do not merge yet] [topic: rendering] [integration] 


Repositories tracked by this digest:
-----------------------------------
* https://github.com/w3c/html-aam
* https://github.com/w3c/html-aria
* https://github.com/w3c/html-extensions
* https://github.com/w3c/htmlwg
* https://github.com/w3c/webcomponents
* https://github.com/whatwg/html
* https://github.com/whatwg/dom


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

FYI: I added an issue <https://github.com/w3c/mathml/issues/483> about
whether baseline and midline ellipsis should share the same "ellipsis" name.

    Neil

 I hope everyone had a good holiday and is refreshed for the New Year.

We meet on Thursday at: 10am Pacific, 1pm Eastern, 7pm Central European Tim
*e*.

The regulars for this group should have the meeting details in their
calendars. For everyone else, the details can be found on the members-only
W3C Math WG calendar
<https://www.w3.org/events/meetings/d6f2b73d-34fc-4276-b164-bdc62a675dcc/20230713T130000/>.


Agenda
1. Announcements/Updates/Progress reports
2. Large operators <https://github.com/w3c/mathml/issues/482> (482)
(integral, sum, union, etc): max 5 minutes (issue opened at the last
minute, so not much discussion)
3. Derivatives (first, higher order, different notations):[473
<https://github.com/w3c/mathml/issues/473>] max 10 minutes (lots of
discussion)
4. Core concept list updates
<https://w3c.github.io/mathml-docs/intent-core-concepts/> (finished the
first item so we will start on David F's wish list)
       i. Deyan's original spreadsheet
<https://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit#gid=1358098730>
(left off at line 180, but mainly just large ops/derivatives left)
       ii. David F's wish list
<https://docs.google.com/spreadsheets/d/1cLPaIy9kX5K-67RG6rjSAXErDSB-_iYmgZaTKQjShVg/edit#gid=0>
       iii. Deyan's Physics list
<https://gist.github.com/dginev/825078ae316c32c312436f42061b3d05> and Chemistry
list <https://gist.github.com/dginev/ff7e6e090b79a0389fc2eff2b9961331>
       iv: Neil's MathCAT intent list and MathPlayer's rules list (subject
area inferences <https://github.com/w3c/mathml/issues/476>, units
<https://github.com/w3c/mathml/issues/475>)