Expose height/depth info

[NSoiffer]

Having written a bunch of "polyfills" for MathML, there were three pieces of missing functionality that required hacks to implement: find the height/depth of an element, convert a CSS length value to pixels (e.g., '3em'), and clone an element including it's shadow root. The later two issues are not specific to MathML, but MathML is somewhat unique in defining and using an element's height above the baseline and depth below the baseline.

Rather than having to rely on a hack, MathML elements should provide a method to get this information. This could be an extension of getBoundingClientRect that adds baseline info or depth (since height above baseline is easily computed from that) or it could be an entirely new method that returns height/depth/width info (the later often being useful when doing computations involving box dimensions.

[bkardell]

I'm not sure I understand why/what you're suggesting MathML should provide here and why it should be particular to MathML? I'd like to not get back into co-evolution problems where we try to solve a thing in MathML that winds up being better solved elsewhere. If this is about consulting box dimensions of some kind, it seems like it belongs to csswg?

[NSoiffer]

I agree that this is an issue that the CSS WG should address. However, since the need comes from manipulating MathML, it seems appropriate for us to come up with use cases and a proposal rather than just saying this is a problem and watching the issue get no attention. It is much easier to respond to a proposal than to a problem, even when the proposal is not a good one.

[ronkok]

I applaud this proposal, especially regarding the height/depth of an element relative to the baseline.

For a use case, I would like to implement the equivalent of the LaTeX \vcenter function. MathML Core does not currently enable this function. That's ok! It is used very infrequently. But if height and depth could be queried, then a \vcenter polyfill becomes feasible.

[stefnotch]

Another use-case: I'm writing a math editor. To do so, I have to overlay a caret onto a formula. Figuring out the x-coordinate is easy.
However, figuring out the caret's height and y-coordinate is very difficult right now. Ideally, it would be placed on the baseline (marked in red) and would be as high as the math-depth dictates.

One silly hack that would probably work right now is inserting a dummy element, figuring out where it is and removing it again.

[bkardell]

Discussed this in the core meeting today, we believe that this belongs to CSS, and will find the relevant issue or create a new one. Once we have that/those we can link it here and this issue can be closed.

[stefnotch]

Is there a CSS issue for this that I can follow?

I'm not sure if my "inserting an empty mphantom element" for getting the baseline is correct in the general case. After all, inserting an empty element does sometimes change the MathML rendering.

e.g. Those two render differently on Chrome.

<math>
  <mn>1</mn><mo><mphantom></mphantom>-</mo>
</math>
<br>
<math>
  <mn>1</mn><mo>-</mo>
</math>

e.g. Those render differently on Firefox
https://jsfiddle.net/dy4t7k52/

[stefnotch]

Regarding the shape of a hypothetical "find the height/depth of an element" API, I think it's worthwhile to keep #127 in mind.

After all, asking what the height/depth of an mrow is doesn't necessarily make sense, if the mrow has been wrapped onto two or more lines. Instead, I'd propose doing it more like getClientRects (and its range API equivalent). The getClientRects method will return multiple rectangles when the content has been wrapped onto a newline.

One of my current use-cases would be rendering squiggly red lines in formulas where something is wrong. I'd prefer to be able to overlay those lines, instead of having to invasively change the MathML.

For the record, using text-decoration yields a pretty messy result.
Microsoft Edge renders this

and Firefox doesn't render it at all. :(