# Planet MathML

The Planet MathML aggregates posts from various blogs that concern MathML. Although it is hosted by W3C, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of W3C.

## Re: Interest in a virtual face-to-face meeting at TPAC?

Source: public-mathml4@w3.org Mail Archives • Neil Soiffer (soiffer@alum.mit.edu) • August 07, 2020 • Permalink

There does not appear enough interest (5 people) to schedule a TPAC time
slot. I will try to grab time for a breakout session to discuss the charter
with other groups the week of Oct 26.

Neil

On Mon, Aug 3, 2020 at 9:11 PM Neil Soiffer <soiffer@alum.mit.edu> wrote:

> The W3C is having a virtual TPAC (Technical Plenary and Advisory
> Committee) meeting this year [1]. As mentioned in email and meetings, a
> goal is to have MathML Working Group Charter ready to discuss with other
> groups by the meeting. The meeting is spread out over two weeks;
> attendance is free. The first week (Oct 12-16) is for committee meetings. A
> second week (Oct 26-30, 14:00–15:00 UTC) is for breakout sessions and that
> is where I hope we get other group members to join in a discussion of the
> WG Charter and get their feedback.
>
> For the first week, it is a chance for this community group to have a
> virtual face-to-face and do a deep dive into one or more topics. I want to
> gauge interest in having such a meeting and have created a doodle poll
> <https://doodle.com/poll/ev9kt69dk7wuyihg> where you can indicate what
> times will work for you. I have created two blocks each day, with each
> block being three hours. If you are interested in a face to face meeting,
> you are interested in.
>
> *I will close the poll on Thursday (Aug 6)*, gather up the suggestions,
> and then do another poll with the most popular times and suggestions to
> gauge whether we should have 0, 1, or 2 blocks of meetings.
>
>     Neil
>
> [1] https://www.w3.org/2020/10/TPAC/Overview.html
>


## [CSSWG] Minutes Virtual F2F 2020-07-28 Part II: CSS Inline 3, CSS Text [css-inline] [css-text]

Source: www-style@w3.org Mail Archives • Dael Jackson (daelcss@gmail.com) • August 07, 2020 • Permalink

=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
with an appropriate subject line.
=========================================

CSS Inline 3 (Continued)
------------------------

