Simplification of the mstyle element #1

fred-wang · 2019-02-14T17:26:18Z

This proposal is to simplify mstyle so that it only supports the following attributes:

displaystyle
dir
mathsize
mathbackground
mathcolor
mathvariant
scriptlevel

And maybe:

scriptsizemultiplier
scriptminsize

From the Math WG mailing list:
https://lists.w3.org/Archives/Public/www-math/2016Jul/0024.html

From the appendix of the original "MathML in HTML5" document:
"The mstyle element duplicates the CSS inheritance mechanism in a CSS-incompatible way and has many exceptions to workaround the fact that attribute names may be used for different purposes. In practice, many of its attributes are not useful and never used. It is a burden for implementers since they essentially have to reimplement a specific “attribute” inheritance mechanism to support the general case even if the most prominent attributes have obvious mapping to CSS. It is also a performance issue to perform the rendering and keep it up-to-date since the rendering on any node may depend on its mstyle ancestors. In this document, it instead suggested to keep only attributes that are compatible with CSS and five new CSS properties are introduced in section 2.3.1. These attributes actually correspond to what is used in practice. "

edit:
This is the proposal for CSS attributes that cannot be mapped to style yet: https://github.com/mathml-refresh/mathml-css-proposals#mathml-css-proposals

physikerwelt · 2019-02-19T10:59:01Z

This might be a stupid question, but why do we need

dir -> direction
mathsize -> font-size
mathbackground -> background-color
mathcolor -> color
can that not implemented using the style attribute?

fred-wang · 2019-02-19T11:23:36Z

Yes, they can be (and are) implemented using CSS style.
Whether we want to remove/deprecate these MathML attributes (and hence the whole mstyle element) is another question, but probably they have already been used a lot in existing documents. This is not really the case of attributes not mentioned in #1 (comment) , I think in a previous discussion on Math WG only one instance of another attribute (linethickness) was used in the MathML 3 test suite.

fred-wang · 2019-02-19T11:26:30Z

Incidentally, for attributes without CSS equivalent, there is https://github.com/mathml-refresh/mathml-css-proposals#mathml-css-proposals

@physikerwelt I think in general it would be good to gather usage metrics of elements/attributes that are proposed for deprecation/removal. Maybe you can do that for wikipedia.

davidcarlisle · 2019-02-19T11:51:05Z

This might be a stupid question, but why do we need

* dir -> direction

* mathsize -> font-size

* mathbackground -> background-color

* mathcolor -> color
  can that not implemented using the style attribute?

html also has a dir attribute so this isn't so strange I think?

Initially the model was to preserve as far as possible that as far as possible the notion that css should be used to encode potentially reader-customizable style, and that explicit attributes in the source should be used to encode author-specified meaning.

So a clearer example would be <mi mathvariant="sans-serif" to chose a sans math alphabet as opposed to using CSS to chose the overall font style (which may be sans serif)

Of course in the end mathvariant got defined as a shift of codepoint rather than a change of font, but it was still a motivating example here.

So at the time, almost all publications were monochrome but the thought was that you may want to use colour just as fonts have been traditionally used, to have distinguished mathematical variables x mathcolor="red" and x mathcolor="blue" that are separate from a reader choice to style the whole expression in brown to match a website style...

