Extend mpadded attribute syntax to be closer to MathML3

[fred-wang]

In #81, we agreed that mpadded attributes in MathML Core should only use pseudo-unit with the same vertical/horizontal direction.

Can we simplify it any further? Remove/Deprecate it?

Some thoughts:

• MathML discourage authors from using mpadded for tweaking or conveying meaning: https://mathml-refresh.github.io/mathml/chapter3.html#presm.warnfinetuning
• In general, since MathML3 did not clearly specify rendering, implementation are inconsistent and usage is probably unreliable.
• CSS is more appropriate for this kind of space tuning. I imagine if we better define MathML interactions with out-of-flow position #16, margin/border/padding Ensure good integration of MathML with the accessibility tree #9, vertical-align CSS interoperability with vertical-align #13, aspect-ratio etc authors could use these alternatives.
• mpadded is probably used a lot, though. We would need to get better statistics and analysis of current use cases.

[fred-wang]

These are the possible non-length values implemented by @distler in itex2MML and copied into TeXZilla:
lspace="-100%width" (\mathllap)
lspace="-50%width" (\mathclap)
height="+[LENGTH][UNIT]" (\mathraisebox)
depth="+[LENGTH][UNIT]" (\mathraisebox)
depth="depth" (\mathraisebox)

depth="depth" can basically be replaced with not using (or ignoring) the attribute. I'm not exactly sure about how the other commands work.

[fred-wang]

From https://mathml-refresh.github.io/mathml/chapter3.html#presm.mpadded

For any unsigned number X, if Y = X / 100 then

X%pseudo-unit is equivalent to Ypseudo-unit
+X%pseudo-unit is equivalent to +Ypseudo-unit
-X%pseudo-unit => -Ypseudo-unit

So it seems that this syntax is not useful.

[fred-wang]

I've rewritten the description of mpadded in MathML core, so that it no longer refers to MatHML3
https://mathml-refresh.github.io/mathml-core/#adjust-space-around-content-mpadded

Unless I'm mistaken, the current syntax and semantic should more or less match what is in the full spec:
https://mathml-refresh.github.io/mathml/#presm_mpaddedatt
(with namedspace removed and numbers defined from CSS)

[NSoiffer]

As far as I can see, the only difference in attrs is in the pseudo units being slightly restricted: the vertical attrs can only refer to height/depth (not width) and the horizontal ones only to width (not height/depth). Is there something else a polyfill needs to handle?

[fred-wang]

I'm still concerned by the current text for mpadded as I doubt it will reflect what is "acceptable" for native implementations. So at this point, I'm not sure we can rely on it to know what a polyfill should handle.

[davidcarlisle]

As far as I can see, the only difference in attrs is in the pseudo units being slightly restricted: the vertical attrs can only refer to height/depth (not width) and the horizontal ones only to width (not height/depth). Is there something else a polyfill needs to handle?

@NSoiffer I think the biggest breaking change is (as currently written in the core spec) in core width="+3em" has no magic meaning: it's same as width="3em" and forces the length to 3em not increase it by that amount.

Note that the css length syntax allows width="calc(100% + 3em)" to get the increment meaning. This already works on mpadded in whatever version of chrome canary I have installed, although apparently not in firefox.

I am tempted to suggest that MathML4 accepts this breaking change and follows core here: using the same interpretation for any values that are syntactically valid css length values.

MathML4 full spec can still add named lengths and psuedo-units thinmathspace and width etc but they are less of a problem as they are syntactically invalid in core so you don't have the same value having different interpretations in full and core.

See also the discussion in PR #297

[davidcarlisle]

Sigh no My above comment is wrong as core is specified as accepting % but treating them as 0, but perhaps the suggestion for full should still stand, as really we need width="+3em" to mean the same thing in Core and Full.

[davidcarlisle]

WG meeting 2024-11-14 agreed to change full to match core, noting that css length allows calc syntax.