Adjusted height & depth of elements moved via voffset

The <mpadded> element has a voffset attribute, which enables one to shift the vertical alignment of an element. However, the MathML-Core specification makes no mention of what happens to the height and depth of an element that is so shifted.

In practice, neither Chromium nor Gecko currently changes the height or depth of an element that is shifted via voffset. In MathML 3.0, one could manually adjust the height and depth via attribute adjustments such as height="+6pt". MathML core does not have such a ± adjustment.

Some way is needed to make that adjustment of height and depth. Otherwise, one will see elements impinging on fraction bars, radical bars, and the like.

Currently in Chromium, one can apply CSS padding and that will increase the height or the depth of the element, depending on whether the padding is applied to the top or the bottom of the element. Gecko does not behave this way. So I know of no way to currently write an adjustment to height and depth that will run correctly in both browsers.

Is the padding hack a valid way to address this dilemma? Will it continue to run in future versions of Chromium and perhaps the other browsers? Should this hack be explicitly written into the MathML Core specification?

Or will some other means of height adjustment become part of MathML-Core? Perhaps a return of the ± notation?

Start by reading the MathML Core rules for and voffset, then compare the Chromium and Gecko behavior described in the issue. A complete outcome should choose and specify an interoperable way to adjust height and depth, including whether CSS padding or ±-style adjustment is normative.