We can decide not to keep this (and we could potentially have different decision for the mathml-core and full mathml but if you are asking why mathml3 (and 2 and 1) are this way, that is basically why.

dani31415 · 2019-02-25T19:03:53Z

Why not indentalign -> text-align ?

physikerwelt · 2019-02-25T19:29:05Z

discussed in the telco on 2019-02-25:

@NSoiffer does not think one can get rid of mstyle entirely?
** @fred-wang "in theory one could get rid of mstyle and use style of mrow"
can one get rid of matvariant?
patrick ion asks if there are glyphs that are only accessible via mstyle?

fred-wang · 2019-03-14T11:42:35Z

Why not indentalign -> text-align ?

I don't think indentalign is in MathML Core. Also we should keep in mind (2) #30 (comment) applies here.

fred-wang · 2019-03-14T11:54:19Z

This is how I understand the current status:
(1) Do we keep the <mstyle> element? It could just be <mrow> + CSS styles but we need (a) to define more CSS properties / remove some attributes and (b) take into account non-browser implementation and backward compatibility with existing usage #55.
(2) Do we reduce the existing set of properties (suggestion: #1 (comment)).
(3) Do we just map properties to CSS instead of defining our own inheritance?
(4) Do we move new proposals https://github.com/mathml-refresh/mathml-css-proposals to CSS -drafts?. Per https://lists.w3.org/Archives/Public/public-mathml4/2019Mar/0007.html for mathvariant it seems fine to extend CSS text-transform and displaystyle is not really controversial. I hope we can decide about scriptlevel-related properties in the next meeting.

dani31415 · 2019-03-15T19:38:03Z

I think we should make MathML core as much backward compatibility as possible with existing formulas. With this idea we should implement the <mstyle>.

At the same time I would deprecate <mstyle> in the sense that we recommend to use the alternative version of <mrow> with CSS. In addition, in MathML 4, I would deprecate <mstyle> as well (with the same meaning of a recommendation of not to use it).

fred-wang · 2019-03-19T09:22:12Z

cc @rwlbuis @emilio

We have discussed a lot about scriptlevel yesterday. This is my summary regarding the attributes:

CSS engines need to know about scriptlevel, scriptsizemultiplier and scriptminsize which means we would need to map attributes to CSS or replace them with something known by CSS.
Putting scriptsizemultiplier and scriptminsize in an arbitrary place is not very useful (but if we map them to CSS that would still be possible anyway). In general some people think it does not make sense to configure scriptsizemultiplier and scriptminsize values at the MathML markup level, there should be another more modern way to address these use cases.
For the first script levels, the scriptsizemultiplier feature could be replaced with OpenType MATH scriptPercentScaleDown and scriptScriptPercentScaleDown constants which are likely accessible from the CSS engine and correspond more to the font designer's goal. Other levels are less important in practice (e.g. TeX and Microsoft office don't consider them) so we could keep the constant 0.71 or do another kind of extrapolation. See https://github.com/mathml-refresh/mathml-css-proposals/blob/master/math-script-level-and-math-style-comments.md#opentype-math-values-scriptpercentscaledown-and-scriptscriptpercentscaledown
the scriptminsize feature could probably be replaced with CSS's new font-min-size property ( https://drafts.csswg.org/css-fonts-4/#propdef-font-min-size ). Note that this is not exactly the same, since scriptminsize is only supposed to affect the change due to scriptlevel, so we cannot just map to font-min-size. However, I believe it still addresses the use cases for which scriptminsize was introduced.

Given all of this, I would now recommend to remove scriptsizemultiplier and scriptminsize attributes from MathML Core and only keep thoses:

displaystyle (mapped to a new two-valued CSS property)
dir
mathsize
mathbackground
mathcolor
mathvariant (mapped to new text-transform values)
scriptlevel (mapped to a new property)

Details for the last one still have to be discussed in #31

fred-wang · 2019-03-22T06:08:46Z

@brucemiller mentioned that LaTeXML sometimes generates href on mstyle ( #55 (comment) ).

First, I'd like to clarify that this proposal is not about generic MathML attributes on mstyle ( like https://mathml-refresh.github.io/mathml/chapter2.html#fund.globatt or https://mathml-refresh.github.io/mathml/chapter3.html#presm.presatt ) but only about those related to this MathML 3 "inheritance".

Also, this raises yet another issue with the MathML 3 mstyle model. https://mathml-refresh.github.io/mathml/chapter3.html#presm.mstyle already has an exception for mathbackground/mathcolor saying that it applies to the mstyle itself, not to descendants. Such an exception should also apply to href.

NSoiffer · 2019-04-29T21:32:03Z

Resolution of 29/4/19 meeting: ( https://lists.w3.org/Archives/Public/public-mathml4/2019Apr/0022.html )

scriptsizemultiplier, scriptminsize: remove from core. Rely rely on opentype math table for scriptsizemultiplier; use css property for scriptminsize
dir, mathsize, mathbackground, mathcolor: keep in core and map to the corresponding CSS property:

fred-wang · 2019-05-16T06:28:39Z

Resolution:
#1 (comment)

Specification:
Need to update Core spec to describe the mappings.
Need to update Full spec to deprecate attributes (?)

Implementation:
Need to remove deprecated attributes ( #5 ), need to implement new CSS properties and to map them to CSS ( #31 ). Other attributes are not implemented.

Polyfill:
Need to write some polyfill implementing https://mathml-refresh.github.io/mathml/chapter3.html#presm.mstyle

Tests:

Check attributes on mstyle/math tags are supported ; and that others are not.
Check rendering equivalence with CSS properties.
Check the actual CSS mapping via getComputedStyle()
Check inheritance/overriding with several nested mstyle
Check interaction of mstyle attributes with the equivalent CSS properties
Check default values
Check adding/removing attributes / CSS properties dynamically
...

…tyle attributes are ignored., a=testonly Automatic update from web-platform-tests Add MathML tests to check that legacy mstyle attributes are ignored. (#19110) * Add MathML tests to check that legacy mstyle attributes are ignored. See w3c/mathml#1 * Avoid false positives. -- wpt-commits: 0d0f9319b356f46f8bebd82982306b3b0053fa8c wpt-pr: 19110

…tyle attributes are ignored., a=testonly Automatic update from web-platform-tests Add MathML tests to check that legacy mstyle attributes are ignored. (#19110) * Add MathML tests to check that legacy mstyle attributes are ignored. See w3c/mathml#1 * Avoid false positives. -- wpt-commits: 0d0f9319b356f46f8bebd82982306b3b0053fa8c wpt-pr: 19110 UltraBlame original commit: 264ac2242a393e4691d45c7704d7c807b8516ef9

https://bugs.webkit.org/show_bug.cgi?id=202720 Patch by Delan Azabani <[email protected]> on 2020-04-09 Reviewed by Frédéric Wang. In MathML 2, the default mo@maxsize was infinity [1], unless some other default was given by mstyle@maxsize [2]. The sole purpose of "infinity" was to give authors a way to set mo@maxsize to infinity when some other mstyle@maxsize was set. MathML Core removes mstyle@maxsize [3][4], such that "infinity" has the same semantics as any other missing or invalid mo@maxsize, so the spec has been simplified to make infinity an anonymous value [5][6]. No functional change, because WebKit has never supported mstyle@maxsize anyway. To verify that there's no functional change: 1. Search for references to LengthType::Infinity, and observe that the mo@maxsize parser in MathMLOperatorElement::maxSize is the only place where a Length of ::type infinity is created 2. Search for references to that method, and observe that the only caller (RenderMathMLOperator::maxSize) passes intMaxForLayoutUnit (infinity) to toUserUnits as the referenceValue 3. Go to the definition of toUserUnits, and observe that the refer- enceValue is used as the ParsingFailed default 4. Step 1 shows that no other attributes would be affected by removing LengthType::Infinity, and steps 2 and 3 show that mo@maxsize treats invalid values as infinity, therefore it's safe to remove both the "infinity" parsing code and the underlying LengthType variant [1] https://www.w3.org/TR/MathML2/chapter3.html#id.3.2.5.2 [2] https://www.w3.org/TR/MathML2/chapter3.html#presm.mstyle [3] https://mathml-refresh.github.io/mathml-core/#style-change-mstyle [4] w3c/mathml#1 [5] https://mathml-refresh.github.io/mathml-core/#dictionary-based-attributes [6] w3c/mathml#107 No new tests, because no functional change. * mathml/MathMLElement.h: Remove LengthType::Infinity. * mathml/MathMLOperatorElement.cpp: (WebCore::MathMLOperatorElement::maxSize): Remove explicit branch on "infinity". Replace what remains with an equivalent cachedMathMLLength call. * rendering/mathml/RenderMathMLBlock.cpp: (WebCore::toUserUnits): Remove explicit branch on LengthType::Infinity. * rendering/mathml/RenderMathMLOperator.cpp: (WebCore::RenderMathMLOperator::maxSize): Update comment to refer to the default value in the same way as the spec. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@259785 268f45cc-cd09-0410-ab3c-d52691b4dbfc

NSoiffer · 2020-05-20T04:21:44Z

Reopened because it still needs a polyfill.

NSoiffer · 2020-08-17T06:23:11Z

#204 asks some questions about inheritance and mathvariant. In a comment, @fred-wang mentioned people really should use mathvariant only on token elements. To me, that raises the question of why mathvariant is still settable on mstyle. It doesn't seem particularly useful and it seems to raise some issues.

Since mstyle is being simplified for core, why not remove mathvariant from it?

NSoiffer · 2020-08-18T17:32:37Z

Discussed briefly at the Aug 17 and people generally felt that mathvariant doesn't make sense to remain on mstyle. Will discuss more fully at next meeting.

fred-wang · 2020-08-18T18:16:34Z

The logic in mathml core is that all the remaining mstyle attributes are now mapped to CSS and can be attached to any MathML elements. So I don't understand what's discussed here. In general it does not make any sense to talk about mstyle specifically for mathml core, since it's now strictly equivalent to an mrow. As I said on #204 , if this is an issue then it should be fixed for all elements, not mstyle specifically (i.e. use universal selectors).

fred-wang · 2020-08-18T18:18:35Z

I had removed the "mathml core" label BTW, as the simplification is done for mathml core. the only reason why this is still opened is whether there is a need for a polyfill or changes in mathml full.

NSoiffer · 2020-08-18T19:34:04Z

The point is to remove mathvariant as a global attr because it mostly only makes sense when placed on a specific token element to effect a mapping to a different code point. Even for that use, the proper Unicode glyph should have been used. It is unclear why this value was included in the original proposal's "keep" list.

fred-wang · 2020-08-18T21:17:57Z

This was discussed last year and we agreed to make all the mstyle attributes global because it's just easy to map attributes to style without doing all these tag-specific checks to know which element supports what. About completely removing mathvariant, this was also discussed last year and we agreed to keep it in the list because it's still widely used (even if using the proper unicode code point would be better, many tools don't do that). Finally we already have tests for these and implementation changes (I think at least in Chromium).

NSoiffer · 2020-08-19T17:35:32Z

In the last comment on this (Apr 2019) which is about a meeting resolution, only dir, mathsize, mathbackground, mathcolor were listed as being agreed to keep in core. mathvariant is not on the list.

I agree mathvariant is still used, but I don't believe anyone ever sets it on mstyle as it is not a useful thing to do. I don't think we have statistics on its usage on mstyle though so we don't have any info on that front to use in this discussion.

Also, it isn't clear that CSS will support the text-transform change needed as it is not in the latest working draft of CSS Text Module Level 3 so the current Chromium implementation may not be supportable on all platforms.

fred-wang · 2020-08-19T18:03:02Z

In the last comment on this (Apr 2019) which is about a meeting resolution, only dir, mathsize, mathbackground, mathcolor were listed as being agreed to keep in core. mathvariant is not on the list.

This github comment is not complete, the proposal was #1 (comment) and summary says

maps displaystyle, mathvariant, scriptlevel to CSS
remove scriptsizemultiplier and scriptminsize
dir, mathsize, mathbackground, mathcolor: map attribute to existing CSS property
Remove all the other mstyle attributes

which is what we've try to do in the spec/tests/implementation.

I agree mathvariant is still used, but I don't believe anyone ever sets it on mstyle as it is not a useful thing to do. I don't think we have statistics on its usage on mstyle though so we don't have any info on that front to use in this discussion.

Two points:

AFAIK MathJax (and so wikipedia) does not use Unicode characters, but the mathvariant attribute instead. And there are others tools using mstyle@mathvariant (like itex2MML). So we would need to convince them first or claim polyfill is good enough in that case.
As discussed during core meeting, restricting to token elements actually makes things more slightly complicate for browsers since you need to perform per-tag check and have the corresponding tests to check attributes apply to a specific list of elements. So I still don't understand what's the point of doing that? The only explanation is #204 but it can be solved by introducing universal selector, if it's considered a bug rather than a feature. I also prefer consistency and say that "MathML stylistic attributes apply to all mathml elements and are just mapped to CSS properties" which is easy to understand.

Also, it isn't clear that CSS will support the text-transform change needed as it is not in the latest working draft of CSS Text Module Level 3 so the current Chromium implementation may not be supportable on all platforms.

We definitely need automatic mathvariant italic in any case for single-char mi. If the CSS WG rejects or wants change to mathvariant or other proposals then we can adapt accordingly, but I don't think we need to agree before we actually get their feedback. Also IIUC Brian said our text-transform proposal is uncontroversial in the CSSWG now. I think the risk is more on the scriptlevel stuff.

https://bugs.webkit.org/show_bug.cgi?id=202720 Patch by Delan Azabani <[email protected]> on 2020-04-09 Reviewed by Frédéric Wang. In MathML 2, the default mo@maxsize was infinity [1], unless some other default was given by mstyle@maxsize [2]. The sole purpose of "infinity" was to give authors a way to set mo@maxsize to infinity when some other mstyle@maxsize was set. MathML Core removes mstyle@maxsize [3][4], such that "infinity" has the same semantics as any other missing or invalid mo@maxsize, so the spec has been simplified to make infinity an anonymous value [5][6]. No functional change, because WebKit has never supported mstyle@maxsize anyway. To verify that there's no functional change: 1. Search for references to LengthType::Infinity, and observe that the mo@maxsize parser in MathMLOperatorElement::maxSize is the only place where a Length of ::type infinity is created 2. Search for references to that method, and observe that the only caller (RenderMathMLOperator::maxSize) passes intMaxForLayoutUnit (infinity) to toUserUnits as the referenceValue 3. Go to the definition of toUserUnits, and observe that the refer- enceValue is used as the ParsingFailed default 4. Step 1 shows that no other attributes would be affected by removing LengthType::Infinity, and steps 2 and 3 show that mo@maxsize treats invalid values as infinity, therefore it's safe to remove both the "infinity" parsing code and the underlying LengthType variant [1] https://www.w3.org/TR/MathML2/chapter3.html#id.3.2.5.2 [2] https://www.w3.org/TR/MathML2/chapter3.html#presm.mstyle [3] https://mathml-refresh.github.io/mathml-core/#style-change-mstyle [4] w3c/mathml#1 [5] https://mathml-refresh.github.io/mathml-core/#dictionary-based-attributes [6] w3c/mathml#107 No new tests, because no functional change. * mathml/MathMLElement.h: Remove LengthType::Infinity. * mathml/MathMLOperatorElement.cpp: (WebCore::MathMLOperatorElement::maxSize): Remove explicit branch on "infinity". Replace what remains with an equivalent cachedMathMLLength call. * rendering/mathml/RenderMathMLBlock.cpp: (WebCore::toUserUnits): Remove explicit branch on LengthType::Infinity. * rendering/mathml/RenderMathMLOperator.cpp: (WebCore::RenderMathMLOperator::maxSize): Update comment to refer to the default value in the same way as the spec. Canonical link: https://commits.webkit.org/223145@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@259785 268f45cc-cd09-0410-ab3c-d52691b4dbfc

NSoiffer · 2024-12-19T00:25:56Z

I think the "needs resolution" and "needs specification update" labels can be removed, leaving only the need to implement the polyfill.

@fred-wang, @davidcarlisle: agree?

davidcarlisle · 2025-03-15T14:10:17Z

This is a very old issue, just reviewing the current state, mostly mathml4 presentation follows core and makes the relevant attributes valid on all elements. Assuming #531 is merged <mstyle> is the same as <mrow> except that it allows 4 additional attributes (that are not in Core) as such it can't really be simplified a lot more unless we drop it completely. Although we could make those 4 attributes "attributes common to presentation elements" and just say mstyle is the same as mrow kept for legacy reasons.

So in answer to @NSoiffer's comment above, we could leave specification as is (and remove the label) or simply further.

…tyle attributes are ignored., a=testonly Automatic update from web-platform-tests Add MathML tests to check that legacy mstyle attributes are ignored. (#19110) * Add MathML tests to check that legacy mstyle attributes are ignored. See w3c/mathml#1 * Avoid false positives. -- wpt-commits: 0d0f9319b356f46f8bebd82982306b3b0053fa8c wpt-pr: 19110

NSoiffer mentioned this issue Feb 20, 2019

Agenda for Core Meeting #8

Closed

fred-wang added MathML Core Issues affecting the MathML Core specification MathML 4 Issues affecting the MathML 4 specification labels Feb 22, 2019

fred-wang mentioned this issue Feb 22, 2019

New properties for CSS math-variant, script-level and math-style #31

Closed

fred-wang added the css / html5 Issues related to CSS or HTML5 interoperability label Feb 22, 2019

physikerwelt mentioned this issue Feb 25, 2019

Collect usage statistics for current MathML elements #55

Closed

fred-wang mentioned this issue Mar 19, 2019

Remove some deprecated attributes #5

Closed

fred-wang mentioned this issue Mar 20, 2019

Deprecate/Remove mathvariant attributes #77

Closed

fred-wang added the compatibility Issues affecting backward compatibility label Mar 20, 2019

davidfarmer mentioned this issue Apr 25, 2019

Path for adding semantics #84

Closed

This was referenced May 7, 2019

Allow mstyle attributes on more (all?) MathML elements #88

Closed

Deprecate/Remove the mstyle element #89

Closed

fred-wang added need implementation update need polyfill Issues requiring implementation changes need specification update Issues requiring specification changes need tests Issues related to writing WPT tests labels May 16, 2019

NSoiffer mentioned this issue May 29, 2019

Chemistry and math layout #92

Closed

fred-wang removed the need tests Issues related to writing WPT tests label Sep 17, 2019

fred-wang closed this as completed Sep 17, 2019

NSoiffer reopened this May 20, 2020

fred-wang removed the MathML Core Issues affecting the MathML Core specification label May 22, 2020

brucemiller mentioned this issue May 24, 2020

[Discussion] A proposal for disentangling markup patterns from semantics for accessibility #217

Closed

NSoiffer added the need resolution Issues needing resolution at MathML Refresh CG meeting label Aug 17, 2020

NSoiffer mentioned this issue Jun 28, 2021

Add scriptsizemultiplier to core w3c/mathml-core#39

Open

faceless2 mentioned this issue Jun 29, 2021

mstyle mathvariant inheritance and mi w3c/mathml-core#53

Open

davidcarlisle mentioned this issue Mar 4, 2022

Appendix A: Add links to pmml and common rnc files #189

Closed

bkardell mentioned this issue Mar 30, 2022

MathML Core w3ctag/design-reviews#438

Closed

5 tasks

OnkarRuikar mentioned this issue Aug 12, 2022

Mark 'scriptsizemultiplier' and 'scriptminsize' deprecated mdn/browser-compat-data#17325

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Simplification of the mstyle element #1

Simplification of the mstyle element #1

fred-wang commented Feb 14, 2019 •

edited

Loading

physikerwelt commented Feb 19, 2019

fred-wang commented Feb 19, 2019

fred-wang commented Feb 19, 2019

davidcarlisle commented Feb 19, 2019

dani31415 commented Feb 25, 2019

physikerwelt commented Feb 25, 2019

fred-wang commented Mar 14, 2019

fred-wang commented Mar 14, 2019

dani31415 commented Mar 15, 2019 •

edited

Loading

fred-wang commented Mar 19, 2019

fred-wang commented Mar 22, 2019

NSoiffer commented Apr 29, 2019 •

edited by fred-wang

Loading

fred-wang commented May 16, 2019

NSoiffer commented May 20, 2020

NSoiffer commented Aug 17, 2020

NSoiffer commented Aug 18, 2020

fred-wang commented Aug 18, 2020

fred-wang commented Aug 18, 2020

NSoiffer commented Aug 18, 2020

fred-wang commented Aug 18, 2020

NSoiffer commented Aug 19, 2020

fred-wang commented Aug 19, 2020

NSoiffer commented Dec 19, 2024

davidcarlisle commented Mar 15, 2025

Simplification of the mstyle element #1

Simplification of the mstyle element #1

Comments

fred-wang commented Feb 14, 2019 • edited Loading

physikerwelt commented Feb 19, 2019

fred-wang commented Feb 19, 2019

fred-wang commented Feb 19, 2019

davidcarlisle commented Feb 19, 2019

dani31415 commented Feb 25, 2019

physikerwelt commented Feb 25, 2019

fred-wang commented Mar 14, 2019

fred-wang commented Mar 14, 2019

dani31415 commented Mar 15, 2019 • edited Loading

fred-wang commented Mar 19, 2019

fred-wang commented Mar 22, 2019

NSoiffer commented Apr 29, 2019 • edited by fred-wang Loading

fred-wang commented May 16, 2019

NSoiffer commented May 20, 2020

NSoiffer commented Aug 17, 2020

NSoiffer commented Aug 18, 2020

fred-wang commented Aug 18, 2020

fred-wang commented Aug 18, 2020

NSoiffer commented Aug 18, 2020

fred-wang commented Aug 18, 2020

NSoiffer commented Aug 19, 2020

fred-wang commented Aug 19, 2020

NSoiffer commented Dec 19, 2024

davidcarlisle commented Mar 15, 2025

fred-wang commented Feb 14, 2019 •

edited

Loading

dani31415 commented Mar 15, 2019 •

edited

Loading

NSoiffer commented Apr 29, 2019 •

edited by fred-wang

Loading