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.
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.
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 >
========================================= 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®exp=false <dbaron> or more precisely, https://searchfox.org/mozilla-central/search?q=NS_FONT_%5BA-Z%5D*_OFFSET_RATIO&path=&case=false®exp=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!
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
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
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.
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. >
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.
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
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.
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
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.
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/
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 > >
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
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
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
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.
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". >
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
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".
Planet MathML features:
David Carlisle Design Science News
FMath
Getting Math onto Web
Pages Community Group MathJax MathML Refresh Community
Group SF.net - ASCIIMathML SF.net - DocBook to LaTeX
Publishing SF.net - MathCast Equation
Editor SF.net - MathStudio
SF.net - Open Math Edit SF.net - PyMathML SF.net - SVGMath SF.net - UniWakka SF.net - jsMath
SF.net - jscl-meditor SF.net - pMML2SVG Updates | Frédéric Wang W3C Blog W3C Math Home W3C News WebKit
public-digipub-ig@w3.org
Mail Archives
public-html-a11y@w3.org
Mail Archives public-html@w3.org Mail
Archives
public-mathml4@w3.org
Mail Archives
public-mathonwebpages@w3.org
Mail Archives
public-webapps@w3.org
Mail Archives www-math@w3.org Mail
Archives www-style@w3.org Mail
ArchivesIf 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.
