Negative spacing

[fred-wang]

"The present document assumes that W,w,a,b,A,BW,w,a,b,A,B, italic correction and top accent attachment are nonnegative values. If computations result in negative values, then they must be interpreted as being zero. Note that some MathML elements such as mspace or mpadded may set box dimensions to negative values." In the future, we should explain how to handle negative spacing.

original report: https://gitlab.com/mathml/MathMLinHTML5/issues/31

[NSoiffer]

Negative horizontal values can be tricky around linebreaks as they may not be intended if not paired with their neighbors. Other than that, what problems do you see with negative values? My memory from my MathPlayer implementation days is that negative values do occur for some of those values and are reasonable.

It would be good to enumerate in this issue the problems that happen if a value is negative rather than just force them to be zero. Forcing them to zero is probably not right for at least some of these values. For example, "-" has a negative depth ("b") and it is likely wrong to make the element taller by forcing the depth to be 0.

[fred-wang]

I agree negative spacing is needed. The basic implementation of mspace is just setting a box of the desired dimensions. I'm not sure you can specify negative box sizes in layout so this would need to be handled differently (probably implemented as negative margin?). Again, I believe this is something to carefully analyzed with web engines' implementers.

[physikerwelt]

I hope that there is a solution that we can simply adopt. Maybe SVG has already a method for negative spaces.

[fred-wang]

Might be related to w3c/mathml#14

[fred-wang]

With the current writing of the spec, the lspace/rspace are no longer part of the content box of the embellished op but are added in mrow so negative spacing is easier to describe. Maybe we should have the same lspace/rspace box properties for mspace or mpadded and generalize to any box.

[davidcarlisle]

@fred-wang could you clarify what specification change you had in mind when adding the label?

[fred-wang]

@davidcarlisle Sorry, I don't remember exactly. But anyway I checked last week how to export the following == reftest from Gecko:

https://searchfox.org/mozilla-central/rev/2a867dd1ab015c3ef24b774a57709fb3b3dc4961/layout/reftests/mathml/operator-1.xhtml
https://searchfox.org/mozilla-central/rev/2a867dd1ab015c3ef24b774a57709fb3b3dc4961/layout/reftests/mathml/operator-1-ref.xhtml

I checked that:

1. Gecko assumes that negative lspace/rspace are invalid and use default spacing instead.
2. Chromium assumes accepts the values but clamp them to 0 during layout.
3. The current MathML Core spec seems to accept negative lspace/rspace and the layout is done without clamping: https://www.w3.org/TR/mathml-core/#dfn-lspace and https://www.w3.org/TR/mathml-core/#layout-of-mrow
4. Not sure about WebKit.

Current spec allows negative spacing via lspace/rspace. However, as I mentioned in #132 (comment) css boxes can't have negative width so we would still need to do some clamping because something like <mrow><mn>1</mn><mo lspace="-10em">+</mo><mn>2</mn></mrow> is wrong with the current text.

My recommendation would be to choose the safest option as a first step: either clamp during layout or reject negative values and make sure implementations are consistent.

Additionally, I'm only mentioning negative lspace/rspace on the mo element here but we need similar considerations for mspace and mpadded (I believe currently spec and implementation just clamp or prevent negative spacing in order to be safe).

Finally note that web-platform/tests/mathml/crashtests contains various crashtests for negative spacing that were found by fuzzers, so again that's really something to consider with care here.