Define if width/height/inline-size/block-size are supported. #75

bfgeek · 2019-02-25T18:10:26Z

A simple test case:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=6693

Safari appears to support height at least on the element, however firefox appears not to?

From an implementation POV it may be easier just to support all width/height/etc on all elements, however this gets into how to define the internal MathML algorithms.

On the element this needs tests for various values of width/height, and within various formatting contexts, e.g. flex (does it respect flex-basis properly), grid, etc.

bfgeek · 2019-02-25T19:25:23Z

Oh this is more fun as it appears to selectively apply to certain elements, e.g.
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=6706

fred-wang · 2019-07-05T11:58:07Z

I think we are now ready to handle this, so I'll put this on the agenda of the nxt MathML CG meeting.

Currently, each MathML box layout its content without linebreaking. The content box is defined to be the one of generated by the content:
https://mathml-refresh.github.io/mathml-core/#layout-algorithms

If width/height/inline-size/block-size are useful, a simple interpretation for now would be to set the content box to the specified size and let the content overflow.

rwlbuis · 2019-07-16T07:28:57Z

Supporting width/height properties in MathML could potentially make things simpler in the implementation since a lot of layout/rendering code expects width/height info.

I am not sure on all the details though. As usual CSS property vs presentation attribute has to be defined, i.e. which one wins ultimately. For mspace, width property could override the width attribute, but how do ascent/descent attribute and height property interact? We'll probably have to look per element how much sense it makes.

fred-wang · 2019-07-16T07:58:32Z

I am not sure on all the details though. As usual CSS property vs presentation attribute has to be defined, i.e. which one wins ultimately. For mspace, width property could override the width attribute, but how do ascent/descent attribute and height property interact? We'll probably have to look per element how much sense it makes.

With my generic proposal for MathML, <mspace width="100px" height="50px" depth="50px" style="width: 50px; height: 200px;"> would still create a 100px square (MathML content) but the content box would have size 50px X 200px so the mspace will have visible overflow on the inline axis and be aligned along the line-over edge (or follows any consistent block alignment rule).

rwlbuis · 2019-07-16T08:10:14Z

For mspace, width property could override the width attribute, but how do ascent/descent attribute and height property interact?

Oops, I meant height/depth here instead of ascent/descent.

fred-wang · 2019-07-16T08:27:25Z

To be clear, we have a general layout algorithm described here:

https://mathml-refresh.github.io/mathml-core/#layout-algorithms

So we have:

The box obtained when content is laid out, described in other individual sections. Let's call it the "math box" for convenience.
The CSS content box which is currently defined to be the same as the "math box".
The CSS padding/border/margin boxes which are described in this section from the CSS content box.

My generic proposal is to interpret width/height as follows for most MathML elements:
(1) Percent width/height are interpreted relative to the "math box" dimensions.
(2) The content box takes the width/height specified by CSS (A).
(3) The inline-start edge of the "math box" is aligned with the inline-start edge of the content box. The line-over edge of the "math box" is aligned with the line-over edge of the content box. (B)
(4) If the specified width (respectively height) is smaller than the one of the "max box" then the "math box" will overflow (C).

(A) Assuming we ignore box-sizing for now. Small adjustment will be needed if we support the border-box value.
(B) Assuming we ignore alignment properties for now.
(C) Assuming we ignore overflow for now. For other other values than "overflow", we might need to introduce anonymous block container or something.

As Neil noted, for the <math> root it makes sense to keep the CSS interpretation of width/height for display: block and inline.

We might also want to consider width/height for the actual layout of the "math box". For example an mrow might take into account the width to perform some line breaking, an mfrac can pass the width constraint to the numerator/denominator or an mspace/mpadded element can have special interpretation according to its attribute. But indeed this special cases would need more analysis than my general proposal, so maybe that should be defined later.

Finally, there is the option of just ignoring width/height on MathML elements.

fred-wang · 2019-07-29T17:48:35Z

Consensus during mathml core meeting: Ignore width/height on all new layout as they are no clear use case and that simplifies implementation. It still makes sense for mtable or math elements.

See https://github.com/mathml-refresh/mathml/issues/45

…eb-platform-tests#18171) * MathML: Add test to verify that new math layout ignore width/height See https://github.com/mathml-refresh/mathml/issues/45