- RESOLVED: No change [leave as text-top and text-bottom] (Issue
#860: Naming of text-top and text-bottom baselines)
- There was interest from the group in extending the vertical
align property to the n-th child so a proposal should be created.
The proposal should deal with cases for different elements
setting first and last baseline and cases where first baseline
isn't necessarily the first baseline selected. (Issue #1339:
Vertically align to nth-child)
- RESOLVED: Canonical order of vertical-align is source,
baseline, shift (Issue #5235: vertical-align syntax /
canonical ordering)
- RESOLVED: We want to allow reordering of values for vertical-align
(Issue #5235)
- RESOLVED: In order to keep vertical-align and align similar we
want to allow reordering of values for align property
(Issue #5235)
- RESOLVED: auto value of baseline-source not allowed in
vertical-align shorthand (Issue #5235)
- RESOLVED: top and bottom take precedence over middle (Issue #5234:
'vertical-align: middle' on table cells)
- RESOLVED: Leave vertical-align superscript and subscript as a may
[for using font metrics] (Issue #5225: vertical-align:
super and font metrics)
- RESOLVED: Font face descriptor for metrics should include
superscript and subscript size and position and allow
opting in to use font metrics (Issue #5225)
- RESOLVED: 0.2em [amount to shift down for vertical-align: sub] and
1/3 em [amount to shift up for vertical-align: super]
are the ratios [when not using font metrics] for
superscript and subscript (Issue #5225)
- Being able to vertically align to the middle of the cap height
(Issue #4707) will be deferred to the next level so that the
group can see if the central property, once implemented, solved
this problem, as well to include problems like these in the
more universal solution for all languages.

CSS Text
--------

- There was a proposal to introduce a switch for letter-spacing
behaviors in order to allow authors to opt into the preferred
behavior and, if that behavior is later found to be web compat,
make it the default.
- However, there was push back about creating a switch which may
later be unnecessary, especially if it's found that it can
become the default value.
- Both Firefox and WebKit are working on changing the behavior in
their implementations so there should be real data to determine
if this is a breaking change shortly.
- RESOLVED: Change Text L3 to a may for the [letter-spacing]
behavior and transfer switch discussion to Text L4
(Issue #1518: letter-spacing should not apply to the end
edge of a line/span?)

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#tuesday

Scribe: dael

CSS Inline 3
============

Rossen: It's :15 after the hour
Rossen: We'll do vertical alignment and break at top of hour

Naming of text-top and text-bottom baselines
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/860

fantasai: We have text-top and text-bottom of vertical align
fantasai: Not really top and bottom in vertical text. Should we
rename?
fantasai: My position is in spec use over and under terms, but
keywords in vertical-align no point in renaming since
existed since CSS1. Any new properties with the new
keywords should be consistent with vertical-align.
Don't rename the syntax, use over and under in spec.

AmeliaBR: We have keywords for this, text-before-edge and
-after-edge which are legacy keywords for SVG. If there's
a desire for logical names we could undeprecate
fantasai: Yeah but don't match anything else in css. Also in
vertical-lr before and over edge don't coincide.
I'm not sure which SVG thinks is what.
fantasai: Difference between flow- and line-relative keywords

Rossen: myles brought up good point on issue about aligning with
naming from font terms
fantasai: Yeah. Fonts uses top and bottom, but it's so deep it's
only exposed to author of font file in abbreviated form
fantasai: I think so far removed from terms web authors use it's
effectively not relevant
koji: They are very different. Font is physical so top is not always
over. CSS always takes text-top and -bottom as logical but in
fonts text-top is physical

<fantasai> https://drafts.csswg.org/css-inline-3/#baseline-types
fantasai: I don't think we should rename or alias keywords. Stick
with text-top and -bottom. In spec prose use text over and
under. That's what I drafted ^
AmeliaBR: Given we're stuck with property being vertical-align
having keywords as describing from vertical alignment is
probably okay.
fantasai: Yeah, that's where I landed. Close no change
Rossen: Are you saying current text-over?
fantasai: Current spec does not add new keywords. Uses text-top and
-bottom. Doesn't switch over anything. Spec prose when
discussing uses text-over or ideographic-over in
descriptions
Rossen: I see
Rossen: And leaving no change is closer to font terms as well
besides weirdness koji mentioned

Rossen: Proposal is no change, leave as text-top and text-bottom
Rossen: Thoughts or objections?
koji: Confirm- I think we're adding keywords for ideographic-top and
-bottom?
fantasai: I think we don't have -top, we just have ideographic which
is the bottom edge. Inherited from SVG. Not adding any
keywords for top
chris: Because they were originally baseline
Rossen: Objections?

RESOLVED: No change

Vertically align to nth-child
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/1339

fantasai: Some discussion of being able to align not just to first
or last line but of a particular child of element
fantasai: Some people working on mathML polyfills wanted this. Also
cases where might want vertical alignment in respect to
heading but stuff above you ignore
fantasai: Feature to say hey this element is what you should pay
attention to for baseline.
<fantasai> https://github.com/w3c/csswg-drafts/issues/1339#issuecomment-494988680
<fantasai> e.g. baseline-priority: high | normal
fantasai: Question is does WG want to add such a feature like
baseline-priority:high and if it's high that gets priority?

<dbaron> what if you want a child to override the first baseline but
not the last baseline?

AmeliaBR: Useful for various layout cases where default baseline
alignment isn't what you want.
AmeliaBR: Agree with TabAtkins that way to do it that the child
declares it rather than figure out how to have parent
refer to which child
Rossen: Multiplicity?
AmeliaBR: First child that says baseline priority if first and last
child with last
Rossen: Intent of feature is select a specific
AmeliaBR: You select by setting property on child element
fantasai: Yes, makes sense
TabAtkins: You don't declare on everything, you put it on the one
thing you want the baseline to come from and that's what
you get

dbaron: What if author wants something high priority for first but
not last?
fantasai: Interesting. Should let them do it. Maybe set separately
for first and last baseline
AmeliaBR: Or what if you want to align with last line of heading? I
don't know.
AmeliaBR: Probably need to think through full proposal

which is the same sort of issues except images exporting
baselines.

fantasai: What I'm hearing is interest in doing this. Proposal
should deal with cases for different elements setting
first and last baseline and cases where first baseline
isn't necessarily the first baseline selected
Rossen: At least to start with. More cases will come as we work. I
agree there's interest from group.

Rossen: Who will work? fantasai?
fantasai: I guess. I would appreciate people with comments and ideas
Rossen: General support in going forward with such feature. Sounds
like a natural extension to baselines and using more
and ideas
Rossen: Sound good?
fantasai: Yep

dauwhe: Is Brian on?
Rossen: I don't see on meeting
dauwhe: Might be interested because MathML work
Rossen: Definitely. Anyone interested should help fantasai

vertical-align syntax / canonical ordering
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5235

fantasai: Minor questions. We split vertical-align to 2 longhands
so made them relate like this.

fantasai: Questions. Added baseline-source longhand where it's
first or last. What's best canonical ordering of values?
fantasai: I put baseline-source then baseline-alignment then
baseline-shift. E.g. "first alphabetic 0.4em"
fantasai: If that seems fine we can close on that
<fantasai> vertical-align: first alphabetic 0.4em

Rossen: Thoughts?
Rossen: Sounds like your proposal makes sense
heycam: Reads nicely in that order. Don't remember specific needs
for these properties.

fantasai: Second question was normally we allow reordering of
keywords and values as long as can parse without
ambiguity. CSS align restricts position of first and last
with baseline keyword.
fantasai: Do we want to be consistent with css align or do we want
to allow reorder because in this context can parse either
way?
fantasai: I guess 3rd option is make it reorderable in align also
<fantasai> https://drafts.csswg.org/css-align-3/#baseline-values
heycam: In other properties is that also 2 separate properties or is
it within the one?
fantasai: Current alignment property is just one with no longhand.
Current is [ first | last] ? baseline
<fantasai> css-align - <baseline-position> = [ first | last ]?
baseline
fantasai: Do we match, allow arbitrary order in these, or loosen
alignment to allow reordering

Rossen: Can we do that?
fantasai: I think so. Would make invalid things valid. I don't think
lots of people use first | last especially since it
doesn't work in Chrome
Rossen: Not sure I would jump to that conclusion so quickly. Doesn't
sound benign
AmeliaBR: Change is to allow keyword to be in either order. Not
breaking anything but something that didn't work might work
fantasai: Yes
AmeliaBR: Fairly new property so I don't think big web compat risk
Rossen: Is that based on data or feelings?
AmeliaBR: Feelings. And we warn people about zombie css and do not
guarantee that something with no affect before is always
no affect
fantasai: And first | last don't work in chrome so no reason to try
and use it there

Rossen: We have canonical ordering. Do we allow value reordering and
do we expand to align. That's the progression. Let's decide
vertical-align first.
fantasai: Preference is lean toward consistent, otherwise no opinion.
Rossen: If align wasn't there is there a reason to disallow
reordering
fantasai: No
Rossen: So for vertical-align want to allow reordering
Rossen: We can resolve on this and then figure out if we can extend
to align. Sounds like we feel fine without data but this is
new and ideally doesn't break

Rossen: With that we have 2 resolutions
Rossen: Anyone think we should go the other way? Keep them strict
without re-ordering?
Rossen: 2 resolutions.
Rossen: The canonical order, vertical-align: first alphabetic
0.4em...record that?
Rossen: Okay. Canonical is first, alphabetic, shift
florian: As spec currently?
fantasai: Yeah
Rossen: Objections?

RESOLVED: Canonical is source, baseline, shift

Rossen: We want to allow reordering of values for vertical-align
Rossen: Objections?

RESOLVED: We want to allow reordering of values for vertical-align

Rossen: Third: In order to keep vertical-align and align similar we
want to allow reordering of values for align property
Rossen: Objections?

RESOLVED: In order to keep vertical-align and align similar we want
to allow reordering of values for align property

fantasai: One more on this. Normally when have longhand/shorthand we
allow all values of longhand to be part of shorthand
fantasai: Initial value of baseline-source is auto. Do we want that
initial value to be allows in vertical-align shorthand? It
is initial value so no need to be specifiable. If it is
explicitly and we add auto to alignment-baseline that's
not parse-able easily
fantasai: Might be a reason to disallow. Don't lose capability and
opens possibility to auto value
florian: So when you mean auto you omit the value
fantasai: Yes
[This is also how it will be serialized anyway due to shortest
serialization]
fantasai: I don't think it's a big deal. I have a slight preference
to omit in case it's useful in future since auto is
general keyword
florian: Easier to add than remove so let's do what you suggest and
we can add it back if we change our mind
Rossen: Fair. Other reasons to keep it by anyone?
<dbaron> that sounds good to me
Rossen: Objections?

RESOLVED: auto value of baseline-source not allowed in
vertical-align shorthand

'vertical-align: middle' on table cells
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5234

fantasai: Has top keyword and bottom keyword which are special
because don't work off baseline. They shift based on total
linebox size.
fantasai: Also has middle which is x-middle baseline and aligns to
x-middle of parent. Same as alphabetic
fantasai: We also have vertical-align top, middle, bottom all behave
completely unrelated to inline layout and they are
basically start, center and end. By splitting to longhand
it means we have to map to magic. Middle is part of
alignment-baseline and top and bottom are line relative
fantasai: Can spec vertical-align: top middle on a table cell. What
does that mean?
fantasai: I prefer top and bottom take precedence
<dbaron> sounds fine to me

AmeliaBR: Did debate recently about which longhand top and bottom go
to. One solution is move them into other longhand to solve
this one issue
AmeliaBR: It would mean that alignment-baseline controls table
alignment because that makes no less sense than anything
else
florian: Think we had reasons to put in longhand we picked
fantasai: Because not possible to combine top or bottom with shift.
Can in theory with everything else
anyone else does
florian: To extent we keep in this longhand your proposal seems
reasonable. Should they be moved is separate
fantasai: Right, anyone who wants can re-open that issue and tag for
discussion
fantasai: This top and bottom take precedence over middle

RESOLVED: top and bottom take precedence over middle

vertical-align: super and font metrics
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5225

fantasai: Maybe should have Jonathan.
fantasai: 3 questions on this.
fantasai: Background is current implementation of super and sub
script are not dependent on font metrics, use UA ratio
fantasai: Second point is there are font metrics for super and
subscript. Third point is they are not particularly
reliable
fantasai: Should spec allow, disallow, or require using font
metrics? Require I don't think we can do reasonably

dbaron: Gecko seems to use font metrics.
dbaron: Cross platform code calls into font metrics code to get
super and subscript metrics. I haven't looked into specifics
of what they return
fantasai: Spec allows but doesn't require it. If that's fine leave
spec as-is
Rossen: That'll satisfy the halfway solution dbaron described or the
full solution
dbaron: Dug in further. We hard code these to 0.2 x em height for
sub and 0.34 for super.
<dbaron> https://searchfox.org/mozilla-central/search?q=_OFFSET_RATIO&path=&case=false&regexp=false
<dbaron> or more precisely,
https://searchfox.org/mozilla-central/search?q=NS_FONT_%5BA-Z%5D*_OFFSET_RATIO&path=&case=false&regexp=true

dauwhe: There are places css is used which are not browsers which
would be pleased to use font information
florian: Source of concern. That it should be accessible, yes. If
you can get that with a keyword that does something
different in browsers is not great

fantasai: So question is do we want to allow browsers or impl to use
font metrics? If we're not requiring do we want to require
a ratio and get interop? If we're disallowing should we
spec a ratio?
fantasai: If not using font metrics should we add an ability to do
so?

heycam: Saw proposal about overriding metrics in @fontface rule
faceless2: That was myles. If solving solve for all.

AmeliaBR: Have a feature in font-variant that allows proper
typographic sub and superscript from font. So is a way to
access if you have a well defined font. Haven't played
with it.
fantasai: That one will pull out glyphs and synthesize them if font
doesn't have. Doesn't shift baseline so if you have nested
super or an image as a super that's not a pure glyph you
cannot do that
AmeliaBR: As an author it would be useful to be able to have
vertical-align:super do something nice and typographic but
I'd be very worried about backwards compat if we widely
change the standard html 1 subscript style
at https://wiki.csswg.org/faq#styling-sup-and-sub-using-font-variant-position
]

fantasai: Ratios aren't consistent but close
fantasai: One option is we could allow font metrics, don't require,
try and get alignment on the ratios.
fantasai: Then explore having the metrics spec via @fontface
faceless2: Solving without solving for superscript size is doing
half the job
fantasai: That's against Fonts 5
fantasai: You want to file it?
faceless2: I think it's best solved in fontface rule
fantasai: But you have to be able to access the size. vertical-align
is only about baseline position. If you want to be able to
size it you have to add to fonts 5 as separate issue.
faceless2: Yeah. I'll put a note

fantasai: Proposal: leave spec with a may, look into asking impl to
align on fallback ratio, allow investigation of
descriptors via font face
florian: Question, what we expect impl to do with the may is by
default link to a fixed ratio and have an allow list of
fonts with useful metric and use that if someone
fantasai: Seems like
florian: If we don't give guidance I wonder if people won't start to
use metrics from fonts or cause more problems where I put
something which looks wrong in Chrome and I corrected
fantasai: Author can always use explicit length or percentage. If
they wanted something precise they can do that
Rossen: Any time we define anything as may we define may have
problem for authors
florian: Seems safe if we assume default is ratio and you opt in to
better, if it's it that it's fine. If it applies in bad
fonts for some browsers it will be weird.
fantasai: Maybe suspend until myles gets back
florian: I'm hinting at it's fine but adding a note what the may is
for and that people should be careful when impl
fantasai: If you want to propose text that's fine
florian: I'll do that and run by myles
Rossen: We can record resolution, myles can read and reopen when he
comes back.

Rossen: Progression of fantasai's suggestions makes sense. Can't
disallow so we need at least a may
Rossen: Aligning on ratios that are as interop as possible is great.
Rossen: Already a number of posts in issue from impl that desc how
they get ratios. Encourage more of that so we can come down
to something same.
Rossen: First resolution should be leave vertical-align super and
sub as a may
Rossen: Objections?

RESOLVED: Leave vertical-align super and sub as may use font metrics

Rossen: I don't know that we can have a resolution about ratios
without actual ratios
fantasai: Yeah
Rossen: Leave that open
fantasai: Okay
Rossen: Last one is with @fontface
fantasai: I think font face descriptor for metrics should include
super and subscript size and position and allow opting in
to use font metrics
Rossen: Sounds good. Objections or comments?

RESOLVED: Font face descriptor for metrics should include
superscript and subscript size and position and allow
opting in to use font metrics

<break type=short>

<dbaron> If we want that descriptor to be able to override the
"fixed" values in browsers, we might want the spec to say
that sooner rather than later (i.e., before the descriptors
get implemented).
<fantasai> we just resolved on that, I thought

Rossen: Time to restart
Rossen: Time check, 40 minutes remain

fantasai: Back to previous issue we have data from impl (thanks
everyone)
fantasai: [lists ratios used by each browser]
fantasai: All slightly off but fairly close
fantasai: I propose 0.2em and 1/3em and put that in spec
florian: +1px seems very specific
koji: I checked commit log and added hyatt. So it's old code
florian: In that case sure
fantasai: Proposal 0.2em and 1/3em. Slightly different but very
close for everyone
Rossen: Thoughts or objections?
koji: Do we have myles?
Rossen: 12 more minutes [before he can join]
fantasai: Safari is using 0.2005 and 1/3em
faceless2: That was me measuring on screen so not gospel
Rossen: As any other decision we can change our minds
Rossen: Would be reasonable
Rossen: Objections to 0.2em and 1/3 em are the ratios for super and
sub script?

RESOLVED: 0.2em and 1/3 em are the ratios for super and sub script

vertically align to middle of cap height
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4707

fantasai: Proposal is defer to next level
fantasai: Lovely diagram for the problem. They don't have quite
right font metrics because x-middle is not middle of cap
height.
fantasai: 2 things going on here that make me want to defer. Adding
cap-middle is easy. Couple of concerns. Cap metrics not
particularly reliable
fantasai: Also we have a central baseline that tends to coincide
with cap middle already. Possible central baseline will
solve when implemented for many purposes
fantasai: Last reason to defer is we have same problem, not just
western but other writing systems. We have an issue that
most writing systems besides western and cjk don't have
the metrics to do the sizing in inline layout and we don't
have a solution to that
fantasai: My inclination is try and defer until we can solve
worldwide problem to get top / bottom / middle for every
writing system. I don't know what it will look like
fantasai: Given that current implementation of central will get you
close and we want to solve for all writing systems I
propose we defer cap middle until more context on 5244
florian: That's with understanding it's possibility central baseline
will solve it?
fantasai: Yeah

Rossen: Agree with use case and problem. Will revisit once central
baseline is solidified and see what else is needed
fantasai: Yeah. Central baseline is solid but needs implementations
Rossen: Okay. Anything else on this?
fantasai: That's all

CSS Text
========

letter-spacing should not apply to the end edge of a line/span?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1518

koji: css 2 spec says letter-spacing is added between characters
koji: No implementation does it. Blink and webkit adds to right of
character
koji: Gecko adds to inline-end of character in resolved direction
koji: Commonly asked question on web when they want to center or
right align or when they want to put borders on underlines
koji: For alignment if we use negative margins, lots of hacks
koji: Proposing solve this by a switch on the property
fantasai: I would like to investigate more web compat of doing
things right. Hasn't happened yet. Agree undefined for L3.
I think don't add a switch at this point in time
<dbaron> I think we'd like to switch to doing it right eventually;
doing it just hasn't been a priority.

florian: If you want to use letter-spacing for purpose of
letter-spacing, what is specified is good. It has been used
for other cases, though. Because of that we're to some
degree locked into behavior
florian: In earlier discussion fantasai suggested we define some
bits and look at switch for next level. I think koji wanted
entire undefined.
koji: I thought fantasai wanted to define it but she said she's fine
to undefine. I think for L3 we are in consensus to undefine

koji: L4 it looks like not consensus. I think we should add the
switch and fantasai doesn't want
koji: fantasai any reason you don't want switch?
fantasai: I want to figure out what web compat constraints are to
see how much we can fix and how much has to be a switch. I
as to what that ought to look like
<tantek> +1 figure out webcompat constraints
florian: All agree some aspects can't work nice way. Not clear all
aspects must stay as implemented. Maybe some could switch to
better without breaking pages.

chrishtr: This property has high use on web according to use
counters. Half of all web page loads. Will change layout
and break or move content around.
chrishtr: This issue has been pending for 2 or 3 years now. In
theory it's possible there could be a way to make a change
to all browsers behavior without breaking web no one has
put in work to prove that in 3 years.
chrishtr: More practical way forward is new aspect to property to
allow sites to opt in to internal characters getting
spacing. That's actionable thing we can do
<AmeliaBR> letter-spacing: 0.1em trim
fantasai: While so many sites use letter-spacing, most are not in a
way where compensating for this bug. Most of them use it
normally and not notice rendering is slightly off. Fixing
in general makes these sites work as author intends.
Possible some sites where switching can cause break. But
we would fix others.
fantasai: I don't think usage says 50% of websites will break.

dbaron: 2 things. Gecko behavior is substantially different from
Chrome. We occasionally get an issue from a dev but I don't
remember us facing breakage for this
dbaron: That makes me think there may be room to do without compat
problems
dbaron: Other is since letter-spacing is old it may be in reset
stylesheets. Interesting is how many are something other than
letter-spacing normal or 0

florian: If we define as undefined in L3 and worry about it in L4
that lets us do either. If we define as Chrome it locks us
in. If we undefine for now maybe we can do better later.
koji: To dbaron's statement we have got this request in bug reports
18 years ago and 18 comments. 18 is not low and 3 are from
this year.
* fantasai didn't catch what the bugs were
koji: It is a feature people want to fix and people waiting at least
18 years. Want to solve
koji: 18 are asking for remove the spacing at last
chrishtr: No spacing at end of span

fantasai: We're proposing fix this and not a switch. Concern from
Chrome is web compat and not shippable
koji: Yeah
chrishtr: And prove no impact is a lot of work we'd rather not do
because skeptical will succeed
fantasai: Gecko is willing to ship. If they ship in nightly and
decide compat is not issue would Chrome ship?
chrishtr: With evidence of web compat yes
koji: Concerned Gecko has different policy. They resolve regression
bug as fixed when change and we have strict policy to avoid
regression. If we search for letter-spacing and center it's
most common and people use it a lot to make sure that
letter-spacing title is centered correctly. Change will break
all those pages

myles: In our new layout engine we have implemented this. Just
haven't turned on new engine by default. In middle of
progress here
Rossen: Make sure I understand you believe this will be web compat
and just make the change?
myles: Our impression is that we are going to try and make the
change and if not web compat we'll back out. We're going to
err on side of changing
koji: Timeframe?
myles: Apple does not comment on future products or releases

florian: Questions to WebKit and Mozilla. If we spec undefined for
now would that slow interest in experimenting?
florian: I'm very interested in if some degree is doable, but not
convinced we can wrap up in time to take Text 3 to CR. Does
disappearance of text cause you to give up on experiment?
dbaron: I think it should be findable from spec if you want it impl
fantasai: What if left current definition as a may and say you may
do something else? It's not undefined but it's a may.
dbaron: That's findable from spec.

chrishtr: I don't see down side of having another option. Make it
undefined with the default settings and you could opt into
only the internal edge mode and still have a possible
future change to all browsers if it's compat to make the
default that
florian: That's kind of what we're saying. We're making it
effectively undefined now. May have a switch later. When we
refine what undefined means we can add the switch
chrishtr: Want to solve for webdev now not in a year. It's a small
change, is it that big of a deal?
florian: Too many problems with legacy and normal
fantasai: If we add things now that we only need temporarily it has
to be maintained forever and webdev have to carry
knowledge. Makes sense to wait 6 months to get it right
chrishtr: Don't believe it's a significant burden for developers.
This is a small thing

chrishtr: To makes sure I understand the core concern. I think that
you would like the default to switch if possible to make
website behave in great way by default
florian: Depending on nuances in that phrase, yes
chrishtr: I agree that is a good thing to aim for. But it hasn't
been achieved in this case. Lots of usage and evidence
it's risky. Without a lot more work and research don't
think can ship in Chromium
florian: I think future you suggest is letter-spacing growing a
keyword, something like a length and either auto or
nice-typography and there's a chance in a year or 3 where
we say both is same
koji: Not legacy. fantasai conformed we will need it for the middle.
We will need a switch. Correct fantasai?
fantasai: I'm not convinced we need a switch. I think it's possible
and reasonably likely. Main reason I think so is some of
the examples I've seen. But I'm not really... only reason
we need a switch is compat. No reason if not for compat.

fantasai: Only reason to have a switch is for compat. Lots of
switches between previous and current isn't good for css
koji: You're saying it should change to padding?
fantasai: I think it should be with margin and maybe add a better
facility for manual kerning that solves the problem better.
florian: Margin is better even without something for kerning
<faceless2> can you have a switch to enable compat mode, but with a
prefix?
koji: What to do with existing cases?
fantasai: We might be stuck with this being one sided. But then
switch would not affect end edge, only end of element.
I just think that interest in forward momentum from 2
implementors to fix it. I think we should see if
that works

myles: That's what I was going to say. 2 implementors in process of
implementing. If I understand from chrishtr you don't have
evidence it's not web compat. Given that it seems a natural
way forward. A compromise of adding both as a may is okay
with us
florian: For compat there is evidence some sites break. Not a clear
analysis of if they can be isolated to limit breakage or if

Rossen: Point of order, 12 minutes to the end.

Rossen: Something chrishtr mentioned that this is small. At the end
of day this is an API adding to the platform. It is adding
complexity which may be unnecessary. We have a general
principle against that. Question for chrishtr and koji where
you have proposal of switch - isn't doing so going to give
you the behavior we believe should be there by default?
Rossen: So are we talking about a run time switch or experimental
switch and not a css property so you can flight and test
overall impact?
Rossen: In other words when you implement this switch aren't you
going to arrive at desired implementation anyway, and
couldn't that be behind a field trial switch?
chrishtr: Could but something would need to be done after to analyze
if turning on switch breaks sites
Rossen: But when you impl you add desired behavior. At which point
you have great data, which is you impl it by default. If
flighted this a bunch broke, then in order to address pain
of dev can release with a switch

chrishtr: I think proposal is impl the change behind and experiment
flag, attempt to ship, and if anyone complains turn it off
Rossen: Yes
chrishtr: Have in past with things we think will work.
chrishtr: When we don't have evidence it is likely to be not a
problem we don't want to do that. It's a PITA for sites to
have to deal with it
chrishtr: Only in cases where we have evidence it's not a problem
would we be willing to do that
<fantasai> authors > implementers
chrishtr: Or if the situation at hand is very severe. Sometimes with
security we might do something like that because security
is bad enough we'd break sites. This case is not anything
like that. There's a whole bunch of people that use
Chromium based browsers we have to worry about. That would
be a lot of analysis, whereas a property switch is trivial
chrishtr: Switch seems more practical and if data comes in later
that it doesn't matter we can change the default. I wish
web was different on centering it's not

Rossen: To finish the question. From 3 values in proposed switch,
auto between and right, is between the one we aspire to have?
chrishtr: Yes
Rossen: We would have said just impl between if we started today?
chrishtr: Yes, just think auto and between
Rossen: So you said switch is simple so implementing between is
simple.
Rossen: Great. So back to my question if implementing between is
simple why can't we flight and test compat just like Firefox
and new WebKit is willing to do. If you say nope breaking
too much and we want to add the switch that's easy convo
chrishtr: Because doing so forces the change and makes sites file
bugs or do detailed analysis of existing sites

myles: Third choice is wait for FF and webkit and see what they have
to say
koji: fantasai said we don't need right only once every site has
switched to use padding for kerning
chrishtr: Is Mozilla planning to ship in next release?
fantasai: Talked to Jonathan and plans are for soon. Next release or
two should be possible.
Rossen: So that's 6-12 week time frame roughly.

fantasai: I would like to wrap this up and say we resolve to allow
both for text L3. You may do the thing specified so far
and you may do something else so we can close for L3. Open
separate issue on L4 for if there should be a switch.
chrishtr: Seems clear won't resolve on switch in this meeting so
letter spacing?
fantasai: I think not relevant for this discussion.
chrishtr: Fork to new issue as well?
fantasai: German uses spacing for emphasis and the commenter wants a
tag for that, and that's not in scope for CSS. That's an
HTML issue.
astearns: Issue for us is if spacing features we give are inadequate
for German
AmeliaBR: What's the standard typographic behavior for German and
can it be represented in CSS
[no because of this bug]

this
Rossen: Objections to that?
florian: I think resolve on that. It's not last work but we'll stop
banning the current behavior
Rossen: Objections to Change Text L3 to a may for the behavior and
transfer switch discussion to Text L4

RESOLVED: Change Text L3 to a may for the behavior and transfer
switch discussion to Text L4

Rossen: Thank you for calling in. Not all discussions are easy but
they are fun.
Rossen: No call tomorrow
Rossen: We are going to reconnect on Thursday at 7amPT
Rossen: Thanks for calling in!


## RE: [EXTERNAL] Some charter changes

Source: public-mathml4@w3.org Mail Archives • Murray Sargent (murrays@exchange.microsoft.com) • August 07, 2020 • Permalink

Good changes. I think math search can be a fuzzy search: that is, false positives for the more obscure searches are okay. You need to be able to recognize equations independently of the variable names. You’ll be able to find K-14 math pretty reliably. And it might be useful for more advanced math as well. You need to convert math text on the web in all popular math formats to an efficient canonical format that the search data base uses. The approach needs to be integrated into web search engines.

Thanks,
Murray

From: Neil Soiffer<mailto:soiffer@alum.mit.edu>
Sent: Thursday, August 6, 2020 7:52 PM
To: public-mathml4@w3.org<mailto:public-mathml4@w3.org>
Subject: [EXTERNAL] Some charter changes

Based on the meeting today, I have made a few wording changes to the charter. In particular...

1. The intro text was modified to focus on the three goals identified for MathML needs to be useful for: presentation, accessibility, and searchability. The later point probably needs more text describing what is meant by "searchibility". Note that computability is *not* on that list.

2. That success means authoring tools actually generate and consume semantics. I expanded the existing bullet point about 'using core' in the success criteria to be all the new features. I'm not sure that emphasizes the point some were making in the call this morning, so please suggest more text if you feel it is needed.

Neil


## Some charter changes

Source: public-mathml4@w3.org Mail Archives • Neil Soiffer (soiffer@alum.mit.edu) • August 07, 2020 • Permalink

Based on the meeting today, I have made a few wording changes to the
charter. In particular...

1. The intro text was modified to focus on the three goals identified for
MathML needs to be useful for: presentation, accessibility, and
searchability. The later point probably needs more text describing what is
meant by "searchibility". Note that computability is *not* on that list.

2. That success means authoring tools actually generate and consume
semantics. I expanded the existing bullet point about 'using core' in the
success criteria to be all the new features. I'm not sure that emphasizes
the point some were making in the call this morning, so please suggest more
text if you feel it is needed.

Neil


## Minutes: MathML General Meeting, 6 August 2020

Source: public-mathml4@w3.org Mail Archives • Neil Soiffer (soiffer@alum.mit.edu) • August 07, 2020 • Permalink

There was an interesting and lively discussion today. Unfortunately, we
couldn't capture all of it in the minutes. There is no recording for
today's meeting.

Attendees:

Neil Soiffer

Deyan Ginev

Sam Dooley

Louis Maher

Murray Sargent

Patrick Ion

Bruce Miller

Moritz Schubotz

Regrets: David Farmer, David Carlisle

MathML WG Charter: comments, suggestions, etc

MS: I’m happy to see the progress with Core, but I’m concerned the
semantics work is not mature enough to put into a standard.

MS: Not clear how the new standard conflicts with content MathML. We
shouldn’t have two ways to do things.

SD: Semantics is more like an upgrade path from content MathML. So it
becomes a functional replacement for content MathML 4.

NS: Could say we should eliminate Chapter 4 since it is a duplicate?

SD: There is a lot there. I’m not sure about that. The syntax is not the
important part, it is content that matters.

[discussion of how open math and content math relate]

BM: Possibly in the long run, content MathML could be deprecated, but only
if the developing attribute format becomes sufficiently expressive and
successful. I am not sure if semantics is expressive enough to get rid of
content MathML, particularly since we’re still grappling with speech vs
computation distinctions.

NS: There is strict and pragmatic content, and semantics is aimed at
pragmatic mathml.

BM: There was a lot of work in MathML 3 to show how pragmatic maps to
strict. I think people should be aiming at strict, not pragmatic.

DG: There is a research project (MathWebSearch) that uses “strict Content
MathML” to index 500 million formulas from arXiv, also some experiments
with ZBMath. It’s a huge index, but generally not online / not a production
deployment. Has a “more academic” status, well-known in the (modest) Math
Information Retrieval community.

[more discussion on the discussion of differences between strict and
pragmatic]

BM: I could see a few steps down the road deprecating pragmatic. We
shouldn’t put up barriers between the various forms (ie. pragmatic, strict
and semantic-attributes should be compatible).

MS: the ability to map to something else is what makes it so useful because
math is not fixed. It makes it easier for accessibility because there is so
much less.

[not captured]

DG: Scope depends on the application. For presentation MathML, it is if
browsers render this, we are done. For speech and other applications, what
determines what is done?

[not captured]

SD: people just care about appearance. Presentation works for them. Others
want to specify semantics. There is a sweet spot where they want both for
some common things. I think we should support all three communities.

MS: I agree that content MathML has remained very academic. It was very far
from being used.

BM: I think it is a false dichotomy (between being able to express the
simple cases simply and still handle more complex cases) that it is an all
or nothing enterprise. There is a slice of openmath that is very generic.
Coming up with a list that is short enough to find it easily and having a
complete enough list. WIth OpenMath, you spend days looking for something
and never finding the symbol…

MS: Who will be creating MathML output. Most people use TeX to create math.
That is then converted to MathML. They won’t write presentation MathML
directly. If it is generated by a program, why is it easier to generate?

SD: from experience, it is much easier to generate semantics than both
contents and presentation.

NS: it is locally generated for each construct, rather than globally
generating two trees.

PI: we are generating a new markup that might be easier to maintain, but it
is not clear that the details are as complex as before. Sam did this and
I’ll have to take his word that it is easier. I agree with Deyan that the
target audience is important.

DG: I claim that there are different representational decisions for
different applications, and we have several for Content MathML. It is
different for a11y on the web than for a notebook that wants to do
computation. Similarly there are differences between inputting TeX syntax
and using a palette-based input such as MathQuil. We should list the
applications we are aiming to facilitate, and not make claims about
applications we have not thought of yet.

NS: I agree. This should go into the charter in success criteria.

BM: We should focus on what we want to and not focus on things we aren’t
interested in.

SD: For example, I want to deal with online testing and capture enough
semantics so I can score the result.

BM: If it can do K12 and still be expandable, that’s a win-win.

MS: We need three things: presentation, accessibility, and search.

PI: That’s my list.

DG: We need to discuss intended input methods (e.g. not by hand, yes by
TeX, Office, palette widgets in javascript). We should specify that in the
spec.

Summary:

1.

Charter should mention goals of presentation, accessibility, and search
2.

Charter should mention that input needs to be supported (from at least
TeX and WYSIWYG). Not decided is how many implementations mean that we
succeeded.

Mid-meeting note from DG: The big problem with adoption of Content MathML
is connected to the academic approach to the spec, which wasn’t close to a
wide community of practitioners. It was indeed closer to CAS systems. We
know it wasn’t successful because no one is publishing new Content
Dictionaries. Finding a way to avoid the block that is incurred by
requiring CDs is crucial to future adoption of a content standard, in my
opinion.


## Re: Reminder: MathML Semantics meeting, Thursday, 6 August

Source: public-mathml4@w3.org Mail Archives • Neil Soiffer (soiffer@alum.mit.edu) • August 06, 2020 • Permalink

Those are all good things to add. I certainly hope we can obsolete the
MathML note that says to use class="MathML-unit" once we have a semantics
proposal.

Re chemistry: I was on the Chem CG call this morning and requested that
they come up with "semantics" for chemistry. They previously did a bunch of
work to narrow down the subject areas needed to disambiguate chemistry from
math, so they have a start on what the targets are they need to identify.

Neil

On Thu, Aug 6, 2020 at 7:38 AM Deyan Ginev <deyan.ginev@gmail.com> wrote:

> Thanks for starting that list Sam and Neil!
>
> I would volunteer the following notable names for consideration in our
> meeting discussion, as possible extensions. It may help to draw
> contrasts to your pragmatic cMML list and quickly reject/accept types
> of names, so that we figure out what gives a name the right to "go in"
> vs stay out of the level 1 list of meanings:
>
> 1. all SI units and imperial units
> 2. other notable K12 constants from STEM e.g.
>  - chemistry: all atoms from the  table of elements, molecule,
>  - math: geometric constructs (angle, segment, point)
> 3. notable K12 operators from STEM e.g.
>  - chemistry: reaction arrows
>  - math: different kinds of intervals (open-closed, closed-open),
> geometric relations (parallel to, intersecting), piecewise function
> definitions
>  - more math: modulo, divisible by
> 4. notable K12 properties from STEM e.g.
>   - chemistry: "positive/negative ions" (usually denoted via
> msup-plus, msup-minus over an atom base))
>   - physics: the little arrows denoting "force", e.g. \vec{F}
>
>
> Of course I don't expect us to cover the entire K12 curriculum's
> concepts in an initial list, and likely there is a good argument to be
> with hundreds and then thousands of concepts that are not normative.
> I'm curious to hear how everyone is thinking about conceptually
> separating the levels, and about the degree to which the group would
> have a burden to maintain these lists going forward. I could also
> imagine "blessing" an external resource as a source of provenance for
> these names, e.g. "any official meaning literal must have a wikipedia
> page/wikidata resource". As a reminder, my main focus is coverage, as
> my main application scenario is enriching arXiv, so apologies that I
> keep drifting to the topic of maximizing breadth.
>
> Greetings,
> Deyan
>
> On Tue, Aug 4, 2020 at 8:58 PM Neil Soiffer <soiffer@alum.mit.edu> wrote:
> >
> > We meet again on Thursday, 6 August at 10am Pacific, 1pm Eastern, 7pm
> Central European Time.
> >
> > Agenda:
> > 1. Charter comments, suggestions, discussion
> > 2. Sam and I have created an initial list based on pragmatic MathML
> >    a) Discussion of how the list was created, etc
> >    b) Are more fields needed/existing fields need changing?
> >    c) What should be removed (some are clearly not appropriate)?
> >    d) What should be added?
> >    e) Names -- naming scheme and do we want to keep some content MathML
> names (e.g., "lt" or spell out as "lessthan")?
> > 3) Continued discussion on "semantics"
> >
> > The zoom meeting link is the same one we used last week. Hopefully the
> calendar invite doesn't have any more hidden bad links. Due to zoombombing,
> I can't send it out to the public mailing list. If you would like to join
> and don't have the link, please send me email at least 10 minutes before
> the meeting.
>


