The generic thing is described here: https://w3c.github.io/mathml-core/#layout-algorithms > By default, the box metrics, offsets, baselines, italic correction and top accent attachment of the content box are set to the one calculated for the math content box. However if a different size is specified for the content box (via width, height or related properties), that size is used instead and the inline-start and block-start edges of the math content box are aligned with the ones of the content box, unless otherwise specified in a specific layout algorithm. Some elements like mfrac specifies a different placement: > The math content box is placed within the content box so that their block-start edges are aligned and the middles of these edges are at the same position. I'm not sure if the current text of MathML Core defines resolution of percentages, there seem to be issue 76 and 77 about that. Probably chrome simply treats them as auto. Some tests are available here: https://wpt.fyi/results/mathml/relations/css-styling?label=master&label=experimental&aligned&q=width-height
Bug 1916988 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The generic thing is described here: https://w3c.github.io/mathml-core/#layout-algorithms > By default, the box metrics, offsets, baselines, italic correction and top accent attachment of the content box are set to the one calculated for the math content box. However if a different size is specified for the content box (via width, height or related properties), that size is used instead and the inline-start and block-start edges of the math content box are aligned with the ones of the content box, unless otherwise specified in a specific layout algorithm. Some elements like mfrac specifies a different placement: > The math content box is placed within the content box so that their block-start edges are aligned and the middles of these edges are at the same position. I'm not sure if the current text of MathML Core defines resolution of percentages, there seem to https://github.com/w3c/mathml-core/issues/76 and https://github.com/w3c/mathml-core/issues/77 about that. Probably chrome simply treats them as auto. Some tests are available here: https://wpt.fyi/results/mathml/relations/css-styling?label=master&label=experimental&aligned&q=width-height The spec does not mention `box-sizing` and always say width/height applies to the content box. I opened https://github.com/w3c/mathml-core/issues/257
The generic thing is described here: https://w3c.github.io/mathml-core/#layout-algorithms > By default, the box metrics, offsets, baselines, italic correction and top accent attachment of the content box are set to the one calculated for the math content box. However if a different size is specified for the content box (via width, height or related properties), that size is used instead and the inline-start and block-start edges of the math content box are aligned with the ones of the content box, unless otherwise specified in a specific layout algorithm. Some elements like mfrac specifies a different placement: > The math content box is placed within the content box so that their block-start edges are aligned and the middles of these edges are at the same position. I'm not sure if the current text of MathML Core defines resolution of percentages, there seem to https://github.com/w3c/mathml-core/issues/76 and https://github.com/w3c/mathml-core/issues/77 about that with the consensus to use the size of a block container. But maybe we can just treat them as auto for now (maybe what chrome does too?). Some tests are available here: https://wpt.fyi/results/mathml/relations/css-styling?label=master&label=experimental&aligned&q=width-height The spec does not mention `box-sizing` and always say width/height applies to the content box. I opened https://github.com/w3c/mathml-core/issues/257