… layout ignore width/height, a=testonly Automatic update from web-platform-tests MathML: Add test to verify that new math layout ignore width/height (#18171) * MathML: Add test to verify that new math layout ignore width/height See https://github.com/mathml-refresh/mathml/issues/45 -- wpt-commits: 73a80e4008e7757e46ecb68f64797e9499ec5892 wpt-pr: 18171 --HG-- rename : testing/web-platform/tests/mathml/relations/css-styling/padding-border-margin/helper.js => testing/web-platform/tests/mathml/support/box-comparison.js

… layout ignore width/height, a=testonly Automatic update from web-platform-tests MathML: Add test to verify that new math layout ignore width/height (#18171) * MathML: Add test to verify that new math layout ignore width/height See https://github.com/mathml-refresh/mathml/issues/45 -- wpt-commits: 73a80e4008e7757e46ecb68f64797e9499ec5892 wpt-pr: 18171

…eb-platform-tests#18171) * MathML: Add test to verify that new math layout ignore width/height See https://github.com/mathml-refresh/mathml/issues/45

fred-wang · 2019-09-15T08:33:15Z

The spec now says that it is ignored for elements with "display: math"

… layout ignore width/height, a=testonly Automatic update from web-platform-tests MathML: Add test to verify that new math layout ignore width/height (#18171) * MathML: Add test to verify that new math layout ignore width/height See https://github.com/mathml-refresh/mathml/issues/45 -- wpt-commits: 73a80e4008e7757e46ecb68f64797e9499ec5892 wpt-pr: 18171 UltraBlame original commit: fc19eb5d4698849e1e57224e69c60a3263ac8388

rwlbuis · 2019-12-09T13:55:10Z

Ian would like to reconsider this:
https://chromium-review.googlesource.com/c/chromium/src/+/1913250/8/third_party/blink/renderer/core/layout/ng/mathml/ng_math_row_layout_algorithm.cc#14

Test:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7503

rwlbuis · 2019-12-09T14:30:52Z

After playing a bit with above live-dom-viewer link, I have these findings:

I was not able to create a scrollbar due to overflow in FF or Safari implementations.
Implementations seem to behave differently to width/height on outer , FF needs a position:absolute before it uses width/height values, whereas in Safari the width is the same, but height is always used (independent of position:absolute).
for FF does not seem to ignore width/height, whereas Safari again only considers height.

bfgeek · 2019-12-09T16:25:13Z

The situation is somewhat more complex than above, e.g. consider this example:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7530

Here both implementations respect the width&height properties, if the outer display is flex.
And both implementations here will trigger scroll:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7531

(this also occurs when the outer div has display: grid etc.)
There are other subtle interactions to consider, e.g. what the flex-basis is when stretching, etc.

It is probably an order of magnitude more work to ignore the width/height properties correctly, than to consistently apply them.
Ian

rwlbuis · 2019-12-09T16:57:34Z

In the 7530 and 7531 examples mi stops being a MathML element AFAIK, so it may as well have been a div or something. To me it may be more interesting to know what the MathML behavior has been up until now. Hopefully we can discuss this issue tonight during the Core MathML meeting.

I guess what you are saying is that if we want to make MathML behave like grid and flexbox, we will see similar behavior on 7530 and 7531, and hence scrollbars?

Are you in favor of width/height support on MathML containers only, or just every MathML element?

bfgeek · 2019-12-11T02:53:56Z

Just every MathML element would be more straight forward.

It also looks like due to implementations relying on the table impls, width/height are also respected on etc, currently.

rwlbuis · 2019-12-11T20:27:23Z

If we support width/height, min/max-width and min/max-height logically follow from that?

I have been reading up on MathML3, and it seems it has a concept of max-width/width for <math< element, just through a non standard attribute rather than properties. I guess we already agreed to drop most of those old attributes though.

bfgeek · 2019-12-13T00:02:11Z

If we support width/height, min/max-width and min/max-height logically follow from that?

Yeah that's right.

If we also get the attr() function in css we can map these directly to these properties. E.g.
mspace {
width: attr(width);
height: attr(height);
}

rwlbuis · 2019-12-13T06:23:03Z

If we support width/height, min/max-width and min/max-height logically follow from that?

Yeah that's right.

Good to know :)

If we also get the attr() function in css we can map these directly to these properties. E.g.
mspace {
width: attr(width);
height: attr(height);
}

mspace is a bit different regarding the height:
https://mathml-refresh.github.io/mathml-core/#space-mspace

It does have width/height attributes but adds a depth attribute for the descent, so this adds to the block height.I think MathML people will keep expecting the height+depth combo, so I don't think we can change the spec. I do wonder though, could we use CSS calc?

bfgeek · 2019-12-13T17:22:03Z

Yeah I believe that:

mspace {
  height: calc(attr(height) + attr(depth));
}

should work?

rwlbuis · 2019-12-13T17:31:39Z

Yeah I believe that:
mspace {
  height: calc(attr(height) + attr(depth));
}
should work?

Quite likely, I can experiment with that. Only remaining special thing about mspace left would then be baseline alignment. I guess we could do some tricks for that too or create a special layout algorithm (as we do right now in our internal branch).

This is just one MathML element, we probably still need to discuss suitability of w/h for the others, I'll try to put it on the agenda for Monday's Core meeting.

NSoiffer · 2019-12-16T07:34:19Z

It's on the agenda for the 16 Dec meeting.

rwlbuis · 2019-12-16T21:57:13Z

@bfgeek we will likely go with width/height. I was wondering if you have an opinion on Fred's proposal?:
https://github.com/mathml-refresh/mathml/issues/45#issuecomment-511718819

rwlbuis · 2020-01-01T11:53:48Z

If we also get the attr() function in css we can map these directly to these properties. E.g.
mspace {
width: attr(width);
height: attr(height);
}

Just learned that this is not supported in Chromium atm:
https://bugs.chromium.org/p/chromium/issues/detail?id=246571

I guess that is what you hinted at with "If we also get the attr() function in css" ?

…mpadded attributes, a=testonly Automatic update from web-platform-tests [mathml] Refactor parsing of mspace and mpadded attributes Currently, the mspace and mpadded elements use different approaches to parse the width/height/depth/lspace/voffset attributes: - AddPropertyToPresentationAttributeStyle for the value (sometimes excluding values that ends with a '%' character). - AddPropertyToPresentationAttributeStyle for a calc expression built from the values of the height and depth attributes. - Using AddMathLengthToComputedStyle (sometimes accepting percentage) which relies on CSSParser::ParseLengthPercentage, but these parsing methods seem incorrect. The initial goal was to use the default value when a percentage is specified and this is what is currently specified in MathML Core [1] [2]. However, the current implementation has bugs that make percentage accepted in some cases [3] or unnecessarily mapping invalid values to presentational hints. This CL tries to bring more consistency on the parsing side by always delegating the parsing of the attribute value to CSSParser::ParseLengthPercentage before mapping it to presentational hint or internal properties. The parsing parameter AllowPercentages::kNo is used to ensure percentages are always treated as invalid. CSSParser::ParseLengthPercentage is also refine to always trim whitespaces, and check there is no remaining token after the parsed <length-percentage>. This refactoring will facilitate specifying Chrome's behavior in MathML Core regarding interaction with CSS width/height properties, handling of percentages and use of presentational hints [4]. [1] https://w3c.github.io/mathml-core/#space-mspace [2] https://w3c.github.io/mathml-core/#inner-box-and-requested-parameters [3] crbug.com/1402998 [4] w3c/mathml-core#75 (comment) Bug: 6606, 1402998 Change-Id: Ibe4e49af4c3f4aeb5c153e10b4ba93d26db20849 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4120274 Commit-Queue: Frédéric Wang <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> Reviewed-by: Ian Kilpatrick <[email protected]> Cr-Commit-Position: refs/heads/main@{#1090758} -- wpt-commits: c600fdea10babeeb9961f019c8fd62aa18bda645 wpt-pr: 37651

fred-wang · 2023-01-23T11:36:08Z

#184 is now ready for review.

@rwlbuis Since you are the one who originally implemented mspace/mpadded in Chrome, can you please the text? Thanks!

Just got approval from rob and no opposition for 2 weeks, so I guess I'll merge this PR and update WPT tests accordingly.

* Specify how to handle width/height properties This tries to align with Chromium's implementation, see #75 (comment) * Align mspace/mpadded attribute parsing on Blink. See also https://chromium-review.googlesource.com/c/chromium/src/+/4120274

fred-wang · 2023-01-31T15:45:14Z

This is merged. I'll close this issue when tests are updated.

Math WG decided that width/height should be taken into account on all MathML elements [1]. This CL updates the following legacy tests that assume the properties are actually ignored [2]: * `ignored-properties-001.html`: This test was checking the properties are ignored. Remove these checks. * `width-height-001.html`: This test was checking the elements keep the same dimension with or without specifying width, height, inline-size or block-size. Change it to actually verify it does take the specified dimensions. * `display-1.html`: This test was checking that the content of a `<math display=block>` with a specified width is horizontally centered inside a parent div. Now that the width is no longer ignored, instead check that it is horizontally centered within the `math` element. More tests will be added in follow-up CLs to further check the effect of specifying width/height on elements. [1] w3c/mathml-core#75 [2] web-platform-tests/interop#197 (comment) Bug: 6606 Change-Id: I6ff46b7589f27cc16ba81db126a4ceaa3a31ef61

Math WG decided that width/height should be taken into account on all MathML elements [1]. This CL updates the following legacy tests that assume the properties are actually ignored [2]: * `ignored-properties-001.html`: This test was checking the properties are ignored. Remove these checks. * `width-height-001.html`: This test was checking the elements keep the same dimension with or without specifying width, height, inline-size or block-size. Change it to actually verify it does take the specified dimensions. * `display-1.html`: This test was checking that the content of a `<math display=block>` with a specified width is horizontally centered inside a parent div. Now that the width is no longer ignored, instead check that it is horizontally centered within the `math` element. More tests will be added in follow-up CLs to further check the effect of specifying width/height on elements. [1] w3c/mathml-core#75 [2] web-platform-tests/interop#197 (comment) Bug: 6606 Change-Id: I6ff46b7589f27cc16ba81db126a4ceaa3a31ef61 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4221437 Reviewed-by: Ian Kilpatrick <[email protected]> Quick-Run: Rob Buis <[email protected]> Commit-Queue: Frédéric Wang <[email protected]> Cr-Commit-Position: refs/heads/main@{#1103391}

…ight This is a followup of [1] with more tests for MathML elements that have a specified width/height: - frac-bar-003.html: Verify that the painted bar takes the specified width, not the one of the children. - width-height-001.html: Don't skip mtable (in the past the test was checking the properties are ignored, but this changed in [1]). - width-height-002.html, width-height-003.html: Add tests to verify the position where the math content is rendered when a larger width/height is specified. - TestExpectations: Remove obsolete Failure expectations. [1] https://chromium-review.googlesource.com/c/chromium/src/+/4221437 [2] w3c/mathml-core#75 Bug: 6606 Change-Id: I5ea7c33eed9fde8b53ccd0400e6fcfa5eab055a0

…ight This is a followup of [1] with more tests for MathML elements that have a specified width/height: - frac-bar-003.html: Verify that the painted bar takes the specified width, not the one of the children. - width-height-001.html: Don't skip mtable (in the past the test was checking the properties are ignored, but this changed in [1]). - width-height-002.html, width-height-003.html: Add tests to verify the position where the math content is rendered when a larger width/height is specified. - TestExpectations: Remove obsolete Failure expectations. [1] https://chromium-review.googlesource.com/c/chromium/src/+/4221437 [2] w3c/mathml-core#75 Bug: 6606 Change-Id: I5ea7c33eed9fde8b53ccd0400e6fcfa5eab055a0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4233950 Commit-Queue: Frédéric Wang <[email protected]> Reviewed-by: Ian Kilpatrick <[email protected]> Cr-Commit-Position: refs/heads/main@{#1103928}

fred-wang · 2023-02-14T07:46:33Z

We have minimal test coverage after these PR, so closing:

web-platform-tests/wpt#38361
web-platform-tests/wpt#38443
web-platform-tests/wpt#38466

…S width/height are ignored, a=testonly Automatic update from web-platform-tests [mathml] Update WPT tests that assume CSS width/height are ignored Math WG decided that width/height should be taken into account on all MathML elements [1]. This CL updates the following legacy tests that assume the properties are actually ignored [2]: * `ignored-properties-001.html`: This test was checking the properties are ignored. Remove these checks. * `width-height-001.html`: This test was checking the elements keep the same dimension with or without specifying width, height, inline-size or block-size. Change it to actually verify it does take the specified dimensions. * `display-1.html`: This test was checking that the content of a `<math display=block>` with a specified width is horizontally centered inside a parent div. Now that the width is no longer ignored, instead check that it is horizontally centered within the `math` element. More tests will be added in follow-up CLs to further check the effect of specifying width/height on elements. [1] w3c/mathml-core#75 [2] web-platform-tests/interop#197 (comment) Bug: 6606 Change-Id: I6ff46b7589f27cc16ba81db126a4ceaa3a31ef61 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4221437 Reviewed-by: Ian Kilpatrick <[email protected]> Quick-Run: Rob Buis <[email protected]> Commit-Queue: Frédéric Wang <[email protected]> Cr-Commit-Position: refs/heads/main@{#1103391} -- wpt-commits: 9352b1202118d24b297659cd15dd92a5215a9c05 wpt-pr: 38361

…ithms with specified width/height, a=testonly Automatic update from web-platform-tests [mathml] Add more tests for layout algorithms with specified width/height This is a followup of [1] with more tests for MathML elements that have a specified width/height: - frac-bar-003.html: Verify that the painted bar takes the specified width, not the one of the children. - width-height-001.html: Don't skip mtable (in the past the test was checking the properties are ignored, but this changed in [1]). - width-height-002.html, width-height-003.html: Add tests to verify the position where the math content is rendered when a larger width/height is specified. - TestExpectations: Remove obsolete Failure expectations. [1] https://chromium-review.googlesource.com/c/chromium/src/+/4221437 [2] w3c/mathml-core#75 Bug: 6606 Change-Id: I5ea7c33eed9fde8b53ccd0400e6fcfa5eab055a0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4233950 Commit-Queue: Frédéric Wang <[email protected]> Reviewed-by: Ian Kilpatrick <[email protected]> Cr-Commit-Position: refs/heads/main@{#1103928} -- wpt-commits: 7b80eda0eaf5c083674bd72f5b4d5c7e5e2be955 wpt-pr: 38443

Math WG decided that width/height should be taken into account on all MathML elements [1]. This CL updates the following legacy tests that assume the properties are actually ignored [2]: * `ignored-properties-001.html`: This test was checking the properties are ignored. Remove these checks. * `width-height-001.html`: This test was checking the elements keep the same dimension with or without specifying width, height, inline-size or block-size. Change it to actually verify it does take the specified dimensions. * `display-1.html`: This test was checking that the content of a `<math display=block>` with a specified width is horizontally centered inside a parent div. Now that the width is no longer ignored, instead check that it is horizontally centered within the `math` element. More tests will be added in follow-up CLs to further check the effect of specifying width/height on elements. [1] w3c/mathml-core#75 [2] web-platform-tests/interop#197 (comment) Bug: 6606 Change-Id: I6ff46b7589f27cc16ba81db126a4ceaa3a31ef61 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4221437 Reviewed-by: Ian Kilpatrick <[email protected]> Quick-Run: Rob Buis <[email protected]> Commit-Queue: Frédéric Wang <[email protected]> Cr-Commit-Position: refs/heads/main@{#1103391}

…ight This is a followup of [1] with more tests for MathML elements that have a specified width/height: - frac-bar-003.html: Verify that the painted bar takes the specified width, not the one of the children. - width-height-001.html: Don't skip mtable (in the past the test was checking the properties are ignored, but this changed in [1]). - width-height-002.html, width-height-003.html: Add tests to verify the position where the math content is rendered when a larger width/height is specified. - TestExpectations: Remove obsolete Failure expectations. [1] https://chromium-review.googlesource.com/c/chromium/src/+/4221437 [2] w3c/mathml-core#75 Bug: 6606 Change-Id: I5ea7c33eed9fde8b53ccd0400e6fcfa5eab055a0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4233950 Commit-Queue: Frédéric Wang <[email protected]> Reviewed-by: Ian Kilpatrick <[email protected]> Cr-Commit-Position: refs/heads/main@{#1103928}

fred-wang referenced this issue in web-platform-tests/wpt Jul 30, 2019

MathML: Add test to verify that new math layout ignore width/height

a2f54d1

See https://github.com/mathml-refresh/mathml/issues/45

fred-wang referenced this issue in web-platform-tests/wpt Jul 30, 2019

MathML: Add test to verify that new math layout ignore width/height

4bcc726

See https://github.com/mathml-refresh/mathml/issues/45

chromium-wpt-export-bot mentioned this issue Feb 4, 2023

[mathml] Update WPT tests that assume CSS width/height are ignored web-platform-tests/wpt#38361

Merged

chromium-wpt-export-bot mentioned this issue Feb 10, 2023

[mathml] Add more tests for layout algorithms with specified width/height web-platform-tests/wpt#38443

Merged

fred-wang removed needs-tests Agenda labels Feb 14, 2023

fred-wang closed this as completed Feb 14, 2023

fred-wang mentioned this issue Mar 8, 2023

Horizontal alignment of MathML elements with horizontal overflow #190

Open

fred-wang added css/html5 and removed css / html5 labels Jul 19, 2023

fred-wang mentioned this issue Sep 5, 2024

Consider support for the box-sizing property #257

Open

fred-wang mentioned this issue Sep 18, 2024

Interaction between height and baseline alignment #259

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Define if width/height/inline-size/block-size are supported. #75

Define if width/height/inline-size/block-size are supported. #75

bfgeek commented Feb 25, 2019

bfgeek commented Feb 25, 2019

fred-wang commented Jul 5, 2019

rwlbuis commented Jul 16, 2019

fred-wang commented Jul 16, 2019

rwlbuis commented Jul 16, 2019

fred-wang commented Jul 16, 2019 •

edited

Loading

fred-wang commented Jul 29, 2019

fred-wang commented Sep 15, 2019 •

edited

Loading

rwlbuis commented Dec 9, 2019

rwlbuis commented Dec 9, 2019

bfgeek commented Dec 9, 2019

rwlbuis commented Dec 9, 2019

bfgeek commented Dec 11, 2019

rwlbuis commented Dec 11, 2019

bfgeek commented Dec 13, 2019 •

edited

Loading

rwlbuis commented Dec 13, 2019

bfgeek commented Dec 13, 2019

rwlbuis commented Dec 13, 2019

NSoiffer commented Dec 16, 2019

rwlbuis commented Dec 16, 2019

rwlbuis commented Jan 1, 2020

fred-wang commented Jan 23, 2023

fred-wang commented Jan 31, 2023

fred-wang commented Feb 14, 2023

Define if width/height/inline-size/block-size are supported. #75

Define if width/height/inline-size/block-size are supported. #75

Comments

bfgeek commented Feb 25, 2019

bfgeek commented Feb 25, 2019

fred-wang commented Jul 5, 2019

rwlbuis commented Jul 16, 2019

fred-wang commented Jul 16, 2019

rwlbuis commented Jul 16, 2019

fred-wang commented Jul 16, 2019 • edited Loading

fred-wang commented Jul 29, 2019

fred-wang commented Sep 15, 2019 • edited Loading

rwlbuis commented Dec 9, 2019

rwlbuis commented Dec 9, 2019

bfgeek commented Dec 9, 2019

rwlbuis commented Dec 9, 2019

bfgeek commented Dec 11, 2019

rwlbuis commented Dec 11, 2019

bfgeek commented Dec 13, 2019 • edited Loading

rwlbuis commented Dec 13, 2019

bfgeek commented Dec 13, 2019

rwlbuis commented Dec 13, 2019

NSoiffer commented Dec 16, 2019

rwlbuis commented Dec 16, 2019

rwlbuis commented Jan 1, 2020

fred-wang commented Jan 23, 2023

fred-wang commented Jan 31, 2023

fred-wang commented Feb 14, 2023

fred-wang commented Jul 16, 2019 •

edited

Loading

fred-wang commented Sep 15, 2019 •

edited

Loading

bfgeek commented Dec 13, 2019 •

edited

Loading