## Re: Reminder: MathML Semantics meeting, Thursday, 6 August

Source: public-mathml4@w3.org Mail Archives • Deyan Ginev (deyan.ginev@gmail.com) • August 06, 2020 • Permalink

Thanks for starting that list Sam and Neil!

I would volunteer the following notable names for consideration in our
meeting discussion, as possible extensions. It may help to draw
contrasts to your pragmatic cMML list and quickly reject/accept types
of names, so that we figure out what gives a name the right to "go in"
vs stay out of the level 1 list of meanings:

1. all SI units and imperial units
2. other notable K12 constants from STEM e.g.
- chemistry: all atoms from the  table of elements, molecule,
- math: geometric constructs (angle, segment, point)
3. notable K12 operators from STEM e.g.
- chemistry: reaction arrows
- math: different kinds of intervals (open-closed, closed-open),
geometric relations (parallel to, intersecting), piecewise function
definitions
- more math: modulo, divisible by
4. notable K12 properties from STEM e.g.
- chemistry: "positive/negative ions" (usually denoted via
msup-plus, msup-minus over an atom base))
- physics: the little arrows denoting "force", e.g. \vec{F}

Of course I don't expect us to cover the entire K12 curriculum's
concepts in an initial list, and likely there is a good argument to be
with hundreds and then thousands of concepts that are not normative.
I'm curious to hear how everyone is thinking about conceptually
separating the levels, and about the degree to which the group would
have a burden to maintain these lists going forward. I could also
imagine "blessing" an external resource as a source of provenance for
these names, e.g. "any official meaning literal must have a wikipedia
page/wikidata resource". As a reminder, my main focus is coverage, as
my main application scenario is enriching arXiv, so apologies that I
keep drifting to the topic of maximizing breadth.

