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.

Latest articles

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,
> please indicate your availability and also add a comment saying what topic
> 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,
 Please respond by starting a new thread
   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

  <faceless2> See also https://github.com/w3c/csswg-drafts/issues/4116,
              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
          granular capabilities. Please help fantasai with use cases
          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
            because SVG had the two longhands and CSS had shorthand,
            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
  fantasai: I don't have a strong feeling about this. Don't know if
            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

  Rossen: Other comments or objections?

  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
  <florian> [more info on using font-variant for that sort of things
            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
           particularly cares about typography
  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
            want to actually discuss with more information and thought
            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.
            If you want spacing on both sides you can add padding.

  fantasai: Only reason to have a switch is for compat. Lots of
            switches between previous and current isn't good for css
            and add complexity
  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
           it's widespread.

  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
            agree we should wrap up. What about comments for German
            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]

  Rossen: We're just about done. fantasai had a proposed closing for
          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,
> Avogadro's number/mole
>  - 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
> made about a very small core list, and adjacent level 2, level 3 lists
> 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,
Avogadro's number/mole
 - 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
made about a very small core list, and adjacent level 2, level 3 lists
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
more feedback about mpadded incompat with CSS, which are blocking the
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:
1. Charter comments, suggestions, discussion
2. Sam and I have created an initial list based on pragmatic MathML
<https://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit?usp=sharing>
   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.

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,
please indicate your availability and also add a comment saying what topic
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
(Access Password: $2%Ekq4?)

Charter:

   -

   We created a very basic starting point (not even a 'first draft') of  MathML
   WG charter
   <https://docs.google.com/document/d/1W-oYUbOMueaqb3KFSWkjWVBwR6AzSEBizHwQhvSwfDc/edit>,
   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.
      -

      MS: We could add something about things about that should be
      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
      to add in thinking about it now
      -

      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
      please continue to comment.



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
be most helpful if you would join us in the teleconference
discussions so that your concerns could be clarified and hopefully
fully addressed.

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
the ultimate safeguard to what you are concerned about. Nothing about this
process prevents adding language to the charter emphasizing the issues you
are concerned about though.

    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?

Thanks for your thoughts,
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:
  - Link to HTML 5 definitions of column header and row header? (by WilcoFiers)
    https://github.com/w3c/html-aam/issues/297 

  1 issues received 1 new comments:
  - #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 

  1 issues received 5 new comments:
  - #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 

  3 issues received 14 new comments:
  - #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)
    https://github.com/w3c/webcomponents/issues/872 [custom-elements] [shadow-dom] 

* 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 

  9 issues received 24 new comments:
  - #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)
  2 pull requests received 5 new comments:
  - #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 

  12 pull requests received 31 new comments:
  - #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 

  1 pull requests received 1 new comments:
  - #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
> >
> 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".
>

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
adopters/implementers.

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
adopted MathML 3, we may be talking about complete overhauls, starting
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.

(feed)This page as an Atom feed

A mechanical calculation machine (with an added W3C logo)

Bert Bos, math activity lead
Copyright © 2008–2016 W3C®

Powered by Planet