Greetings,
Deyan

On Tue, Aug 4, 2020 at 8:58 PM Neil Soiffer <soiffer@alum.mit.edu> wrote:
>
> We meet again on Thursday, 6 August at 10am Pacific, 1pm Eastern, 7pm Central European Time.
>
> Agenda:
> 1. Charter comments, suggestions, discussion
> 2. Sam and I have created an initial list based on pragmatic MathML
>    a) Discussion of how the list was created, etc
>    b) Are more fields needed/existing fields need changing?
>    c) What should be removed (some are clearly not appropriate)?
>    d) What should be added?
>    e) Names -- naming scheme and do we want to keep some content MathML names (e.g., "lt" or spell out as "lessthan")?
> 3) Continued discussion on "semantics"
>
> The zoom meeting link is the same one we used last week. Hopefully the calendar invite doesn't have any more hidden bad links. Due to zoombombing, I can't send it out to the public mailing list. If you would like to join and don't have the link, please send me email at least 10 minutes before the meeting.


## Re: Minutes: MathML Core Meeting of August 3, 2020

Source: public-mathml4@w3.org Mail Archives • Frédéric Wang (fwang@igalia.com) • August 05, 2020 • Permalink

On 04/08/2020 01:49, Neil Soiffer wrote:
> There are 28 MathML Core issues with "needs resolution"

FWIW, I don't know if "needs resolution" correspond to the highest
priority or is actually up-to-date. Also I think someone (from W3C?)
said we shouldn't use this kind of label. The thing is that I used to
put this label by default, but probably didn't always remove it e.g.
when we decided not to put it in core level 1 (as we could come back to
this in the future).

Anyway I think now core is in relatively good state, the issue labels on
the spec corresponds to think we can't decide immediately in the group ;
we should wait upstream work and CSS/WHATWG discussions. BTW, there was
upstreaming, so I wonder whether level 1 should simplify it even more
(or remove it).

--
Frédéric Wang


## Reminder: MathML Semantics meeting, Thursday, 6 August

Source: public-mathml4@w3.org Mail Archives • Neil Soiffer (soiffer@alum.mit.edu) • August 05, 2020 • Permalink

 We meet again on Thursday, 6 August at 10am Pacific, 1pm Eastern, 7pm
Central European Time.

Agenda:
2. Sam and I have created an initial list based on pragmatic MathML
a) Discussion of how the list was created, etc
b) Are more fields needed/existing fields need changing?
c) What should be removed (some are clearly not appropriate)?
e) Names -- naming scheme and do we want to keep some content MathML
names (e.g., "lt" or spell out as "lessthan")?
3) Continued discussion on "semantics"

The zoom meeting link is the same one we used last week. Hopefully the
calendar invite doesn't have any more hidden bad links. Due to zoombombing,
I can't send it out to the public mailing list. If you would like to join
and don't have the link, please send me email at least 10 minutes before
the meeting.


## Interest in a virtual face-to-face meeting at TPAC?

Source: public-mathml4@w3.org Mail Archives • Neil Soiffer (soiffer@alum.mit.edu) • August 04, 2020 • Permalink

The W3C is having a virtual TPAC (Technical Plenary and Advisory Committee)
meeting this year [1]. As mentioned in email and meetings, a goal is to
have MathML Working Group Charter ready to discuss with other groups by the
meeting. The meeting is spread out over two weeks; attendance is free. The
first week (Oct 12-16) is for committee meetings. A second week (Oct 26-30,
14:00–15:00 UTC) is for breakout sessions and that is where I hope we get
other group members to join in a discussion of the WG Charter and get their
feedback.

For the first week, it is a chance for this community group to have a
virtual face-to-face and do a deep dive into one or more topics. I want to
gauge interest in having such a meeting and have created a doodle poll
<https://doodle.com/poll/ev9kt69dk7wuyihg> where you can indicate what
times will work for you. I have created two blocks each day, with each
block being three hours. If you are interested in a face to face meeting,
you are interested in.

*I will close the poll on Thursday (Aug 6)*, gather up the suggestions, and
then do another poll with the most popular times and suggestions to gauge
whether we should have 0, 1, or 2 blocks of meetings.

Neil

[1] https://www.w3.org/2020/10/TPAC/Overview.html


## Minutes: MathML Core Meeting of August 3, 2020

Source: public-mathml4@w3.org Mail Archives • Neil Soiffer (soiffer@alum.mit.edu) • August 03, 2020 • Permalink

Attendees:

-

Neil Soiffer
-

Brian Kardell
-

Murray Sargent
-

Bruce Miller
-

Louis Maher
-

Rob Buis

Regrets:

-

Patrick Ion
-

David Carlisle

Agenda:
https://github.com/mathml-refresh/mathml/issues/8#issuecomment-667748594

The meeting was recorded:
https://benetech.zoom.us/rec/share/_51HdovZ5G5IaIXD6WDue5ElOpngT6a813Aa_aIJmEgvzBIDP3wMm0DINZu35Ome

Charter:

-

We created a very basic starting point (not even a 'first draft') of  MathML
WG charter
please have a look, comment, contribute
-

NS: Fred had some concerns on the decision making part, that we don't
specify browser buy-in.  I think that the process of W3C is going to
enforce that, but I don't know. Moritz also had concerns but I don't
entirely understand them. I hope they will join a call to allow
for higher
bandwidth discussion.
-

BK: people have different feelings. Probably three different things:
mathml core, what you can usefully do with known popular
non-browser tools,
or things we hope will be done someday or some more obscure tools. On the
latter there are a lot of good ideas, speculation, and just theorizing.
This is why I suggested that we should get started on the charter sooner,
rather than later, because if we aren't careful things can spiral out of
control and some folks are going to be concerned about that.
-

deprecated
-

NS: Times have changed in terms of how specs are written, and perhaps
the charter could call out some examples about what will be
deprecated, but
we have to be careful not to make the charter the spec. There
are wordings
that need changing. I did notice that the WHATWG Processes also include
some examples, so we could potentially do that with the charter - careful
examples.
-

NS: Brian has some experience with other charters. Any other things
-

BK: CSS WG has recently realized that some of the things it says
aren’t true, where it speaks about how something works "by design". E.g,
text-transform and screen readers. These kinds of things where you talk
about a11y and aren’t the group that deals with a11y gets tricky. So I
worry about things that aren’t straightforward math in the
browser. That’s
why I didn’t write much about it in the charter. I don’t know
what needs to
be done or how to write about it.
-

NS: If we are going to have this ready for TPAC, we need to keep
pushing forward. So hopefully no more than two more weeks of
brainstorming,
then a few weeks of throwing out things that don’t fit or
clearly can’t be
accomplished, followed by some discussion of details/wording, and then
turning it over to some editors who will polish it/put it into
the correct
format/template/location for outside groups to look at/comment on. So

There are 28 MathML Core issues with "needs resolution"Consider integrating
scriptlevel into font-size #174
<https://github.com/mathml-refresh/mathml/issues/174> (anything new?)

BK: Rob checked and the WPT and implementations were updated to what they
thought Elika said and so those probably need changing. I’m going to be
opening issues with CSS this week.

Applying visual effects #179
<https://github.com/mathml-refresh/mathml/issues/179>

NS: what happens now?

RB: I don’t know

NS: Seems like we need to write tests and see what the implementation is
doing. Do they just flow through or do we need to have the UA stylesheet
for math reset some of them?

BM: Seems like we need more abstract language so we don’t have to list
every potential interaction. Probably requires someone with deep knowledge
of the web to know which things fall into what categories… if there are
different categories of effects.

BK: we need to know where it is special, such as creating a new stacking
context.

Custom MathML elements #138
<https://github.com/mathml-refresh/mathml/issues/138>

BK: This should be moved to level 2. They should be treated as unknown
MathML elements in Level 1.

Resolved: to move to core level 2.

Interoperable handling of invalid markup #15
<https://github.com/mathml-refresh/mathml/issues/15>

Non-normative note to spec to send message to console

BK: need to get Webkit or Gecko to agree because they do something
different.

[discussion of specs and tests]

BK: Firefox displays an error, Webkit hides the content, not even laid out
in an mrow. Someone should fact check. SVG renders nothing for invalid
subtrees in some cases. MathML is different because it is text.


## Re: Minutes: MathML general meeting 30 July, 2020

Source: public-mathml4@w3.org Mail Archives • Miller, Bruce R. (Fed) (bruce.miller@nist.gov) • August 03, 2020 • Permalink

On 7/31/20 2:48 AM, Moritz Schubotz wrote:
> Dear Neil,
>
> thank you very much for sharing the minutes and organizing the meetings.
>
>> -----Original Message-----
>> From: Neil Soiffer <soiffer@alum.mit.edu>
>> Sent: Friday, July 31, 2020 2:00 AM
>> To: public-mathml4@w3.org
>> Subject: Minutes: MathML general meeting 30 July, 2020
>>
>> NS: I will do a Google Sheet; we clearly have more on semantics; 2 more
>> weeks on charter comments, then we’ll nail it down to W3C standards.  Thank
>> you all
>>
> I am seriously concerned about this attitude. My goal is to improve MathML and support the adoption of the MathML standards, by publishers content providers. I also agree that improving accessibility and machine readability is what we should aim for. However, I think the current document focusses on implementation details without to clearly identify the current shortcomings of MathML3 and to show why the newly proposed implementation is sigificantly better.
> That said, I would propose to keep the document open until it is good.

I'm not sure what attitude you're referring to, but it would
discussions so that your concerns could be clarified and hopefully

bruce

> Best
> Moritz
>
> ------------------------------------------------------------------------------
>
> FIZ Karlsruhe - Leibniz-Institut für Informationsinfrastruktur GmbH.
> Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB 101892.
> Geschäftsführerin: Sabine Brünger-Weilandt.
> Vorsitzende des Aufsichtsrats: MinDirig’in Dr. Angelika Willms-Herget.
>
> FIZ Karlsruhe ist zertifiziert mit dem Siegel "audit berufundfamilie".
>

--
bruce.miller@nist.gov
http://math.nist.gov/~BMiller/


## Re: WG draft charter

Source: public-mathml4@w3.org Mail Archives • Neil Soiffer (soiffer@alum.mit.edu) • August 03, 2020 • Permalink

The W3C has a process <https://www.w3.org/2019/Process-20190301/#Reports>
for moving from Working Draft to Recommendation. It has changed over the
years and is not the same process as was in place when MathML first became
a recommendation. In the end, the committee puts forth a Candidate
Recommendation (CR) if the director approves, gets feedback on that, and
again if the director approves it based on technical issues,
implementor feedback, and community feedback, it moves on to Proposed
Recommendation (PR). No changes can be made to the CR except for removing
"at risk" items. Once it becomes a PR, the  Advisory Committee must approve
it. This is mostly a consensus vote, so a single dissent can sink the
recommendation.

Because of this process, it would be self-destructive to include
controversial items in a recommendation without labelling them "at risk"
and ultimately removing them if they remain controversial. I think that is
process prevents adding language to the charter emphasizing the issues you

Neil

On Mon, Aug 3, 2020 at 4:03 AM Frédéric Wang <fwang@igalia.com> wrote:

> Maybe I haven't read in details but I don't think these address my
> concern. At least MathML3 also had similar W3C's "two interoperable
> implementations" and "test suite" rules, and that unfortunately didn't
> prevent it from becoming what it is. I'd prefer to follow a stricter model
> like WHATWG and the browser community do, where you need support and test
> coverage for each change.
>
> What you quoted is "deliverables" and "success criteria" which just sounds
> goals not decision policy, so I don't see how it prevents us from putting
> something in core that has no implementor's interest or is controversial in
> the browser community or no test plan. Actually, one could say this is
> worse, since that means we can actually put a complex/controversial
> feature, wait for the PR application, finally try to convince browser, get
> pushback and then give it up with the idea. Moreover, browser vendors
> really only use working drafts as a reference these days, so I don't think
> MathML Core drafts should even contain controversial things.
>
> Note that my remark is only for MathML Core, I don't care if people put
> things in MathML full that have no browser implementor interest if this is
> just to present something for discussion or to experiment with polyfills.
> What I don't want is the way of thinking "put something in core without
> following the modern approach of the browser community, with the hope that
> it will get natively implemented in browsers".
>
> On 03/08/2020 01:52, Neil Soiffer wrote:
>
> I think what you want is at least partially addressed by what is written
> in "deliverables" for MathML Core Level 1:
>
>> This specification provides an initial integration to the platform with
>> increased implementation details, focused on a subset of MathML 3 which had
>> wide implementation and could be 'fit' into the platform. It greatly
>> details and relies on automated web platform tests aiming to greatly
>> improve MathML interoperability.
>
>
> It is supported by the listing of a Test Suite and Implementation report
> in the non-normative documents. This is backed up by the success criteria:
>
>> There are multiple, independent, interoperable native implementations of
>> MathML Core Level 1 that are widely used
>
>
> Furthermore, we can't proceed to Proposed Recommendation (PR) without two
> interoperable implementations as per W3C policies. So no matter how
> important I think linebreaking support may be and how good I might be at
> convincing others that it is essential for Core, without the
> implementations, Core will never make it to PR without it being implemented.
>
> Based on other group's "Decision Policy" sections, that section should
> concern itself with voting policies (consensus, voting time periods, ...),
> not criteria on which way a vote should go.
>
> We need to improve the intro language, the scope language, and language
> about what the group produces. I think changes there will be able to
> address your concerns. I hope you and others will suggest wording
> changes/improvements to those sections as we move forward with the charter
> development.
>
>    Neil
>
>
>
> On Fri, Jul 31, 2020 at 3:15 PM Frédéric Wang <fwang@igalia.com> wrote:
>
>> Thanks Brian for working on the draft,
>>
>> I just skimmed through it, I think it looks good overall. My main
>> concern is about the policy regarding what will go into MathML Core
>> specifications (or any other one that is intended to be implemented
>> natively in browsers).
>>
>> I believe the charter should really contain strong rules that aligns
>> with the policy of other web platform standards (maybe in "Decision
>> policy"?), so we are sure that we don't end up adding/keeping something
>> in the spec that, for example, lacks rigorous implementation details,
>> does not have web platform tests, is controversial among the browser
>> community or for which nobody is committing to implement it.
>>
>> We have tried our best to adhere to these principles and that was
>> instrumental in order to convince the browser community that our CG is
>> credible and address criticisms of the MathML3 specification. However,
>> this is a topic that has been raised again and again in Core meetings.
>> So I think we should make sure that this is clearly stated in the charter.
>>
>> --
>> Frédéric Wang
>>
>>
>>
> --
> Frédéric Wang
>
>


## Re: WG draft charter

Source: public-mathml4@w3.org Mail Archives • Deyan Ginev (deyan.ginev@gmail.com) • August 03, 2020 • Permalink

Hi Frédéric,

Very curious to read about the lessons learned and trying to ensure
MathML's browser support remains for the long-haul "by design". I
think there is a lot of wisdom in your perspective.

I wanted to ask for your thoughts on the "content side" of the MathML
spec. Do you think it should even attempt to aim to one day be in
Core, or do you think it is completely irrelevant until there are
compelling browser applications that consume the content markup?

I am trying to get a workable perspective on where this "multi-level"
approach to MathML will guide us to, and I mentioned in another thread
that the accessibility mini spec we're attempting looks to be a lot
closer to practical browser applications than cMML ever was. Do you
find it reasonable for us to work on small application-oriented
"content subsets", and then aim to elevate them to the browser-level
of rigor/testing/support? And how should we minimize being
controversial while doing so?

Deyan

On Mon, Aug 3, 2020 at 7:03 AM Frédéric Wang <fwang@igalia.com> wrote:
>
> Maybe I haven't read in details but I don't think these address my concern. At least MathML3 also had similar W3C's "two interoperable implementations" and "test suite" rules, and that unfortunately didn't prevent it from becoming what it is. I'd prefer to follow a stricter model like WHATWG and the browser community do, where you need support and test coverage for each change.
>
> What you quoted is "deliverables" and "success criteria" which just sounds goals not decision policy, so I don't see how it prevents us from putting something in core that has no implementor's interest or is controversial in the browser community or no test plan. Actually, one could say this is worse, since that means we can actually put a complex/controversial feature, wait for the PR application, finally try to convince browser, get pushback and then give it up with the idea. Moreover, browser vendors really only use working drafts as a reference these days, so I don't think MathML Core drafts should even contain controversial things.
>
> Note that my remark is only for MathML Core, I don't care if people put things in MathML full that have no browser implementor interest if this is just to present something for discussion or to experiment with polyfills. What I don't want is the way of thinking "put something in core without following the modern approach of the browser community, with the hope that it will get natively implemented in browsers".
>
> On 03/08/2020 01:52, Neil Soiffer wrote:
>
> I think what you want is at least partially addressed by what is written in "deliverables" for MathML Core Level 1:
>>
>> This specification provides an initial integration to the platform with increased implementation details, focused on a subset of MathML 3 which had wide implementation and could be 'fit' into the platform. It greatly details and relies on automated web platform tests aiming to greatly improve MathML interoperability.
>
>
> It is supported by the listing of a Test Suite and Implementation report in the non-normative documents. This is backed up by the success criteria:
>>
>> There are multiple, independent, interoperable native implementations of MathML Core Level 1 that are widely used
>
>
> Furthermore, we can't proceed to Proposed Recommendation (PR) without two interoperable implementations as per W3C policies. So no matter how important I think linebreaking support may be and how good I might be at convincing others that it is essential for Core, without the implementations, Core will never make it to PR without it being implemented.
>
> Based on other group's "Decision Policy" sections, that section should concern itself with voting policies (consensus, voting time periods, ...), not criteria on which way a vote should go.
>
> We need to improve the intro language, the scope language, and language about what the group produces. I think changes there will be able to address your concerns. I hope you and others will suggest wording changes/improvements to those sections as we move forward with the charter development.
>
>    Neil
>
>
>
> On Fri, Jul 31, 2020 at 3:15 PM Frédéric Wang <fwang@igalia.com> wrote:
>>
>> Thanks Brian for working on the draft,
>>
>> I just skimmed through it, I think it looks good overall. My main
>> concern is about the policy regarding what will go into MathML Core
>> specifications (or any other one that is intended to be implemented
>> natively in browsers).
>>
>> I believe the charter should really contain strong rules that aligns
>> with the policy of other web platform standards (maybe in "Decision
>> policy"?), so we are sure that we don't end up adding/keeping something
>> in the spec that, for example, lacks rigorous implementation details,
>> does not have web platform tests, is controversial among the browser
>> community or for which nobody is committing to implement it.
>>
>> We have tried our best to adhere to these principles and that was
>> instrumental in order to convince the browser community that our CG is
>> credible and address criticisms of the MathML3 specification. However,
>> this is a topic that has been raised again and again in Core meetings.
>> So I think we should make sure that this is clearly stated in the charter.
>>
>> --
>> Frédéric Wang
>>
>>
>
> --
> Frédéric Wang


## Weekly github digest (HTML specs)

Source: public-html@w3.org Mail Archives • W3C Webmaster via GitHub API (sysbot+gh@w3.org) • August 03, 2020 • Permalink



Issues
------
* w3c/html-aam (+1/-0/💬1)
1 issues created:
https://github.com/w3c/html-aam/issues/297

- #2 Mappings for <meter> should be different from <progress> (1 by stevefaulkner)
https://github.com/w3c/html-aam/issues/2 [AAM V2]

* w3c/html-extensions (+1/-0/💬5)
1 issues created:
- Should we archive this repo? (by hober)
https://github.com/w3c/html-extensions/issues/40

- #40 Should we archive this repo? (5 by LJWatson, marcoscaceres, siusin)
https://github.com/w3c/html-extensions/issues/40

* w3c/webcomponents (+1/-0/💬14)
1 issues created:
- Allow a click on label associated with custom element to focus the custom element (by JanMiksovsky)
https://github.com/w3c/webcomponents/issues/891

- #891 Allow a click on label associated with custom element to focus the custom element (3 by JanMiksovsky, domenic)
https://github.com/w3c/webcomponents/issues/891
- #889 Allowing CSS combinators postfixed to the ::slotted() selector (9 by Danny-Engelman, bathos, castastrophe, trusktr)
https://github.com/w3c/webcomponents/issues/889
- #872 2020 Virtual F2F for Accessibility and Web Components (2 by JanMiksovsky)

* whatwg/html (+7/-3/💬24)
7 issues created:
- simpler doctype declaration (by henryruss2)
https://github.com/whatwg/html/issues/5777
- Table grouping should clear row spans (by Manishearth)
https://github.com/whatwg/html/issues/5776
- How should errors in cross-origin importScripts() sanitized when reported to WorkerGlobalScope error event? (by hiroshige-g)
https://github.com/whatwg/html/issues/5772
- "reset the rendering context to its default state" should also clear the "current default path" (by Kaiido)
https://github.com/whatwg/html/issues/5771
- Changing the session history spec to converge on historical & modern browser behaviour (by jakearchibald)
https://github.com/whatwg/html/issues/5767
- Should "message" events be fired on closed MessagePorts? (by karlt)
https://github.com/whatwg/html/issues/5765
- "For example, an element that is both flow conte..." (by tabatkins)
https://github.com/whatwg/html/issues/5764

- #5777 simpler doctype declaration (1 by domenic)
https://github.com/whatwg/html/issues/5777
- #5776 Table grouping should clear row spans (2 by Manishearth)
https://github.com/whatwg/html/issues/5776
- #5772 How should errors in cross-origin importScripts() sanitized when reported to WorkerGlobalScope error event? (4 by domenic, hiroshige-g)
https://github.com/whatwg/html/issues/5772
- #5765 Should "message" events be fired on closed MessagePorts? (2 by gterzian, karlt)
https://github.com/whatwg/html/issues/5765
- #5764 "For example, an element that is both flow conte..." (5 by domenic, triple-underscore)
https://github.com/whatwg/html/issues/5764 [document conformance] [good first issue]
- #5759 Window opening steps return WindowProxy despite COOP (1 by camillelamy)
https://github.com/whatwg/html/issues/5759 [topic: cross-origin-opener-policy]
- #4702 Consider renaming HTMLOrSVGElement to HTMLOrForeignElement (6 by ExE-Boss, domenic, stephenmcgruer)
https://github.com/whatwg/html/issues/4702 [addition/proposal] [integration] [needs implementer interest] [needs tests]
- #3377 navigator.registerProtocolHandler specification divergent from both implementations (2 by fred-wang, mgiuca)
https://github.com/whatwg/html/issues/3377 [interop] [topic: custom protocols]
- #2722 Attribute to suggest filename for image elements (<img filename> / <img download>) (1 by cp-apple)
https://github.com/whatwg/html/issues/2722 [addition/proposal] [needs concrete proposal] [topic: img]

3 issues closed:
- simpler doctype declaration https://github.com/whatwg/html/issues/5777
- How should errors in cross-origin importScripts() sanitized when reported to WorkerGlobalScope error event? https://github.com/whatwg/html/issues/5772
- "For example, an element that is both flow conte..." https://github.com/whatwg/html/issues/5764 [good first issue]

Pull requests
-------------
* w3c/html-aria (+0/-0/💬5)
- #211 add allowed roles for nav element (2 by scottaohara, stevefaulkner)
https://github.com/w3c/html-aria/pull/211
- #196 Add implicit roles to td, th, and simplify tr (3 by carmacleod, patrickhlauke, stevefaulkner)
https://github.com/w3c/html-aria/pull/196

* whatwg/html (+5/-1/💬31)
5 pull requests submitted:
- Further clarify "Contexts in which this element can be used" (by domenic)
https://github.com/whatwg/html/pull/5775 [document conformance]
- Editorial: modernization of script fetching algorithms (by domenic)
https://github.com/whatwg/html/pull/5774 [topic: script]
- Added find-in-page definitions (by vmpstr)
https://github.com/whatwg/html/pull/5770
- Add preservesPitch to HTMLMediaElement (by domenic)
https://github.com/whatwg/html/pull/5769
- flow content is a superset of phrasing content (by koba04)
https://github.com/whatwg/html/pull/5768

- #5775 Further clarify "Contexts in which this element can be used" (2 by domenic, triple-underscore)
https://github.com/whatwg/html/pull/5775 [document conformance]
- #5770 Added find-in-page definitions (2 by domenic, vmpstr)
https://github.com/whatwg/html/pull/5770
- #5768 flow content is a superset of phrasing content (3 by domenic, koba04)
https://github.com/whatwg/html/pull/5768 [document conformance]
- #5752 Introduce "cross-origin-isolated" permission (2 by domenic, yutakahirano)
https://github.com/whatwg/html/pull/5752
- #5739 COOP: modify redirects handling (1 by camillelamy)
https://github.com/whatwg/html/pull/5739 [needs tests]
- #5574 Allow an image to indicate its own density and correct its intrinsic size (1 by noamr)
https://github.com/whatwg/html/pull/5574 [addition/proposal] [needs implementer interest] [topic: img]
- #5524 Adjust registerProtocolHandler() handling (2 by domenic, fred-wang)
https://github.com/whatwg/html/pull/5524 [do not merge yet] [topic: custom protocols]
- #5518 Cross origin opener policy reporting (1 by camillelamy)
https://github.com/whatwg/html/pull/5518 [topic: cross-origin-opener-policy]
- #5302 Add MIME type checking for non-blob:/data: worker scripts (9 by domenic, evilpie)
https://github.com/whatwg/html/pull/5302 [do not merge yet] [normative change] [security/privacy] [topic: script] [topic: workers]
- #5248 Rename HTMLOrSVGElement to reflect its wider use in MathML as well (1 by ExE-Boss)
https://github.com/whatwg/html/pull/5248 [impacts documentation]
- #4288 Re add inert (2 by asurkov, domenic)
https://github.com/whatwg/html/pull/4288
- #3881 Add HTMLMediaElement.preservesPitch (5 by domenic, haywirez)
https://github.com/whatwg/html/pull/3881

1 pull requests merged:
- flow content is a superset of phrasing content
https://github.com/whatwg/html/pull/5768

* whatwg/dom (+1/-0/💬1)
1 pull requests submitted:
- Define TreeNode mixin and add .closest() to more nodes (by shvaikalesh)
https://github.com/whatwg/dom/pull/883

- #883 Define TreeNode mixin and add .closest() to more nodes (1 by domenic)
https://github.com/whatwg/dom/pull/883

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


## Re: WG draft charter

Source: public-mathml4@w3.org Mail Archives • Frédéric Wang (fwang@igalia.com) • August 03, 2020 • Permalink

Maybe I haven't read in details but I don't think these address my
concern. At least MathML3 also had similar W3C's "two interoperable
implementations" and "test suite" rules, and that unfortunately didn't
prevent it from becoming what it is. I'd prefer to follow a stricter
model like WHATWG and the browser community do, where you need support
and test coverage for each change.

What you quoted is "deliverables" and "success criteria" which just
sounds goals not decision policy, so I don't see how it prevents us from
putting something in core that has no implementor's interest or is
controversial in the browser community or no test plan. Actually, one
could say this is worse, since that means we can actually put a
complex/controversial feature, wait for the PR application, finally try
to convince browser, get pushback and then give it up with the idea.
Moreover, browser vendors really only use working drafts as a reference
these days, so I don't think MathML Core drafts should even contain
controversial things.

Note that my remark is only for MathML Core, I don't care if people put
things in MathML full that have no browser implementor interest if this
is just to present something for discussion or to experiment with
polyfills. What I don't want is the way of thinking "put something in
core without following the modern approach of the browser community,
with the hope that it will get natively implemented in browsers".

On 03/08/2020 01:52, Neil Soiffer wrote:
> I think what you want is at least partially addressed by what is
> written in "deliverables" for MathML Core Level 1:
>
>     This specification provides an initial integration to the platform
>     with increased implementation details, focused on a subset of
>     MathML 3 which had wide implementation and could be 'fit' into the
>     platform. It greatly details and relies on automated web platform
>     tests aiming to greatly improve MathML interoperability.
>
>
> It is supported by the listing of a Test Suite and Implementation
> report in the non-normative documents. This is backed up by the
> success criteria:
>
>     There are multiple, independent, interoperable native
>     implementations of MathML Core Level 1 that are widely used
>
>
> Furthermore, we can't proceed to Proposed Recommendation (PR) without
> two interoperable implementations as per W3C policies. So no matter
> how important I think linebreaking support may be and how good I might
> be at convincing others that it is essential for Core, without the
> implementations, Core will never make it to PR without it being
> implemented.
>
> Based on other group's "Decision Policy" sections, that section should
> concern itself with voting policies (consensus, voting time periods,
> ...), not criteria on which way a vote should go.
>
> We need to improve the intro language, the scope language, and
> language about what the group produces. I think changes there will be
> able to address your concerns. I hope you and others will suggest
> wording changes/improvements to those sections as we move forward with
> the charter development.
>
>    Neil
>
>
>
> On Fri, Jul 31, 2020 at 3:15 PM Frédéric Wang <fwang@igalia.com
> <mailto:fwang@igalia.com>> wrote:
>
>     Thanks Brian for working on the draft,
>
>     I just skimmed through it, I think it looks good overall. My main
>     concern is about the policy regarding what will go into MathML Core
>     specifications (or any other one that is intended to be implemented
>     natively in browsers).
>
>     I believe the charter should really contain strong rules that aligns
>     with the policy of other web platform standards (maybe in "Decision
>     policy"?), so we are sure that we don't end up adding/keeping
>     something
>     in the spec that, for example, lacks rigorous implementation details,
>     does not have web platform tests, is controversial among the browser
>     community or for which nobody is committing to implement it.
>
>     We have tried our best to adhere to these principles and that was
>     instrumental in order to convince the browser community that our CG is
>     credible and address criticisms of the MathML3 specification. However,
>     this is a topic that has been raised again and again in Core meetings.
>     So I think we should make sure that this is clearly stated in the
>     charter.
>
>     --
>     Frédéric Wang
>
>

--
Frédéric Wang


## Reminder: MathML core meeting 3 August, 2020

Source: public-mathml4@w3.org Mail Archives • Neil Soiffer (soiffer@alum.mit.edu) • August 03, 2020 • Permalink

The agenda is at
https://github.com/mathml-refresh/mathml/issues/8#issuecomment-667748594

Meeting is at 11am Pacific, 2pm Eastern, 8pm Central European Time.

The zoom meeting link is the same one we have used at the last few core
meetings. Due to zoombombing, I can't send it out to the public mailing
list. If you would like to join and don't have the link, please send me
email at least 10 minutes before the meeting.


## Re: Minutes: MathML general meeting 30 July, 2020

Source: public-mathml4@w3.org Mail Archives • Neil Soiffer (soiffer@alum.mit.edu) • August 02, 2020 • Permalink

Moritz,

I think we are on the same page as to goals. You maybe misunderstood the
minutes comment. The "two more weeks" comment is to end the time to gather
suggestions for the *charter*; what the specs will say is nowhere near
close to finished. The charter defines what is in scope and what is not for
the working group, along with deliverables, etc. The timeline I am looking
at *for the charter* is to have it in good shape by October so it can be
discussed at W3C TPAC meetings in October.  That's two more months of
charter writing, but to accomplish that writing, we need to end the brain
storming phase and enter a phase where we consider what is technically
appropriate and what people are willing to commit doing in the time period.
After that, comes putting those into plans into words we all agree on.

Just as an FYI about the timeline. If we submit the charter in November,
the WG wouldn't start until sometime in 2021 because the process to approve
a WG takes a few months. The WG likely would exist for maybe two years,
with hopefully working drafts moving to the last call/candidate
recommendation/... phases sometime in early 2022. Note: this *my* opinion
and the CG and/or W3C may have other ideas about the timeline.

Both the core meetings and semantics meetings have charter review/comments
on their agendas and I hope you will join at least one of the two meetings
so you have an opportunity to present and discuss any suggestions you have
about the charter. You have a lot of experience and I value your ideas.

Neil

On Thu, Jul 30, 2020 at 11:48 PM Moritz Schubotz <
moritz.schubotz@fiz-karlsruhe.de> wrote:

> Dear Neil,
>
> thank you very much for sharing the minutes and organizing the meetings.
>
> > -----Original Message-----
> > From: Neil Soiffer <soiffer@alum.mit.edu>
> > Sent: Friday, July 31, 2020 2:00 AM
> > To: public-mathml4@w3.org
> > Subject: Minutes: MathML general meeting 30 July, 2020
> >
> > NS: I will do a Google Sheet; we clearly have more on semantics; 2 more
> > weeks on charter comments, then we’ll nail it down to W3C standards.
> Thank
> > you all
> >
> and support the adoption of the MathML standards, by publishers content
> providers. I also agree that improving accessibility and machine
> readability is what we should aim for. However, I think the current
> document focusses on implementation details without to clearly identify the
> current shortcomings of MathML3 and to show why the newly proposed
> implementation is sigificantly better.
> That said, I would propose to keep the document open until it is good.
>
> Best
> Moritz
>
>
> ------------------------------------------------------------------------------
>
> FIZ Karlsruhe - Leibniz-Institut für Informationsinfrastruktur GmbH.
> Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB
> 101892.
> Geschäftsführerin: Sabine Brünger-Weilandt.
> Vorsitzende des Aufsichtsrats: MinDirig’in Dr. Angelika Willms-Herget.
>
> FIZ Karlsruhe ist zertifiziert mit dem Siegel "audit berufundfamilie".
>


## Re: WG draft charter

Source: public-mathml4@w3.org Mail Archives • Frédéric Wang (fwang@igalia.com) • July 31, 2020 • Permalink

Thanks Brian for working on the draft,

I just skimmed through it, I think it looks good overall. My main
concern is about the policy regarding what will go into MathML Core
specifications (or any other one that is intended to be implemented
natively in browsers).

I believe the charter should really contain strong rules that aligns
with the policy of other web platform standards (maybe in "Decision
policy"?), so we are sure that we don't end up adding/keeping something
in the spec that, for example, lacks rigorous implementation details,
does not have web platform tests, is controversial among the browser
community or for which nobody is committing to implement it.

We have tried our best to adhere to these principles and that was
instrumental in order to convince the browser community that our CG is
credible and address criticisms of the MathML3 specification. However,
this is a topic that has been raised again and again in Core meetings.
So I think we should make sure that this is clearly stated in the charter.

--
Frédéric Wang


## Re: Minutes: MathML general meeting 30 July, 2020

Source: public-mathml4@w3.org Mail Archives • Deyan Ginev (deyan.ginev@gmail.com) • July 31, 2020 • Permalink

Hi Moritz, all,

In the meetings I've attended, I don't think we ever discussed what
the exact reasoning is to work on a quick timeline, so that's a valid
question. I myself quite appreciate Neil's impetus to move us forward,
it's good to have a driver in these distributed discussions (which can
end up meandering and stagnate, if one is not careful).

As to timelines, MathML 3 was published in 2014, so not really a
breakneck speed to be revising it in 2020, and to not take too long
doing so. As to addressing the fundamental problems with MathML 3 - I
like your point that we should make abundantly clear what the
direction of the "Refresh" effort / a hypothetical MathML 4 spec is. I
think there's a shared consensus that we're trying to get the proposed
changes to MathML in a direction where we make it "as simple as
possible but no simpler", while being mindful of existing

Given that MathML 3 is at the very last steps before having official
support in all major browser vendors, after years of hardship, I've
understood the current effort as mainly a practical incremental
upgrade. One perspective over the core changes is that they will
simplify ongoing maintenance of the browser implementations, making
them easier to keep. If we were in a position where no browser ever
from scratch etc. But since there is now a breakthrough in working
together with the Chromium world, it's quite sensible that the next
iteration on the spec solidifies on what appears to be a slow success
story in browser vendors. Other specs such as ePub, JATS, also have
passively delegated all math syntax to MathML, though I wonder if we
could have more people from those industries giving feedback on the
refresh effort. Maybe that comes later, after we have a draft?

A repeated, in fact belabored, criticism of MathML has been that it is
overly complex (and for Content MathML - too academic), to the point
of alienating the wider web-development community. I think we're also
trying to address a part of that in the a11y fragment of the proposal,
focusing on one application and minimalistic design. I myself view the
a11y work as a "canary in the coal mine" attempt at seeing if we can
one day simplify Content MathML to a point where it isn't "scary by
default".

But I wonder if you are worrying that we are making big mistakes which
the people on the calls are not seeing, because they are not thinking
of valid uses that are not represented in the discussions? Maybe we
should reach out to more experts from the publishing industry, or
additionally cross-talk with the folks at ePub, JATS, polyfill
engines? I am a late-comer to the Refresh group, so I don't even know
if a lot of this has already happened, maybe some of it has...

Looking forward to see what others think here,
Deyan

On Fri, Jul 31, 2020 at 9:59 AM Moritz Schubotz
<moritz.schubotz@fiz-karlsruhe.de> wrote:
>
> Dear Neil,
>
> thank you very much for sharing the minutes and organizing the meetings.
>
> > -----Original Message-----
> > From: Neil Soiffer <soiffer@alum.mit.edu>
> > Sent: Friday, July 31, 2020 2:00 AM
> > To: public-mathml4@w3.org
> > Subject: Minutes: MathML general meeting 30 July, 2020
> >
> > NS: I will do a Google Sheet; we clearly have more on semantics; 2 more
> > weeks on charter comments, then we’ll nail it down to W3C standards.  Thank
> > you all
> >
> I am seriously concerned about this attitude. My goal is to improve MathML and support the adoption of the MathML standards, by publishers content providers. I also agree that improving accessibility and machine readability is what we should aim for. However, I think the current document focusses on implementation details without to clearly identify the current shortcomings of MathML3 and to show why the newly proposed implementation is sigificantly better.
> That said, I would propose to keep the document open until it is good.
>
> Best
> Moritz
>
> ------------------------------------------------------------------------------
>
> FIZ Karlsruhe - Leibniz-Institut für Informationsinfrastruktur GmbH.
> Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB 101892.
> Geschäftsführerin: Sabine Brünger-Weilandt.
> Vorsitzende des Aufsichtsrats: MinDirig’in Dr. Angelika Willms-Herget.
>
> FIZ Karlsruhe ist zertifiziert mit dem Siegel "audit berufundfamilie".


## Feeds

Planet MathML features:

If you own a blog with a focus on MathML, and want to be added or removed from this aggregator, please get in touch with Bert Bos at bert@w3.org.